LTE et WiFi : Les attentes de la R.13 et R.14

WIFI et LTE
En général, on choisit un mode d’accès WiFi ou LTE pour accéder à Internet et pourtant, actuellement, les terminaux peuvent se connecter simultanément au WiFi pour toutes les sessions IP ne nécessitant pas de QoS, et au réseau LTE. L’accès au WiFI est souvent préférable pour l’utilisateur lorsqu’il peut profiter d’un débit plus élevé que par le LTE et préférable pour l’opérateur qui décharge ainsi ses stations de base pour un trafic vers des utilisateurs résidents.
Par contre, dans le cas ou le débit du WiFi est faible (soit ponctuellement à cause d’un encombrement ou factuellement car le point d’accès est loin du DSLAM), lorsque l’utilisateur configure son smartphone pour un accès WiFi, ce dernier utilisera cet accès même si la qualité d’expérience serait meilleure en LTE.
Afin d’aider l’UE à se connecter au meilleur réseau, et définir des règles de politiques en fonction des applications (temps réels ou non), l’opérateur déploie l’entité ANDSF (Access Network Discovery Selection Function) dans le cœur du réseau.
Dans la R.8, lorsque l’UE détecte la présence du WiFi, tout le trafic était routé via le point d’accès WiFi ou restait en 4G.
La R.9 propose un mécanisme (MAPCON : Multi Access PDN Connectivity) permettant plusieurs connexions IP sur le réseau WiFi et sur le réseau LTE.  Dans ce cas, l’entité ANDSF indique quel accès radio choisir pour différentes applications en fonction de règle de trafic se basant sur l’identification de l’APN, l’adresse IP et le port de destination. Les règles s’appellent ISRP (Inter System Routing Policies).
La R.11 apporte plus de flexibilité sur l’analyse des flux comme par exemple séparé des applications temps réel ou non qui utilisent le même port http, définir une règle en fonction du débit attendu, de la taille du fichier, …
La R.10 propose également une mobilité des flux : un flux IP sur un réseau d’accès peut sans coupure être dirigé vers un autre réseau d’acccès (DSMIPv6 : Dual Stack Mobile IPv6), cependant les opérateurs ont préféré utiliser la mobilité sur le protocole GTP, et la R.13  propose la solution de mobilité IFOM (IP Flow Mobility)
Dans la release R.12, le réseau LTE propose une procédure de sélection du réseau afin d’aider le smartphone à choisir le meilleur réseau d’accès. Dans cette release, le réseau configure un niveau de puissance du signal ce qui permet au dispositif de comparer la puissance reçue à ce niveau et ainsi déterminer sur quel réseau d’accès exécuter la session IP.
La R.12 propose aussi à l’UE de profiter d’une double connexion : Connexion LTE et connexion WiFI simultanée. Il s’agit d’aggrégation dans le cœur réseau et celle-ci s’effectue au niveau de l’entité PGW (PDN Gateway).
Deux scénarios d’agrégation existent :
  1. LWA : L’agrégation des accès LWA (LTE / WLAN Aggregation) s’effectue au niveau de la couche PDCP de l’eNb et le point d’accès WiFI
  2. LWIP L’agrégation des accès LWIP (LTE / WLAN radio level integration with IPsec tunnel) s’effectue au niveau du SGW et le point d’accès WiFi

La R.13 propose l’utilisation du spectre WiFi pour émettre des signaux LTE. L’opérateur déploie des eNb qui émettent dans la bande du WiFi pour faire de l’agrégation de porteuses (CA). Les eNb déployés ne doivent pas interférer avec les bornes WiFi, il est donc nécessaire de mettre en œuvre des mécanismes d’écoute avant émission (LBT/CCA) avant d’émettre. On parle de LAA – License Assisted Access.

  • La R.13 propose le LAA uniquement sur le DL
  • La R.14 propose le LAA sur le DL et UL sur 32 bandes de 20 MHz

MTC : Le réseau M2M / IoT sur la 4G – 2ème partie

Au cours de l’article précédent, nous avions évoqué les évolutions du réseau 4G vers le MTC. Cette évolution est une brique de base pour le réseau 5G et les fonctionnalités que nous avions décrites sont les 4 suivantes :
• control plane CIoT EPS optimization
• user plane CIoT EPS optimization
• EMM-REGISTERED without PDN connection
• S1-U data transfer and header compression

(Je vais reprendre la notation de l’article précédent)
II-3-a) Control plane CIoT EPS optimisation
C-Plane CIoT EPS Optimization est une méthode destinée à encapsuler les données utilisateurs dans les messages du plan de contrôle. En évitant de mettre en place de la signalisation pour rétablir les bearer, cette méthode permet de réduire le nombre de message sur le plan de contrôle lorsque les données à transmettre sont de petites tailles et par conséquent, on réduit la bande utilisée et la consommation du dispositif.
Les fonctionnalités supportées par cette méthode sont :
• Transport de données utilisateurs (IP et Non IP)
• Point d’ancrage de la mobilité du dispositif
• Compression d’entête pour les flux IP
• Protection par intégrité et chiffrement de la Data transmise dans le plan de contrôle
• Interception légale.
Cette méthode s’appuie sur le MME, ce dernier est considéré comme un nœud de transfert de données et l’eNb est vu comme un relai :
• entre l’UE et le PGW (connectivité PDN : UE -> eNb -> MME -> SGW -> PGW) en utilisant les protocoles de signalisation (S1-AP et GTP-C)
• ou entre l’UE et l’entité SCEF (connectivité PDN : UE -> eNb -> MME -> SCEF).

Si l’UE a un stack IP, les données sont transmises en IP de l’UE vers le PGW.

Figure 5a : Control plane IP DATA

Si l’UE ne contient pas de stack IP (NIDD), les données sont transmises au MME via le protocole S1-AP et envoyées soit vers le PGW soit vers le SCEF. Lorsque l’UE fait une demande de connexion vers l’AS en non IP, l’UE indique l’APN  de passerelle. Le choix de la connectivité PDN entre le PGW et le SCEF est défini au niveau du HSS dans la donnée de souscription APN.

Le profil du device au niveau du HSS indique l’APN que doit utiliser le dispositif pour transmettre des données non IP. L’APN route les messages vers le PGW ou vers le SCEF.

On considère ici que l’APN renvoie vers le PGW.

Lorsque l’UE fait une demande d’attachement, il indique :

  • Qu’il souhaite une connection PDN non IP
  • Le réseau utilise l’APN fourni par l’UE ou l’APN contenu dans le profil de l’UE au niveau du HSS et transmis au MME
  • Le PGW donne à l’UE la taille maximale autorisée des paquets (qui peut etre de 128 octets)
  • Les paquets non IP sont transmis via le plan de contrôle par des messages NAS

 

Figure 5b : Control plane Non IP DATA vers le SGW

 

Connection non IP via le SCEF

Dans les deux cas, l’UE émet une demande de transmission de données via la procédure RRC SERVICE REQUEST en encapsulant le message ESM DATA TRANSPORT (message NAS entre l’UE et le MME via l’eNb en relais). Dans le cas précis ou l’UE ne contient pas de stack IP, il informe le MME qu’il souhaite établir une connexion PDN non IP.

Dans le cas de données entrantes :

  • Les données peuvent être bufferisées dans le SGW lequel transmet un message de notification « Downlink Data Notification Message » au C-SGN. Le C-SGN répond au SGW en indiquant le temps restant avant que le device soit joignable (PSM Mode). Cela permet au SGW d’étendre le temps pendant lequel le message sera conservé.
  • Les données peuvent être bufférisées dans le SCEF

 

II-3-b) User plane CIoT EPS optimisation

Dans le cas ou l’UE supporte l’optimisation sur le plan de données (User Plane CIoT EPS Optimization), il doit obligatoirement supporter la méthode S1-U Data transfer. Ainsi,  les données sont transmises via l’interface S1-U, c’est-à-dire entre l’eNb et le SGW.

L’optimisation User plane CIoT EPS optimisation est apportée par une amélioration du contrôle de bearer et par de nouveaux messages RRC ainsi que de nouveaux états RRC permettant un établissement de bearer plus rapide et plus efficace.

 

Les nouveaux états RRC sont : RRC-Suspend et RRC-Resume.

  • Procédure RRC Suspend. Cette procédure est activée par l’eNb permet de libérer le bearer radio entre l’eNb et le device, ainsi que le bearer S1 entre l’eNb et le SGW. Au niveau du SGW, cela supprime dans la table de contexte le numéro d’identifiant TEID du flux et l’adresse IP du eNb mais les autres informations sont conservées (QoS, clé de sécurité,…). Le MME conserve les informations de la connexion S1-AP et du bearer, place le device dans l’état ECM-Idle et répond à l’eNB de la libération du bearer par le message UE Context Suspend response. Le eNB conserve le contexte mais transmet à l’UE le message « RRC Connection Suspend ». Le device conserve les informations AS (clé de sécurité, information sur le flux de trafic) et se met en état ECM-Idle et RRC-Idle
  • Procédude RRC Resume permet de ré-activer les états qui ont été sauvegardés au niveau du device, de l’eNb et du MME. Dans un premier temps, le device récupère les informations de la couche AS et contacte l’eNB. Ce dernier accomplit une vérification de la sécurité pour ré-établir le bearer radio. L’eNB informe le MME par le message « UE Context Resume Request » de la ré-activation du bearer radio. Le MME récupère le profil du S1-AP et place le device dans l’état ECM-Connected. Il retourne vers l’eNb une confirmation « UE REsume Context Response » contenant l’adresse IP du SGW et le MME envoie l’adresse du eNb et le TEID du eNB (informations S1-AP conservées) vers le SGW.

Figure 6 : Messages RRC reprendre ou suspendre un contexte

 

Figure 7 : Call Flow

Pendant l’état RRC-Suspend, le device n’a plus de connexion radio. Il peut de plus être en mode eDRX, donc en cas de mobilité il ne détecte pas le changement d’eNB. Lorsque le device exécutera la procédure RRC Resume vers le nouvel eNb, celui-ci va demander à l’ancien eNb de lui transférer les informations AS. L’ancien eNb en profite pour supprimer le contexte (clé de sécurite, …). Le nouveau eNb crée un TEID, informe le MME lequel transfère le nouveau TEID et l’adresse du nouvel eNb vers le SGW.

De plus, cette méthode permet aussi de transférer des données non IP entre le SGW et le PGW

II-3-c) EMM-REGISTERED without PDN connection

Lors de la procédure d’attachement, l’UE informe le MME qu’il peut être dans l’état EMM-REGISTERED without PDN connection par le message “attachwithoutPDN Connectivity”. Classiquement, un smartphone (Human UE) émet dans la requête EMM d’attachement  un message ESM pour définir les caractéristiques du bearer par défaut. Dans le cas qui nous intéresse, le message ESM PDN CONNECTIVITY REQUEST est remplacé par le message ESM DUTY MESSAGE, l’UE reste connecté au réseau (EPS attached) même si toutes les connexions PDN ont été libérées. On se retrouve donc dans le cas 3G ou le contexte de l’UE n’existe pas au niveau des entités du réseau.

Remarque : « EMM-REGISTERED without PDN connection » à la même signification que « EPS attach without PDN connectivity

Lorsque le dispositif s’allume, avant d’émettre sa demande d’attachement, il lit le SIB2 transmis par l’eNb pour savoir vérifier la compatibilité de la cellule. Si le MME ne supporte pas l’état « EMM-REGISTERED without PDN connection » alors l’UE établie un bearer par défaut. Lorsque l’UE souhaitera émettre des données, un bearer EPS par défaut sera mis en place sauf si l’UE indique une méthode de transmission, par exemple SMS seulement, lors de son attachement.

II-3-d) S1-U data transfer and header compression

L’UE qui supporte le User Plane Optimisation EPS doit supporter le S1-U data transfer afin de transmettre les données sur le plan utilisateur.

On suppose maintenant que l’UE et le MME supporte à la fois la fonctionnalité S1-U data transfer et la fonctionnalité Control Plane EPS Optimization pour encapsuler la DATA entre le CN et l’UE dans des messages NAS

Lorsque le MME reçoit une requête de connexion PDN, le MME détermine la quantité de données à transmettre sur le lien UL et DL et décide ainsi si les données doivent être transmises sur le plan de contrôle ou sur le plan utilisateur. Il vérifie également si l’UE peut supporter

 

Figure 8 :  Etablissement du S1-U bearer pendant le transport de données dans le plan de Controle

1 – L’UE transmet/reçoit des données dans le plan de control (Control Plane CIoT EPS Optimisation).

2 –3 L’UE reçoit une réponse pour faire une demande d’établissement de bearer dans le plan utilisateur (User Plane Bearer). Dans ce cas, l’UE envoie un message NAS vers le MME. Le message est encapsulé dans un message RRC-Service Request émis au eNb, et un message S1-AP UL entre le eNb et MME. De manière classique, le message contient les informations suivantes :

  • NAS message
  • TAI+ECGI de la cellule sur laquelle l’UE est en communication
  • S-TMSI
  • CSG ID (si la cellule sur laquelle est connectée le mobile est une cellule CSG)
  • CSG access Mode

4 – Le MME fait le transfert des données transmises sur le plan de signalisation vers le bearer

Dans le prochain article, nous décrirons certaines procédures et protocoles

Allocation de ressources et scheduling

Dans cet article nous allons voir la signalisation émise par l’eNb pour informer l’UE de la taille du bloc de transport (TBS) alloué à l’UE pour transmettre ses données utiles (payload). La taille dépend de la qualité du lien radio (renseigné par l’UE via le CQI) et des ressources allouées par l’eNb à l’UE (scheduling).

Nous ne nous intéresserons pas ici à la procédure de scheduling mais uniquement à l’échange de signalisation pour informer l’UE de la taille et des ressources allouées pour transmettre ses données.

Allocation de ressources

La trame physique du LTE est partagée entre tous les utilisateurs, et nécessite la transmission de signalisation 4G sur des ressources blocs commun aux UES allouées au canal physique nommé  PDCCH* et l’échange de données sur des RB specifiques avec un format de modulation et de codage imposée par l’eNb et qui dépend des conditions radios.

Le mapping physique LTE (cf http://blogs.univ-poitiers.fr/f-launay/2013/08/27/rsrp-et-rsrq/) rappelle la répartition des ressources en temps et en fréquence entre utilisateurs et la disposition de RB spécifique pour la gestion des ressources.

L’UE doit donc attendre l’ordre spécifiant :

  • Le Time Slot sur lequel il va recevoir/émettre des données
  • Le RB (les blocs de fréquence) sur lequel il va recevoir/émettre des données
  • Le schéma de codage et de modulation (MCS) pour démoduler/moduler les données
  • La puissance d’émission

*Le canal PDCCH est le canal physique de contrôle dans le sens descendant qui porte les informations permettant à  l’UE de connaître les ressources qui lui sont allouées dans cette sous-trame (position des RB, format MCS) et des informations de contrôle permettant à l’UE de connaître les ressources et le schéma de modulation qu’il utilisera 4 TTI plus tard pour émettre ses données vers l’eNb.

Alloc_ressource_fig1

Figure 1 : Schéma général d’un échange d’information de contrôle

L’eNb doit donc transmettre de nombreuses informations vers chaque UE par un message nommé DCI  (Downlink Control Information). Le DCI est transmis soit à un groupe d’UE, soit spécifiquement à un UE afin de lui porter à connaissance l’attribution des ressources pour la transmission de ses données (payload). Dans ce cas, l’information portée par le PDCCH (et transmis en broadcast) est destiné à un seul UE. Pour savoir si le PDCCH lui est destiné, l’UE doit décoder le CRC avec ses identifiants RNTI (P-RNTI, C-RNTI, SPS-RNTI, RA-RNTI).  Toutefois, l’eNb doit aussi transmettre des informations systèmes destinées à plusieurs UE simultanément donnant ainsi des règles d’allocation suivant le mode de transmission de l’UE (la classe du terminal permet de définir ses capacités notamment sur la diversité de transmission, de réception et le MIMO). Dans ce cas, le CRC du PDCCH est codé avec la valeur du SI-RNTI.

Puisqu’un mobile ne peut deviner si un PDCCH lui est transmis, chaque UE qui n’est pas dans l’état discontinue (DRX) décode sur la sous-trame correspondante l’ensemble des CRC en fonction de ses identifiants RNTI. La taille allouée pour le PDCCH est néanmoins connue par le mobile sur un espace de recherche dit espace de recherche commun et son emplacement est toujours situé sur les premiers symboles OFDM. Quant à sa taille, elle est formée par l’agrégation de 1,2, 4 à 8 CCE sur lequel l’eNb transmettra respectivement 8 PDCCH, ou 4 ou 2 ou 1 (selon le format du PDCCH c’est  dire à la quantité d’information à transmettre). Sur l’espace de recherche commun, l’eNb transmet des informations système (SI-RNTI).

Lorsque le PDCCH est spécifique à un UE, on parle alors d’espace de recherche spécifique. L’emplacement de ce dernier est défini en fonction du RNTI de l’UE et du numéro de trame. Lorsque l’UE a reconnu un PDCCH spécifique, il répond en retour sur le PUCCH ou PUSCH. Il informe notamment  l’eNb de la qualité du lien radio via l’indication de la qualité du canal nommé CQI, ce qui permet à l’eNb d’adapter les paramètres de transmission à savoir :

  • L’efficacité du code correcteur.
  • Le type de modulation (QPSK, 16 QAM, 64 QAM).
  • Dans le cas du MIMO, les indicateurs RI et PMI.

Pour satisfaire aux différents besoins, il existe plusieurs formats DCI spécifiant le type d’information à transmettre (de taille par conséquent différent, ce qui revient à une allocation en terme de CCE différent) et décrites dans la norme 3GPP R8/R10 :

  • DCI Format 0 est utilisé pour informer l’UE de l’allocation des ressources sur la voie montante
  • DCI Format 1 est utilisé pour informer l’UE de l’allocation des ressources de la voie descendante lorsqu’il y a une diversité de transmission (MISO ou MIMO rank 1)
  • DCI format 2 est utilisé pour informer l’UE de l’allocation des ressources de la voie descendante pour le MIMO.
  • DCI format 3 est utilisé pour la transmission des commandes de contrôle de puissance (TPC commande) pour le canal de la voie montante.
  • DCI format 4 est utilisé pour informer l’UE de l’allocation des ressources sur la voie montante dans le cas MIMO

 

Pour un format donnée, les informations transmises dépendent du type de RNTI (P-RNTI, C-RNTI, RA-RNTI, …) et du mode de transmission. Ainsi , en se basant sur le mode de transmission,  la norme précise des sous-formats :

Alloc_ressource_tab1Tableau 1 : Format DCI et informations transmises

Nous avons précédemment dit que le PDCCH était décodé selon l’identifiant RNTI. Pour faire une synthèse, le tableau 2 reprend selon l’état du mobile (connecté, en veille)la liste les formats DCI correspondant en fonction du type d’identifiant :

Alloc_ressource_tab2Tableau 2 : Correspondances entre le type RNTI et les formats DCI compatibles

Entre la Release 8 et la Release 10, le 4ème format est apparu. Ce dernier est utilisé pour informer l’UE de l’allocation des ressources sur la voie montante en utilisant le multiplexage spatial, ce qui nécessite donc de transmettre davantage d’informations comparé au DCI format 0.

Alloc_ressource_tab3

Tableau 3 : Les différents formats selon la release

Mais, ce n’est pas la seule différence, car en effet, la R10 traite du LTE-Advanced laquelle autorise l’agrégation de plusieurs bandes de fréquences et par conséquent chaque format du R10 comporte un champ supplémentaire précisant la porteuse concernée.

Alloc_ressource_tab4

Tableau 4  : Les différents champs concernant les informations portées par le DCI selon la release pour le format 0

Alloc_ressource_tab5

Tableau 5  : Les différents champs concernant les informations portées par le DCI selon la release pour le format 2

 

 

Exemple

Alloc_ressource_fig2

Figure 2 : Exemple issu du site http://niviuk.free.fr/lte_dci_decoder.html

Le tableau donne des informations concernant la valeur hexadécimales du DCI. En remplaçant 2584A800 par 2585A800, la modulation est une 64QAM

(Cf Specification ETSI 3GPP TS 36.213 R8, Table 7.1.7.2, http://www.qtc.jp/3GPP/Specs/36213-920.pdf, la table TBS donne la taille 9144 à la ligne 22, colonne 18)

Alloc_ressource_fig3

Figure 3 : Exemple issu du site http://niviuk.free.fr/lte_dci_decoder.html

 

Comme dernier exemple, je vous propose de découvrir les informations contenues dans le PDCCH spécifiant le niveau de puissance

Alloc_ressource_fig4

 

Ref : http://blogs.univ-poitiers.fr/f-launay/tag/pdcch/ pour calculer le nombre maximum d’UE pouvant simultanément échanger des données avec l’antenne et le nombre maximum d’UE pour la VoLTE

http://www.sharetechnote.com/html/DCI.html

http://nitintayal-lte-tutorials.blogspot.fr/2013/05/all-about-pdcch-and-cce-allocation.html

 

 

Pool de MME

I) Principe et rappels

Lorsque l’UE est à l’état EMM-Registered et ECM-Idle, il est localisé sur une zone nommée Tracking Area. Une seule zone de localisation suffit pour le LTE puisque l’UE n’est enregistré que sur le domaine en commutation de paquets.

A ce titre, on peut rappeler que sur le réseau 2G/3G, le mobile est localisé :

  • LA : Location Area pour la localisation dans le domaine CS
  • RA : Routing Area pour la localisation dans le domaine PS

Pour le LTE, la localisation de l’UE est initialisée par la requête d’attachement au réseau. Ensuite, la requête de Update de TA (TAU) est déclenchée soit périodiquement à la fin d’un Timer soit sur détection de changement de TA par l’UE.

Des mécanismes particuliers ont été mis en oeuvre en 4G permettant à l’UE d’être enregistré sur plusieurs TA simultanément.

imgf0001

II) Enregistrement de l’UE sur Plusieurs TA

Dans des zones à forte mobilité (Voie ferroviaire ou autoroutière), l’UE passe rapidement d’une zone de TA à une autre, déclenchant ainsi de la sig pour la mise à jour de la localisation. Pour alléger le nombre de requêtes TAU, le MME peut indiquer une liste de TA à l’UE et tant que l’UE est sur un eNb ayant un TAI appartenant à cette liste, l’UE ne procède par à une demande de mise à jour.

III) Pool de MME : Mécanisme S1-flex

A l’inverse, une zone de TA peut aussi être gérée par plusieurs MME. On parle de pool MME (ensemble). L’avantage est de pouvoir faire basculer le contexte d’un UE (contexte crée lors de l’attachement par exemple) vers un autre MME appartenant au même pool afin de faire du partage de charge ou un partage de réseau (network sharing). Dans le cas du partage de réseau, un pool de MME peut appartenir à plusieurs opérateurs. Lorsque le réseau veut réaliser un partage de charge, il doit donc transférer le contexte de l’UE d’un MME à un autre MME du même pool, ce qui nécessite de la part du mobile de lancer une procédure de TAU. Or comme cette demande est à l’initiative du réseau, l’UE est notifié de cette demande par l’eNB qui relâche la connexion RRC avec la cause loadbalancing (même si le MME est mis en maintenance).

Un eNb, comme par exemple l’eNB 2 est connecté à différents MME, cela est nécessaire dans le cas de RAN Sharing ou plusieurs opérateurs ne souhaitent partager que les antennes.

On appelle le mécanisme S1-flex la possibilité pour un eNb d’être connecté à plusieurs MME, mais attention il n’existe qu’une seule interface S1-MME par couple MME – eNb. L’eNb est à l’initiative de cette association et les fonctions du S1-MME sont gérées par le protocole S1-AP

IV) Mécanisme ISR

ISR Idle mode Signaling Reduction est un mécanisme qui permet de réduire la signalisation lorsque l’UE fait une procédure de re-sélection inter-RAT.

Nous avons vu dans le premier paragraphe que l’UE est localisé en fonction du réseau 2G/3G ou 4G selon le LA, RA ou TA. Dans le cas du passage du réseau LTE au réseau UMTS, l’UE sera localisé en TA puis en RA. Lors de la re-sélection de cellule, l’UE doit faire une mise à jour de sa localisation, même s’il passe régulièrement de la 3G au LTE en restant toujours dans les mêmes cellules.

Le mécanisme ISR consiste à conserver au niveau de l’UE les identifiants de cellules ( RA et TA seulement car le LTE ne fonctionne que dans le domaine Paquet) et en cas de re-sélection d’un système à un autre, l’UE compare l’information de la cellule et n’alerte le MME ou le SGSN qu’en cas de modification de cellule. Par contre, en cas de paging, les notifications d’appels seront envoyées sur les deux cellules des zones TA et RA

Lorsque l’UE fait une demande de localisation LA pour le domaine CS, et si l’UE est attaché au domaine CS du LTE (cas pour le mécanisme de CSFB) alors l’ISR est désactivé.

Protocole RRC

Hérité de la 3G, le protocole RRC permet à l’UE et à l'(e)Nb d’échanger de la signalisation (messages RRC).

Au cours de l’article Protocoles NAS et Protocoles AS, je vous avais présenté le concept d’accès au réseau (NAS et AS). Dans cet article, j’avais présenté le  NAS (Non Access Stratum). Comme son nom l’indique les fonctionnalités du NAS sont indépendantes de la couches d’accès, donc de l’accès radio et par conséquent le NAS permet l’échange d’information de signalisation entre l’UE et le MME.

Le NAS a pour rôle de permettre :

  • l’enregistrement de l’UE au réseau
  • l’authentification de l’UE
  • la mise à jour de la localisation
  • la gestion des appels.

Cf. article  Protocoles NAS et Protocoles AS « La couche NAS a deux rôles essentiels (figure 2): »

  • Gestion des sessions (et des appels pour la 3G)
  • Gestion de la mobilité.

En fait, les protocoles EMM, ECM et ESM sont des protocoles de signalisation de la couche NAS, cela concerne l’UE et le MME.

lte_control_plane_RRC

L’AS regroupe les protocoles de signalisation propre au réseau d’accès (Access Stratum) c’est à dire entre l’UE-eNb et eNb-MME, eNb-SGW pour la 4G.

L’AS est transporté par les messages RRC sur l’interface LTE-Uu. Même si le NAS est indépendant de la couche d’accès, il est néanmoins transporté par la couche radio dans le cadre du LTE. Ainsi, le NAS est transporté par le protocole RRC (interface LTE-Uu) et le protocole S1-AP (interface SA-MME).

lte_protocol_layers

A titre d’exemple, pour l’EMM les messages ATTACH/DETACH REQUEST, TAU sont encapsulés dans le message RRC Connection Setup Complete, tout comme le SERVICE REQUEST de l’ECM (se référer à al’article correspondant : ECM – EPS Connection Management)

Pour la 3G, il faut rajouter le RNC comme le montre la figure ci-dessous

asnas3G

Le protocole RRC a pour but est de transférer les informations de signalisation entre l’UE et la station de base, nous allons pouvoir maintenant étudier les messages d’accès au réseau et de gestion d’appels, ainsi que les call flow dans les articles à venir.

Commentaires : Bien différencier les protocoles et les interfaces. L’interface S1-MME et le protocole S1-AP.

Technologie de transport de la voix en 4G : CSFB (part 2)

Gestion de la mobilité entre le réeau 2G/3G et LTE

Comme nous l’avons entrevu dans le précédent article, un réseau doit en permanence savoir localiser un mobile afin de fournir les services à l’ayant droit. La procédure de localisation se nomme « Mobility Management », c’est-à-dire Gestion de la mobilité.

Pour terminer un appel via la fonction CS Fallback, le domain CS doit connaitre la position du mobile en se référant à la localisation fournie par le réseau LTE, c’est-à-dire en se basant sur l’aire d’enregistrement du mobile indiquée par le MME. Le MME a donc la charge d’informer la VLR de la zone de localisation du mobile sur le réseau 4G.

Le cœur de réseau 3G possède déjà la fonction permettant de gérer simultanément la mobilité sur le réseau en commutation de circuit (CS) et en commutation de paquets(PS), chaque mobile étant géré sur une zone nommée LA (Location Area) pour la partie CS et RA (Routage Area) pour la partie PS.

Afin de réduire le trafic de signalisation sur les réseaux mobiles 2G/3G et 4G, l’enregistrement de localisation du mobile sur le réseau SGSN par la VLR est ré-utilisé par la technologie CS FallBack : Concernant les informations de localisation du mobile sur le réseau 4G (TA : Tracking Area), le MSC/VLR exploite donc la même logique que pour le réseau PS en 3G, c’est-à-dire la VLR demande les données d’enregistrement du mobile sur le réseau 4G et les exploite de manière identiques aux données d’enregistrement de localisation fournies par les requêtes venant du SGSN.

 DoCoMo_MME1_database

Cela permet d’une part d’éviter une mise à jour trop fastidieuse des MSC pour prendre en compte les requêtes de localisation sur le réseau 4G pour la voix.

Il faut également se rappeler qu’un terminal sur le réseau 4G ne peut être sur le réseau 2G/3G en même temps. Ceci implique que le MME, qui contient la zone d’enregistrement du mobile sur le réseau LTE (TA) doit être en mesure d’identifier vers quel VLR il doit envoyer ses messages de gestion de mobilité. Le MME contient donc une base de données de localisation permettant d’avoir la correspondance entre la zone de localisation du réseau 4G (TA) avec la zone de localisation du mobile sur la VLR (LA). Cette base de données permet donc de déterminer quel MSC/VLR doit être contacté pour l’enregistrement de la localisation du mobile.

La figure 2 détaille l’échange d’information entre le MME et la VLR : La VLR a identifié le MME sur lequel était géré le mobile et le MME connait la VLR et le LA associé à la position du mobile si ce dernier est sur le réseau 3G CS. A l’inverse, la VLR connait l’équipement MME associé.

 

DoCoMo_MME_database

Figure 2 : Mise à jour des données de localization sur la VLR et le MME

 

Si nous reprenons la figure précédente, le call flow est le suivant :

  1. L’UE envoie une requête Tracking Area Update (TAU) vers le MME indiquant la position actuelle (TA) du mobile
  2. Le MME accomplie la mise à jour de la position du mobile vers le HSS via une procédure Location Update
  3. Le MME exploite la base de correspondance TA/LA pour identifier d’une part la zone de localisation LA du mobile correspondant au réseau de CS 2G/3G et la VLR correspondant, c’est-à-dire celui qui gère cette zone (LA). Via l’interface SGs, le MME envoie une requête LAU (Location Area Update) au MSC/VLR avec la valeur du LA correspondante.
  4. La VLR qui reçoit la demande de mise à jour de localisation enregistre la correspondance de l’identité du MME ayant fait la requête de mise à jour (comme c’est le cas avec le SGSN) et l’identité unique du mobile (IMSI). Cela permet au VLR de savoir sur quel MME (comme c’est le cas avec le SGSN) le UE est actuellement connecté, ce qui est nécessaire pour un appel à destination d’un mobile connecté sur le réseau 4G.
  5. La VLR lance une procédure d’enregistrement vers le HSS permettant à ce dernier de savoir sur quel VLR est maintenant enregistré le UE, et informe le MME du numéro TMSI affecté au mobile (Temporary Mobile Subscriber Identity).
  6. Le MME informe le mobile de son identité TMSI et de sa localisation LA.

Gestion de l’itinérance (Part 2) : la mobilité des UE

Part 2 : Gestion de la mobilité

II-1) – La signalisation


Le réseau GSM et 3G s’appuie sur l’architecture traditionnelle de la téléphonie commuté et exploite le protocole de signalisation SS7 (cf. http://mooc-ipad-formation.eu).
Ainsi, la gestion de la mobilité, la gestion de la localisation et de l’authentification étaient pris en charge par le protocole MAP (Mobile Application Part).

Ce protocole décrit les messages transmis entre les différents équipements du réseau de l’opérateur Home (HPLMN) et l’opérateur visité (VPLMN). Lors d’une première phase de migration vers l’IP, la signalisation SS7 initialement transportée sur des liens traditionnels TDM comme le E1/T1 est dorénavant encapsulée sur l’IP via le protocole SIGTRAN.

Mais, le réseau LTE n’utilise pas le protocole de signalisation SS7 : Diameter a été préféré et remplace le protocole MAP en supportant toutes ses fonctionnalités.

Le protocole DIAMETER a été adapté pour le LTE afin de gérer la gestion de mobilité des UE au sein du LTE mais le protocole doit également assurer l’interconnexion entre le LTE et les réseaux 2G/3G (DIAMETER to MAP). Pour échanger des données de signalisation, DIAMETER utilise des AVPs (Attribute Variable Pair) afin d’encapsuler les données en provenance d’applications reconnues.

Sur le tableau suivant, en guise d’exemple, nous donnons la traduction des messages MAP/DIAMETER.

diameter_map

II-2) L’architecture du réseau LTE

Pour comprendre la gestion de la mobilité sur le réseau LTE, il est nécessaire de revenir sur l’architecture du réseau en insistant (en rouge) sur la partie roaming (cf. article précédent).

LTE_roamingLes interfaces en rouges sont exploitées lors du roaming, nous allons les détailler pour plus de clarté :

  • Gestion de la mobilité :

L’interface S6a permet de transférer des données d’authentification et de localisation entre le MME et le HSS via Diameter afin d’autoriser ou non l’accès d’un utilisateur au réseau LTE.
En général, l’authentification est réalisée en respectant le protocole AAA lequel réalise trois fonctions : l’authentification, l’autorisation, et la traçabilité (en anglais : Authentication, Authorization, Accounting/Auditing)
L’interface S6d autorise les échanges d’informations relatives au protocole AAA entre le SGSN et HSS sur (over) DIAMETER.

  • Policy Control and Charging

L’interface S9 transfère la politique de contrôle de la QoS et les informations de taxation entre le HPCRF (Home Policy and Charging Rules Functionality) et le PCRF (Policy and Charging Rules Function) du V-PLMN toujours sur Diameter (cf. architecture SAE/LTE)
Le PCRF supervise les flux sur le réseau LTE : Il peut détecter les types de flux et de services (DPI : Deep packet Inspector) et met en relation la taxation adaptée (abonnement, calendrier) sur ce type de flux.

  • GTP Traffic

Le flux de données est transporté via un tunnel entre le SGW et le PGW sur l’interface S8. On retrouve le même fonctionnement en 2G et 3G, entre le SGSN et le GGSN.

II-3) Mise à jour de la localisation

Lorsqu’un utilisateur authentifié est en déplacement, le premier message reçu par le cœur de réseau est un message de Mise à Jour de la localisation (Location Update), quel que soit le protocole MAP ou DIAMETER utilisé.

Cependant, dans le cas

  • GSM MAP; le message ISD (Insert Subscriber Data) transporte le profil complet de l’abonné et si l’information complète ne peut être transmise dans un seul message ISD, le V_PLMN demande la transmission des informations complémentaires via d’autres messages ISD.

En 2G/3G, le protocole INAP/CAMEL est utilisé chaque fois qu’un utilisateur est en itinérance sur un autre réseau. LTE ne supporte pas le protocole CAMEL, il n’existe pas de traduction de message INAP vers le protocole DIAMETER

  • Pour DIAMETER, le LUA (Location Update Answer) transporte le profil de l’abonné. Ainsi, le DIAMETER ISD n’est utilisé que lorsque le H-PLMN demande un changement dans le profil de l’abonné.

Sur les figures ci-dessous, nous illustrons la partie Location Update via le protocole MAP (figure de gauche) et via le protocole Diameter (figure de droite)

Loc_Update_MAP_Diameter

II-4) Contrôle de la politique de QoS et facturation en temps réel

Dans le précédent article, nous avions vu deux techniques de routage de trafic, soit via le P-GW du réseau visité (Local Breakout) soit via le P-GW du réseau home (Home Routing).

Dans le premier cas, il est nécessaire de définir un accord pour échanger les informations de contrôle d’appel via l’interface Gy entre les deux PLMN. Ainsi, le PDN du V-PLMN peut interagir directement avec le système de tarification (charging system) du H-PLMN.

II-4.1) Home Routing

Basons-nous sur l’architecture du LTE, en focalisant notre attention sur les équipements impliqués lors du roaming. Sur la figure suivante, le V-PCRF communique avec le H-PCRF via l’interface S9 mais la facturation en temps réel (Real Time Charging) n’est pas transmise sur l’interface S9, mais via l’interface Gy selon le protocole DIAMETER RFC 3588.

Chaging_system_HPLMN

Concernant le roaming 2G/3G vers la 4G (on parle de roaming INTER-RAT), il faut savoir que le PCEF n’est pas pris en charge sur le réseau 2G/3G, ce qui pose un souci de QoS lors d’un roaming inter-RAT. En effet, dans le cas du réseau 2G ou 3G, le GGSN était dédié aux données et la QoS était spécifiée par la création d’un PDP context, la téléphonie était géré par le MSC, les SMS par le SMSC, et les services avancés par CAMEL.

II-4.2) Local Breakout

La procédure est légèrement différente, puisque c’est le PCEF du réseau visité qui transmet les informations de facturation en temps réel au H-PLMN. Les mêmes interfaces que précédemment sont utilisées.

Chaging_system_PLMNs

Gratuité de l’itinérance (Part 1): Bouygues dégaine en premier

Architecture du Roaming LTE

En début d’année, les opérateurs (Free, suivi de Bouygues puis Orange) avaient annoncé la gratuité du Roaming (itinérance) sur l’ensemble de l’Europe ou dans certains pays (Italie, Portugal pour Free), et/ou réservé à quelques abonnements. Ainsi, par exemple Bouygues avait annoncé le 22 janvier l’itinérance gratuite en Europe sur ses forfaits Sensation à partir du 24 février.

Nous allons montrer dans cet article comment la gratuité peut être effective sur le réseau 4G. Mais, comme l’objectif de toute entreprise, c’est de gagner de l’argent, nous aborderons donc dans cet article la partie facturation (billing) et le chargement d’information de tarification sur le type de service (charging).

Dans un premier temps, il faut revenir sur le concept de routage pour la LTE, le fonctionnement du LTE se diffère à ce niveau par rapport à la téléphonie 2G/3G. En effet, il existe deux méthodes de routage, le Home Routing et le Local breakout. A chaque méthode est associée des processus de tarification qui différent par conséquent par rapport à la 2G et 3G).

Nous allons donc naturellement commencer cet article par l’architecture de Roaming du LTE

I-1) Roaming LTE

Un réseau mobile déployé par un opérateur dans un pays se nomme PLMN (Public Land Mobile Network). Chaque utilisateur ayant souscrit à un opérateur utilise de préférence le réseau de cet opérateur, on parle de H-PLMN (Home PLMN). L’itinérance (roaming) permet à cet utilisateur de se déplacer en dehors du réseau de son opérateur et d’utiliser les ressources d’un autre opérateur (concurrent ou complémentaire). Cet opérateur est appelé V-PLMN (Visited PLMN).

Un utilisateur en itinérance est connecté à l’interface E-UTRAN, au MME et au S-GW du réseau LTE visité. Cependant le LTE/SAE permet de router les paquets vers un P-GW lequel appartient soit au réseau de l’opérateur visité (V-PLMN) soit à celui de son propre opérateur (H-PLMN), comme le montre la figure ci-dessous.

roaming

L’avantage du Home Routing est la capacité d’accéder aux services souscrits chez son opérateur (H-PLMN) même si le client (abonné) est sur un réseau visité. Le P-GW dans le réseau visité permet à l’abonné un accès local (Local Breakout) au réseau Internet via le réseau de l’opérateur visité.

L’interface entre le S-GW (Serving Gateway) et la passerelle P-GW permettant d’accéder au réseau de données (PDN : Packet Data Networks) est nommée S5 dans le cas du Local Breakout ou S8 pour le Home Routing.

I-2) LTE roaming Charging

La complexité des nouveaux modèles de taxations pour supporter l’itinérance en 4G sont plus nombreux que pour la 3G

  • Les cartes Pré-payées. Le standard CAMEL, qui permet l’accès par pré-payement aux services 3G n’est pas compatible avec la 4G. Ains, les accès au réseau PDN par des utilsateurs de cartes pré-payées doivent être obligatoirement routées vers le H-PLMN et ne peuvent donc pas être routés via le V-PLMN. Les opérateurs doivent donc mettre en place un flux de taxation spécialement dédié au clients de carte prépayé afin que ces derniers puissent accéder au PDN via leur P-GW
  • Les forfaits : La facturation s’appuie sur les mêmes tickets que le 3G.

Dans le cas de Local breakout, les opérateurs n’ont pas la même visibilité sur les activités des abonnés puisque la connexion de l’abonnée est gérée par le V-PLMN. Cependant, afin que l’opérateur Home puisse avoir des informations en temps réels (nécessaire entre autre pour les forfaits bloqués), il doit établir une interface DIAMETER entre son système de facturation et le P-GW du réseau visité.

Dans le cas d’un Local Breakout sur des services IMS, le réseau visité crée un CDR (Call Detail Records ) en provenance du S-GWS-Gateway(s). Cependant le CDR ne contient pas toutes les informations requises pour créer un TAP selon la version 3.12 pour le service utilisé (évènement ou session). En conséquence de quoi, les opérateurs doivent corréler les CDRs émis par leur proper réseau avec le CDR crée par l’IMS pour constituer un enregistrement TAP.

I-3) TAP 3.12

TAP : Transferred Account Procedure est le mécanisme permettant aux opérateurs d’échanger des informations de facturations des clients en roaming. TAP 3.12 correspond à la version 12 et la release 3, laquelle décrit la syntaxe des fichiers TAP transmis entre les opérateurs depuis le 1er mai 2013.

tap

Le TAP est transmis au HPLMN au plus tard 36 heures après la fin de la session.

Extrait du module de Formation LTE 4G – part 4

Voici le dernier article extrait du module de formation réalisé pour détailler la couche physique du LTE et principalement la formule de Shannon et le calcul de puissance.

Capacité : Formule de Shannon

Nous allons maintenant déduire de cette étude sur la couche physique, l’impact au niveau du calcul de Shannon appliqué au LTE.

C = FB log2(1 + SNR)

 C, la capacité est proportionnelle à la bande B, et dépend du rapport Signal à Bruit SNR de la communication. Le facteur F est un facteur de pondération qui prend en compte la durée du temps de garde mais aussi, du nombre de symboles de contrôle par RB.

Avec Nsc=12, le nombre de sous porteuses et Ns, le nombre de symboles OFDM par sous trame (une sous trame à une durée de 1ms). Or, nous savons qu’il y a 6 ou 7 symboles par slot, un slot étant une demi sous trame. Donc Ns=12 ou 14 (axe vertical).

Mais, dans un Ressource Block, il y a donc Nsc*Ns/2 symboles dont 4 symboles (RE) réservés au CRS  (Cell Reference Signal). Donc le nombre de symboles utiles pour la transmission sont proportionnelles à la formule de Shannon à un facteur (Nsc.Ns/2-4)/Nsc.Ns/2

Pour plus d’information, lisez l’article suivant

http://mirror.transact.net.au/pub/sourceforge/n/project/ns/ns3-lte/HARQ/Documents/State%20of%20the%20Art/Articles/phylayer_simu.pdf

Bouygues souhaite récupérer les abonnées des autres opérateurs

Il y a quelques mois, nous avions assisté à une plainte des Australiens contre Apple pour publicité mensongère : Les iphones dit 4G (iphone5) n’étaient pas compatible en Australie, se référer à l’article suivant : http://blogs.univ-poitiers.fr/f-launay/tag/apple/

Toutes personnes qui possèdent un iphone 5 ne peut donc pas se connecter sur le réseau 4G en France puisque les fréquences ne sont pas compatibles. Mais, à partir du 1er octobre, Bouygues ouvre son réseau sur la bande de 1800 MHz (Refarming).

D’ailleurs, le PDG de Bouygues Telecom, Olivier Roussat, fait un appel du pied à tous les possesseurs d’Iphone5 via  Twitter en publiant le messagesuivant  « Bienvenue à tous les detenteurs d’Iphone5. ».Je vais twitter à M Roussat mes cours sur la 4G et lui proposer mon catalogue de formation 🙂

Orange et SFR vont ils lancer rapidement leur réseau sur la bande de 1800 MHz? Ils devront le faire quoiqu’il en soit, car pour préparer le LTE-A, il est nécessaire d’avoir plus de bande de fréquence que celles autorisées sur le 2600 MHz et 800 MHz.

Quant à Free, la course à la 4G n’est que le début car le LTE-A qui promet en débit de 1Gbps nécessite 100 MHz de bande, soit 5 fois plus de bande que celle actuellement acquise par l’opérateur.