Bearer par défaut, bearer dédié et Application à la VoLTE

Bearer par défaut ou bearer dédié ?

Le bearer est un circuit virtuel qui s’établit sur le plan utilisateur (user plane) entre l’UE et la PGW (exemple circuit en rouge de la figure 1).

Figure 1 : EPS Bearer

L’association du flux IP avec le bearer est déterminée par un gabarit de trafic nommé filtre TFP (Traffic Flow Template). Ce filtrage est réalisé au niveau du PGW pour les paquets entrants et au niveau de l’eNb pour les paquets sortants. Le gabarit de filtre TFT s’appuie sur les adresses IP (source et destination), les numéros de ports (source et destination) et le protocole IP. Le SDF (Service Data Flow) correspond à un ensemble de flux IP associé à un service utilisateur avec la même QoS (par exemple, plusieurs flux IP provenant de site différents). Les flux ayant les mêmes caractéristiques de QCI/ARP (QoS Class Identifier et Allocation and Retention Priority) seront transmis dans le même bearer (cf. figure 2).

Figure 2 : Association d’un flux dans un bearer

Chaque entité du plan de transport du réseau 4G (eNb, SGW, PGW) a pour rôle de transmettre les paquets vers l’entité suivante. Les paquets sont transmis à travers un bearer entre deux entités. Le choix du bearer est défini de manière unique par un couple d’identifiants entre l’entité qui émet le paquet et l’entité qui reçoit le paquet. Cet identifiant est nommé TEID (couple : TEID_émission, TEID_reception) et la valeur du TEID est définie de manière unique au niveau de chaque entité. Par exemple, on suppose la création d’un bearer (par défaut) pour permettre un accès IP entre l’UE et le PGW. Le PGW crée un TEID=124 pour un bearer, et informe le SGW de son TEID. Le SGW sauvegarde le TEID du PGW et crée lui-même un numéro TEID (par exemple 2028 ou par coïncidence on pourrait aussi avoir un TEID 124 si ce numéro TEID n’existe pas au niveau du SGW, il s’agit alors d’une coïncidence avec une probabilité très faible) qu’il communique au PGW. Le SGW va créer un autre identifiant de bearer (par exemple le 11014) qu’il communique à l’eNB. L’eNb crée un numéro de bearer (ex : 100) qu’il communique au SGW.

Le SGW peut ainsi créer une table de contexte : Le TEID 2028 est associé au TEID 124 du PGW. Le TEID 11014 est associé  au TEID 100 du eNB. Le SGW fait l’association entre son TEID 2028 et le TEID 11014.

Exemple d’une table de contexte simplifiée au niveau du SGW

TEID_SGW TEID_entité @IP_entité Association TEID QoS
2028 124 @IP_PGW 11014 QCI=8 ARP
11014 100 @IP_eNb 2018 QCI=8 ARP

 

Ainsi, lorsqu’un paquet arrive sur le TEID=2028 du SGW, il associe le TEID=2028 au TEID=11014 et réalise l’action qui consiste à transmettre le paquet vers le numéro TEID=100 de l’entité dont l’adresse est @IP_eNb .

Le traitement des paquets est donc réalisé à partir d’une table de contexte, indiquant le « routage » à effectuer vers le TEID de sortie lorsque le paquet arrive par le TEID entrant. Cette table de contexte est créée par la signalisation 4G lors de l’attachement du mobile pour un bearer par défaut, ou déclenchée soit par le mobile soit par le PGW pour la création d’un bearer dédié. C’est ce que nous allons présenter dans cet article.

Par conséquent, nous allons dans cet article décrire le rétablissement d’un bearer par défaut et l’établissement d’un bearer dédié pour la mise en place d’une session. Afin de faciliter la compréhension de l’article, nous allons respecter un code couleur :

  • Message RRC en noir
  • Message EMM en bleu
  • Message ESM en vert
  • Les procédures en rouge

Cet article s’appuie sur le livre : VoLTE et ViLTE de M Perez André.

Procédure de demande de session

Lorsqu’un UE souhaite établir une session, il transmet au MME (il s’agit donc d’un message NAS) une demande d’établissement de session initiée par la sous-couche ESM. Les messages ESM seront encapsulés dans les messages RRC. Les messages RRC transportent également des messages NAS de la sous couche EMM. Les procédures seront définies par un code couleur rouge. Suite à la demande de création d’une session, le MME va déclencher l’établissement de bearer grâce aux protocoles RRC (bearer radio), S1-AP et GTPv2-C (respectivement pour la création du bearer radio, du bearer S1 et S5).

Cet  article s’appuie sur la spécification 3GPP TS 24.301

Rappel sur la mise en place du bearer par défaut lors de l’attachement.

Le default bearer est le bearer par défaut mis en place lors de la procédure d’enregistrement de l’UE (aussi nommée attachement de l’UE) : L’UE fait une demande d’attachement au MME, le MME sélectionne le PGW en fonction de l’APN de l’UE (l’opérateur doit s’assurer que l’algorithme de résolution d’APN au niveau du MME est correctement implémenté). En cas de roaming, le HSS peut notifier au MME de nouvelles données de souscriptions EPS (le HSS fournit donc un nouvel APN), permettant ainsi de réaliser un roaming selon le service LBO (Local Break Out, un contrat d’itinérance particulier). Le PGW fait une requête d’adresse IP au serveur DHCP et attribue une adresse IP permanente à l’UE (permanente signifie tant que l’UE reste attaché au réseau). Le PGW vérifie les valeurs des paramètres de QoS (QCI, ARP, GBR, MBR, AMBR) proposées par le MME (valeurs récupérées au niveau du HSS).

Comme nous l’avions déjà évoqué dans des articles précédents,  le bearer par défaut est un bearer sans débit garanti qui s’établit en même temps que la procédure d’attachement réalisée par la sous-couche EMM  : La sous-couche EMM de l’UE, lors de la demande d’attachement, envoie le message NAS ATTACH à la sous-couche RRC laquelle encapsule le message EMM dans le message RRC Connexion Setup. La sous-couche ESM demande en plus l’émission du message PDN Connectivity Request, comme le montre le tableau 1. Il s’agit d’une différence entre le réseau 3G et le réseau 4G, ce dernier profite de l’attachement pour demander la création de contexte de bearer et accélérer l’accès au réseau pour des demandes de sessions.

Se référer à l’article http://blogs.univ-poitiers.fr/f-launay/2015/05/19/emm-procedure-initial-attach-part-2/ pour plus de détail

Table 1 : RRC Connection Setup : ATTACH REQUEST

Après la procédure d’authentification (détaillé dans l’article …), le MME contacte le HSS (informe le HSS de la localisation du MME qui gère l’UE et le MME récupère le profil de l’UE dont les paramètres de QCI, MBR, …). A partir de cette information, le MME demande la création du bearer S1 et S5 (messages Create Session Request avec le SGW et Create Default Bearer Request portés par le protocole GTPv2-c et transmis respectivement au SGW et au PGW) avec la valeur de QoS du profil. Le PGW vérifie quant à lui les caractéristiques du bearer. Une fois les contextes de bearers S5 et S1 créés (ajout d’une nouvelle entrée dans la table de contexte avec un Identifiant de Chargement), le MME répond à la demande d’attachement de l’UE en transmettant via le protocole S1AP le message Initial Context Setup Request à l’intérieur duquel est encapsulé le message ATTACH ACCEPT et la demande d’activation du contexte de bearer par défaut (message ESM Activate Default EPS Bearer Context Request). L’eNb reçoit le message, rajoute l’entrée à sa table de contexte puis transfère le message EMM et ESM vers l’UE via le message RRC Connection Reconfiguration. Dans la description du message, on peut noter que le réseau indique les caractéristiques du bearer (QoS), l’adresse IP affecté au mobile, l’APN et l’adresse IP du PGW.

Table 2 : RRC Connection Reconfiguration : ATTACH ACCEPT et demande d’activation du bearer par défaut

L’UE répond par un message ESM Activate Default EPS Bearer Context Accept du message NAS ATTACH Complete encapsulé dans la réponse RRC Connection Reconfiguration

  • Etablissement d’une session sur le bearer par défaut : Ré-établissement du bearer par défaut

On suppose ici que l’UE est enregistré, les contextes de bearer ont déjà été créés au niveau du PGW et du SGW (via les messages Create Bearer du protocole GTPv2-c indiqués dans le paragraphe précédent). Ainsi, les paramètres de QoS sont déjà appliqués (remarquer le PGW lors de la création du bearer par défaut avait contacté le PCRF consécutivement à la requête CREATE SESSION REQUEST (etape 7 : http://blogs.univ-poitiers.fr/f-launay/2015/05/19/emm-procedure-initial-attach-part-2/). Par contre, suite à une période d’inactivité, la connexion S1 est libérée au niveau de l’eNb et l’UE n’a plus de ressources radios.

La première phase consiste à réaliser une connexion sécurisée entre l’UE et l’eNb  (RRC Connexion Establishment). La procédure RRC Connexion Establishment est la procédure permettant à l’UE d’informer le réseau qu’il souhaite établir une requête afin de passer de l’état RRC-Idle à l’état RRC-connect. Cette procédure RRC Connexion Establishment est constituée de trois messages : Le message RRC Connexion Request (UE vers eNb avec l’identité S-TMSI de l’UE), RRC Connexion Setup (eNb vers UE) suivi du message RRC Connexion Setup Complete (UE vers eNb). La sous-couche EMM de l’UE envoie le message NAS SERVICE REQUEST à la sous-couche RRC laquelle encapsule le message EMM dans le message RRC Connexion Setup Complete pour indiquer le type de session (session data, appel voix, réponse à un paging..). Le message est crypté en utilisant les clés de chiffrement connues depuis l’attachement (contexte de sécurité NAS comprenant les clés de chiffrement et d’intégrité NAS). La procédure d’authentification est optionnelle (pas d’authentification si la vérification d’intégrité du message est valide). L’eNb reçoit la requête NAS déclenchée par le téléphone et doit le re-transmettre vers le MME. Pour cela, l’eNB utilise le protocole S1AP et émet le message Initial UE Message. A ce stade, l’eNb crée une identité nommée eNb_UE_S1AP_ID pour identifier de manière unique l’UE. Il transmet alors cette information dans le message Initial UE Message et encapsule la requête NAS.

Lorsque le MME reçoit le message NAS Service Request (pour rappel ce dernier est déclenché par l’UE, reçue par l’eNB et retransmis par l’eNb), le MME démarre une procédure d’établissement du RAB, ce qui consiste à établir un lien DRB (Data Radio Bearer) et un bearer S1 entre l’eNb et le SGW.

  • MME –> eNb : L’établissement du contexte au niveau de l’eNb (seulement au niveau de l’eNb) est activé par le MME via le message Initial Context Setup Request. Le MME communique à l’eNb le numéro de tunnel TEID du SGW et les clés de chiffrements et les informations sur la QoS (UE-AMBR, GBR, MBR). Le MME encapsule dans ce message le NAS SERVICE ACCEPT à destination de l’UE

Table 3 : Paramètres échangés dans le message Initial Context Setup Request

Figure 3 : Initial Context Setup Request – Source EventHelix.com

  • eNb <-> UE : L’eNb accomplit une procédure de sécurité AS (afin de dériver les clés de chiffrement des données et d’intégrité sur la couche radio RRC) puis établit le bearer radio avec l’UE en 2 étapes grâce aux messages RRC suivants :
    • eNb -> Ue : message RRC Connection Reconfiguration. L’eNB alloue une identité DRB pour identifier le bearer
    • Ue -> eNb : Message RRC Connection Reconfiguration complete. L’UE confirme l’établissement de la connexion radio (SRB2, DRB)

Ces deux étapes (Sécurité AS – SRB et DRB, puis RRC Conn Rec) correspondent à la procédure Radio Bearer Establishment au niveau du call flow. Cela permet de modifier/configurer la connexion RRC.

A partir de ce moment, les données de trafic de l’UE peuvent être transmises vers le réseau (SGW et PGW). Le lien Uplink DATA est établi, mais pas le lien Downlink car le SGW ne connait pas l’identifiant de tunnel TEID de l’eNb. L’eNb attribut donc une identité du bearer S1 eNB TEID afin de transmettre cette identité au SGW.

L’eNb informe le MME de l’identifiant de tunnel crée pour ce flux de données dans le message Initial Context Setup Response (7) (consécutif donc au message Initial Context Setup Request). Le Message Initial Context Setup Response  contient les informations suivantes : Les Eléments d’Information de la couche Radio de l’UE, l’indicateur CSFB et SRVCC. Le MME informe ensuite le SGW de cet identifiant de tunnel via le message Modify Bearer Request (8). Le SGW doit donc répondre au MME pour lui confirmer l’activation du contexte de bearer par le message Modify Bearer Response (12). Les données de l’UE ayant été transmise via le lien Uplink, si l’UE s’est déplacé, le mécanisme de handover pour la partie Data (Plane User) permet la continuité du trafic montant. Par contre, le plan de contrôle doit aussi prendre en compte cette modification. Ainsi, si le type de RAT a changé (localisation du mobile sur la cellule – ECGI ou de TAI), il faut en informer le PGW via le message Modify Bearer Request (9), et si les règles PCC ne sont pas des règles prédéfinies (règles dynamiques), le PGW contacte le PCRF pour définir s’il faut modifier les règles PCC en fonction du nouveau RAT.

Figure 4 : Rétablissement du  bearer par défaut (référence : TS 23.401, chap 5.3.4.1 UE triggered Service Request)

  • Création d’un autre bearer : Bearer par défaut ou bearer dédié ?

Si une application de l’UE nécessite l’accès à un autre PGW alors, un deuxième bearer par défaut doit être construit (sous condition d’avoir les droits  au niveau du PGW). Dans les faits, l’UE lance une demande de connectivité PDN Connectivity Request vers le MME en précisant l’APN et la QoS, si la résolution au niveau du MME conduit au choix d’un autre PGW, la demande de connectivité sera établie vers ce PGW.

Figure 5 : UE requested PDN connectivity procedure

Attention, un même PDN peut être associé à plusieurs APN. Ainsi, si une application avec la même QoS nécessite une APN différente laquelle renvoie vers le même PGW, il n’y aura pas de création d’un nouveau bearer par défaut. Par contre, si les caractéristiques de QCI sont différentes, alors le réseau va créer un bearer dédié (l’UE peut avoir deux bearer par défaut ayant le même QCI mais avec des ARP différents).

Pour résumer, des bearers dédiés devront être établis si l’EPC décide de mettre en œuvre d’autres caractéristiques de bearer (GBR ou nouvelle valeur de QCI, ce qui nécessite la création d’un autre tunnel et par conséquent la sauvegarde de nouveaux contextes de bearer au niveau du PGW, SGW et eNb).

  • Création d’une session avec une QoS spécifique (Création d’un bearer dédié initié par l’UE)

On suppose le cas suivant : L’utilisateur souhaite lancer une session vers le PGW défini lors de la procédure d’attachement mais avec une valeur de QCI différente de celle définie pour le bearer par défaut. Si l’UE est au repos (mode ECM-Idle/RRC Idle), il doit activer la connexion RRC via la procédure RRC Connexion Establishment (pour rappel la procédure RRC Connexion Establishment est la procédure permettant à l’UE d’informer le réseau qu’il souhaite établir une requête c’est-à-dire pour passer de l’état RRC-Idle vers l’état RRC-connecte). La procédure procédure RRC Connexion Establishment est constituée de trois requêtes : Le message RRC Connexion Request (UE vers eNb), RRC Connexion Setup (eNb vers UE) suivi du message RRC Connexion Setup Complete (UE vers eNb). Dans ce dernier message, la couche RRC encapsule le requête EMM NAS Service Request afin d’établir une connexion sécurisée entre l’UE et le MME (procédure EMM).  Puisque l’UE souhaite établir un bearer dédié, il est nécessaire d’établir une connexion ESM, laquelle nécessite l’encapsulation du message NAS ESM Bearer Ressource Allocation Request délivré avec le message RRC Connection Reconfiguration. Nous avons déjà évoqué le message RRC Connection Reconfiguration lors de la procédure d’attachement avec encapsulation d’un message NAS, mais nous avons aussi vu que le message RRC Connection Reconfiguration permet aussi de définir des paramètres sur l’établissement du lien radio (PHR, DRX, …) Ici, l’UE est déjà attaché, par conséquent seule la sous-couche ESM encapsule la demande de création d’un bearer dédié.

Dans cette requête, l’UE envoie le QCI et le GBR, MBR désiré pour le lien UL et DL. Le MME reçoit le message et le transmet au SGW puis au PGW via le protocole GTP-C.

Figure 6 : Création d’un bearer dédié initié par l’UE

le PGW contacte alors le PCRF via Diameter. La requête CC-Request contient l’identifiant IMSI du mobile et la QoS demandée. Le PCRF regarde les détails dans sa table de souscription pour confirmer ou modifier la QoS demandée par le mobile ou contacte le SPR pour avoir le détail de la souscription du mobile.

Le réseau répond à la demande de l’UE par l’activation d’un bearer ou la modification du contexte d’un bearer, éventuellement d’un rejet de la demande.

Figure 7 : Activation d’un bearer dédié

 

  • Modification d’une session avec une QoS spécifique (Modification d’un bearer dédié)

L’UE va émettre le message Request Bearer Ressource Modification vers le MME. Cette requête permet à l’UE de demander une modification du bearer (modification d’un bearer par défaut, demande de création ou libération d’un bearer dédié). Si la demande est acceptée par le MME, ce dernier va mettre en place une procédure d’activation de bearer dédié.

Figure 8 : Modification d’un bearer

L’activation (ou création) du bearer dédié correspond à la mise en place de contexte de routage de bearer au niveau des entités PGW, SGW et eNb. L’étape 5 est présenté sur la figure 8.

 

  • Etablissement d’un bearer dédié en cours d’appel : Création d’un bearer dédié initié par le réseau

On suppose maintenant qu’un flux existe sur un bearer par défaut (ex application sur un serveur IP comme YouTube ou MyGoogle) et l’utilisateur souhaite activer un service supplémentaire (par exemple payer une VoD avec une QoS associée).

Dans ce cas, le serveur VoD va informer le PGW de la présence d’un nouveau flux de trafic nécessitant une QoS spécifique. La fonction PCEF au niveau du PGW va décider la création d’un bearer dédié à partir des règles de PCC indiquées par le PCRF (QCI=1, GBR, ARP=1, …). Le PGW vérifiera le débit entrant du PDN vers l’UE

Le PGW va envoyer une demande de création d’un bearer dédié (via le message Create Bearer Request) vers le SGW puis relayé au MME. Le MME déclenche la procédure d’établissement d’un E-RAB via l’application S1 AP E-RAB Setup Request avec les caractéristiques de QoS définies par le PCRF.

L’eNb, en cas de non saturation, accepte la demande et informe l’UE de la demande d’un bearer radio via le message RRC Connection Reconfiguration, lequel encapsule le message NAS ESM Activate Dedicated EPS bearer.

Table 4 : RRC Connection Reconfiguration

Si le bearer est crée, on acquitte le MME par le message RRC Conn Reconf Complete, et le MME acquitte le PGW par le message Create Bearer Response, et enfin le PGW informe le PCRF.

Figure 9 : Création d’un bearer dédié à partir d’une application utilisant le bearer par défaut (sur une connexion existante)

Application à la VoLTE

Ce paragraphe exploite l’article suivant : https://www.linkedin.com/pulse/dedicated-bearer-setup-lte-impact-volte-precondition-arindam-ghosh

  • Bearer par défaut dans le réseau Home

A l’allumage, le mobile démarre la procédure d’attachement. Si les données de souscriptions permettent d’identifier l’APN IMS comme l’APN pour le bearer par défaut sans autre APN alors le MME connecte l’UE vers l’APN IMS. La particularité de ce bearer est la valeur de QCI=5. Le MME fournit également l’adresse IP du P-CSCF à l’UE.

Si le mobile se connecte sur un APN non IMS au cours de la procédure d’attachement, alors il se connectera ultérieurement à l’APN IMS par une procédure d’établissement de bearer. Dans la procédure de demande de connexion PDN, le mobile informe l’APN IMS et demande l’établissement d’un bearer par défaut pour la signalisation téléphonique SIP. LE MME établit le bearer par défaut (QCI=5) et fournit l’adresse du P-CSCF au mobile.

  • Bearer par défaut dans le réseau Visité

Si le mobile est en roaming, la question est de savoir si le réseau visité supporte l’IMS.

  • Le réseau visité supporte l’IMS

On suppose évidemment que le réseau home supporte l’IMS (sinon la question ne se poserait même pas), alors le MME du réseau visité propose à l’UE de se connecter au PGW du réseau visité pour les appels voix et donc au P-CSCF du réseau visité.

  • Le réseau visité ne supporte pas l’IMS

On suppose évidemment que le réseau home supporte l’IMS (sinon la question ne se poserait même pas), alors le MME du réseau visité propose à l’UE de se connecter au PGW du réseau HOME et donc au P-CSCF du réseau Home mais le MME refuse les appels voix sur IMS. Toutefois, le mobile pourra utiliser le réseau Home IMS pour d’autres services comme par exemple le SMS.

  • Rétablissement du bearer par défaut pour transmettre les messages SIP

L’application VoIP échange des flux SIP vers le réseau IMS afin de joindre le correspondant appelé et de négocier les codecs si celui-ci est joignable.

  • L’appelant utilise le bearer IMS par défaut pour transmettre la signalisation SIP de demande d’invitation d’appel vers l’appelé (figure 1).
  • Le réseau IMS contacte le PGW de l’opérateur de l’appelé (données entrantes) pour transmettre la signalisation SIP vers l’appelé. Le réseau de l’appelé émet une requête de paging (non présenté dans cet article), l’UE appelé demande le rétablissement du bearer par défaut (figure 1).

L’UE appelant envoie dans le message SIP INVITE la liste des codecs compatibles vers l’UE appelé. L’UE appelé reçoit la liste des codecs et n’en retient qu’un. Il informe l’UE appelant du codec choisit.

  • Création du bearer dédié de l’appelant et de l’appelé.

A ce stade, l’appelant connait le type de codec, le réseau peut donc demander la création d’un bearer dédié avec le codec désiré et le réseau créé également un bearer dédié du coté de l’appelé.

  • Appelé : Figure 9 – Création d’un bearer dédié initié par le réseau
  • Appelant : Figure 9 – Création d’un bearer dédié initié par le réseau

Dans ce cas, l’AF (il s’agit du P-CSCF) informe le PCRF d’une modification de la session IP-CAN en indiquant les paramètres du nouveau bearer. Le PCRF envoie une requête IP-CAN session modification vers le PGW, lequel décide contacte le MME via une requête Create Bearer Request. Le MME analyse la demande et si elle accepte la demande, envoie un E-RAB setup request au eNb. Enfin, l’eNb envoie une requête RRC Connection Reconfiguration vers l’UE.

  • Fonction du PCRF

Dans les deux cas précédent, le PGW contacte alors le PCRF via Diameter. La requête CC-Request contient l’identifiant IMSI du mobile et la QoS demandée. Le PCRF regarde les détails dans sa table de souscription pour confirmer ou modifier la QoS demandée par le mobile ou contacte le SPR pour avoir le détail de la souscription du mobile.

Le PCRF peut recevoir des requêtes de la part d’une entité extérieure (AF : Application Function comme par exemple le P-CSCF) ou de la part du mobile afin de mettre en œuvre un service utilisant un bearer dédié (meilleure qualité que le bearer par défaut).

Dans tous les cas, le PCRF définie une règle PCC (préétablie ou établie à la volée) et retourne le QCI/ARP pour établir un bearer dédié. Il transmet aussi les paramètres de taxation au PCEF.

Si le PGW reçoit une valeur de QCI et un ARP tous deux identiques aux paramètres d’une session déjà en cours, alors le PGW demande la modification du bearer actuelle pour insérer ce nouveau flux (augmentation du débit). Le PGW réalise le mapping entre le flux de données (SDF : Service Data Flows) et le bearer correspondant.

Le PCRF assure aussi la fonction de Gating, c’est-à-dire peut bloquer un type de paquet ou tous les paquets (par exemple lors du dépassement de son forfait) au niveau du PGW.

La fonction Gating est une fonction qui détermine si oui on non un paquet peut traverser le PGW.

 

Attachement au réseau 4G : Différents scénarios

Dans deux articles écrits en mai 2015, j’avais décris la procédure d’attachement au réseau 4G : http://blogs.univ-poitiers.fr/f-launay/2015/05/05/emm-procedure-initial-attach/ et http://blogs.univ-poitiers.fr/f-launay/2015/05/19/emm-procedure-initial-attach-part-2/

Je vais revenir sur ces deux articles afin de mieux expliquer les différents scénarios s’appliquant au mobile lorsque ce dernier fait une demande d’attachement.

La procédure d’attachement nécessite 2 étapes clés:

  • L’identification de l’UE auprès du MME.
  • Authentification de l’UE

L’identification consiste, de la part du mobile, à fournir un identifiant lequel est transmis en clair sur l’interface air jusqu’au MME. Il s’agit donc d’un message NAS. Cet identifiant est transmis en clair, c’est à dire non crypté. (Imaginez en effet que l’UE crypte son identifiant par une clé Kc connu par le MME. Le MME n’ayant pas connaissance de l’UE qui lui a transmis le message devrait tester toutes ses clés Kc pour récupérer l’identifiant).

L’identifiant permettant de connaitre l’UE peut être :

  • L’identifiant IMSI
  • L’identifiant GUTI.

Ces deux identifiants ont été décrits dans l’article suivant : http://blogs.univ-poitiers.fr/f-launay/2015/05/06/imsi-tmsi-gummei-guti/

Le GUTI, Global Unique Temporary Identifier permet d’identifier de manière unique l’UE. Cet identifiant est constitué d’un code unique fourni par le MME, nommé M-TMSI. Le M-TMSI permet donc de connaître l’UE au niveau du MME. En rajoutant le code d’identifiant du MME, du code identifiant le pool MME, l’identifiant du réseau opérateur (MNC) et le code pays (MCC), le GUTI permet donc de connaître le MME sur lequel était enregistré l’UE auparavant.

Ce dernier point est important, lorsque l’UE se détache du réseau 4G (lorsqu’il envoie un message DETACH request), les contextes de commutation de bearer sont supprimés au niveau du PGW et du SGW mais :

  • l’UE conserve son contexte de sécurité NAS, le GUTI et le tracking area
  • le MME conserve le contexte de sécurité NAS associé au GUTI.

L’authentification consiste à vérifier l’identité de l’UE, soit à partir du message d’intégrité NAS soit à partir d’une procédure d’authentification mutuelle nommée AKA. Cette procédure permet au réseau de vérifier l’UE et pour l’UE de valider le réseau. Le choix de la procédure d’authentification est dictée par la manière dont l’UE s’identifie au réseau.

Si l’UE transmet son identifiant IMSI, dans ce cas le réseau applique la procédure d’authentification AKA mais si l’UE transmet son identifiant GUTI, le réseau est alors en mesure de récupérer son contexte de sécurité NAS.

Le contexte de sécurité NAS permet de garantir un échange authentifié entre l’UE et le MME (NAS Message) en chiffrant les données via une clé de chiffrement Knasenc et de valider l’intégrité du message via une clé d’intégrité Knasinc. Ces deux clés ont été générées au cours d’un précédent attachement avec l’identité IMSI.

Détachement

Nous allons maintenant nous intéresser à la spécification 23.401. (version 8 ira très bien).

Nous avons vu précédemment que l’UE pouvait s’identifier selon son IMSI ou son GUTI. Or, pour s’identifier avec le GUTI, le téléphone doit avoir été enregistré. Ainsi, aussi étrange que celà puisse paraître, pour comprendre cette procédure d’attachement, je vais commencer par expliquer la procédure de détachement, c’est à dire lorsque l’UE se désenregistre du réseau.

La procédure de détachement (Detach procedure – section 5.3.8 p70) peut être déclenchée par l’UE ou par le réseau.

L’UE peut faire une demande de détachement lorsque l’utilisateur éteint son téléphone ou bascule en mode avion. Dans ce cas, l’UE émet une requête NAS avec un indicateur « Switch Off » et le MME répond par un Detach Accept. Les contextes de commutation sont supprimés au niveau du SGW et PGW, le MME conserve quant à lui le contexte de l’UE (GUTI et clé de chiffrement/clé d’intégrité lié avec le GUTI).

Le MME peut aussi faire une demande de détachement pour un UE,

  • soit une demande implicite (UE est implicitement détaché) qui a lieu lorsque l’UE n’a pas transmis ou reçu de données depuis un certains temps (implicit Detach Timer = T3423 + 4 mn si l’ISR – Idle Mode Signaling Reduction est activé  )
  • soit une demande explicite par exemple pour réaliser de l’équilibrage de charge sur un autre UE

Jusqu’à présent, le MME a conservé le contexte NAS et le GUTI de l’UE. Au bout d’un certain temps

La fonction Purge (Purge Function cf section 5.3.9.3 p74) permet au MME d’informer le HSS qu’il a supprimé le contexte NAS et le GUTI. Ce dialogue est réalisé par le protocole Diameter via le message PUR/PUA (Purge Request/Answer). Dans le cas de cette procédure, le MME n’a plus de contexte concernant l’UE.

Attachement

Il nous reste plus qu’à étudier les différents scénarios pour la procédure d’attachement. Il y a 5 cas en tout :

1 – L’UE se connecte pour la première fois : Il transmet son identifiant IMSI

2 – L’UE se connecte avec son identifiant GUTI

  1. Sa demande est transférée au MME sur lequel il était précédemment connecté
    1. Le MME a conservé son contexte
    2. Le MME n’a plus son contexte
  2. Sa demande est transférée à un MME différent de son précédent MME
    1. Le MME a conservé son contexte
    2. Le MME n’a plus son contexte

Attachement

Il faut bien se rappeler que quelque soit le scénario, la première étape consiste à s’identifier, donc à transmettre en clair son identifiant. Ensuite, si le mobile transmet son IMSI, la requête NAS de demande d’attachement n’est pas chiffrée.

Par contre, si le mobile transmet son GUTI, la suite du message NAS est chiffrée et une clé d’intégrité est rajoutée.

Voyons les différents cas.

CAS 1 – L’UE se connecte pour la première fois : Il transmet son identifiant IMSI. Dans ce cas, le réseau effectue une authentification AKA. J’invite le lecteur à se référer à l’article http://blogs.univ-poitiers.fr/f-launay/2015/05/05/emm-procedure-initial-attach/

2 – L’UE se connecte avec son GUTI.

CAS 2 : L’eNb analyse le GUTI, ce dernier est connecté au MME via un lien S1-MME, il peut donc relayer la requête NAS de demande d’attachement au MME. Le GUTI est envoyé en clair, la requête NAS est chiffré et une clé d’intégrité est rajouté.

CAS 3 : L’eNb analyse le GUTI, ce dernier n’est pas connecté au précédemment MME. La requête est donc transmise à un nouveau MME, et ce dernier vient interroger l’ancien MME. Le GUTI est envoyé en clair, la requête NAS est chiffré et une clé d’intégrité est rajoutée correspondant à l’ancien MME. Le nouveau MME transférant le tout à l’ancien MME. On suppose que ce MME n’a pas conservé le contexte ou la clé d’intégrité n’est pas correcte, dans ce cas le MME informe le nouveau MME qu’une procédure d’authentification doit être réalisée. Le nouveau MME demande à l’UE de s’identifier à nouveau via son identifiant IMSI

CAS 4 : L’eNb analyse le GUTI, ce dernier est connecté au MME via un lien S1-MME, il peut donc relayer la requête NAS de demande d’attachement au MME. Le GUTI est envoyé en clair, la requête NAS est chiffré et une clé d’intégrité est rajouté. Le MME est capable de déchiffrer le message et la clé d’intégrité est correcte. Dans ce cas, le MME accepte la demande d’attachement.

CAS 5 : L’eNb analyse le GUTI, ce dernier n’est pas connecté au précédemment MME. La requête est donc transmise à un nouveau MME, et ce dernier vient interroger l’ancien MME. Le GUTI est envoyé en clair, la requête NAS est chiffré et une clé d’intégrité est rajouté. L’ancien MME est capable de déchiffrer le message et la clé d’intégrité est correcte. Dans ce cas, l’ancien MME informe le nouveau MME que la demande peut être acceptée.

Attachement1Attachement2Selon les différents cas, la procédure d’authentification AKA n’est pas nécessaire. Voici une dernière figure résumant les 5 cas possibles et le dialogue entre l’UE et le MME

Attachement3

 

La Bande des 700 MHz

Je vous avais soumis l’an dernier des prévisions de consommation de volumes de données jusqu’en 2018, nous allons maintenant nous appuyer sur les chiffres de volumes consommés par les clients sur leur téléphone mobile entre le 2ème trimestre 2011 et le 2ème trimestre 2014. Au regard de la courbe, le volume est en croissance exponentielle (environ 70% d’augmentation chaque année) et on note une multiplication par 5 par rapport à 2011.

Consommation_data

Cette augmentation de données se justifie aussi par une augmentation de débits sur l’interface radio, mais la problématique se pose sur le partage d’accès et l’évolution à terme de la 4G+ vers la 4G++.

Les prochains smartphones pourront se connecter sur 3 bandes du réseau LTE permettant ainsi de profiter d’une bande de 10 MHz autour de 1800 MHz, 20 MHz autour de 2600 MHz et 10 MHz autour de 800 MHz. Cependant, le LTE-Advanced suggère l’agrégation de 5 canaux de 20 MHz. Or, le partage actuel du spectre ne rend pas cette solution envisageable à ce jour, comme le montre les tableaux de répartition de fréquence ci-dessous :

Spectre_900

*Le spectre 900 MHz est utilisé pour la 3G (re-farming) mais pas pour la 4G

1800_erreur

 

Modification du 26/10/2015 (afin de comprendre les remarques de cet article, j’ai laissé la figure précédente même fausse, la correction étant néanmoins apportée. Merci au lecteur d’avoir notifié cette erreur).

1800

*Le spectre 1800 MHz a été ré-attribué pour permettre à Free d’avoir une bande pour réaliser du re-farming 4G. Voici en effet l’évolution des bandes 1800 MHz (Chaque opérateur fournit 5 MHz de bande à Free à 1800 MHz lorsqu’il active le Re-farming sur cette bande). La figure ci-dessous était une projection de l’évolution de l’attribution des fréquences. Je rappelle que

*Orange et SFR conservent la possibilité de demander à tout moment une levée anticipée des restrictions technologiques dans la bande 1800 MHz, s’ils souhaitent utiliser la 4G dans cette bande avant la date du 25 mai 2016.

Spectre_1800

Pour répondre au lecteur (cf. remarques en fin de l’article), effectivement seul Bouygues a fait une demande anticipée de re-farming. Cette demande a été acceptée par l’ARCEP le 14 mars 2013. Par conséquent, en 2012, Free ne disposait pas encore de 5 MHz de Bande, et la libération des bandes par Bouygues pour SFR sur le territoire en France était planifiée entre Octobre 2013 et Juillet 2015).

Spectre_2100

*Le spectre 2100 MHz n’est réservé à ce jour que pour la 3G

Spectre_2600

Le spectre 2600 MHz a été vendu en septembre 2014 pour la 4G en complément du spectre 800 MHz vendu en décembre 2014 pour la 4G (Free n’a pas acquis de licence dans la bande de 800 MHz – leur enchère n’était pas assez élevée pour avoir un lot).

Spectre_800

Bande des 700 MHZ

A ce jour non, mais une 4ème bande sera bientôt exploitée pour la 4G permettant ainsi aux opérateurs d’envisager l’agrégation de 4 bandes et atteindre 70 MHz de bande.

La bande envisagée est le 700 MHz car elle déjà exploitée par des opérateurs sur d’autres continents. Les UE (smartphone) sont donc déjà équipés de modules à 700 MHz.

Cependant, la bande de 700 MHz (694 MHz à 790 MHz)  est actuellement attribuée à la TNT en France. A la date du 10 décembre 2014, par communiqué de presse, le Premier ministre a précisé les modalités de mise en oeuvre des modalités de réallocation des fréquences de la bande 700 MHz aux opérateurs mobiles.

En terme de date, le gouvernement souhaite attribuer des autorisations d’utilisation de bloc de 5 MHz dans la bande 700 MHz aux opérateurs mobiles en décembre 2015. Au total 30 MHz de bande. Les bandes 703-733 MHz et 758-788 MHz sont utilisées en mode de duplexage fréquentiel (mode FDD), la transmission de la station terminale (liaison montante) étant située sur les fréquences 703-733 MHz, et la transmission de la station de base (liaison descendante) étant située sur les fréquences 758-788 MHz.

Toutefois, ces bandes ne seront libérées qu’entre le 1er octobre 2017 et le 30 juin 2019, à l’exception de quelques zones où ces derniers pourraient les utiliser dès avril 2016.

Le jeudi 18 juin, L’ARCEP a transmis pour avis aux membres de la commission consultative des communications électroniques (CCCE) les projets de décisions qu’elle a élaborés en vue de l’attribution de la bande 700 MHz.

Que deviendra la TNT?

La TNT est donc affectée par cette réallocation de fréquence. Or, avec le nombre de chaînes qui diffusent sur la TNT (en prenant en compte les chaînes HD), il est nécessaire d’optimiser le type de codage utilisé actuellement pour les chaînes non HD. Ainsi, la technique Mpeg2 va disparaître et les transmissions se feront en Mpeg4. Cela va nécessiter le remplacement de certains décodeurs et de télévision, pour savoir s’il faut remplacer votre télévision, il suffit de regarder si votre télévision peut décoder les chaînes HD. Si oui, vous avez un décodeur Mp4.

SRVCC – Single Radio Voice Call Continuity – Suite

Nous allons maintenant étudier le mécanisme SRVCC et ses évolutions eSRVCC et rSRVCC en illustrant le concept par une approche pratique.

On suppose que l’UE1 souhaite contacter l’UE2. L’UE1 est sur un réseau 4G, vis à vis du réseau IMS, qui est le réseau home, l’UE1 est dans un réseau visité.

L’UE1 souhaite appeler l’UE2. L’UE1 est compatible avec le mécanisme SRVCC et l’appel est évidemment contrôlé par le réseau IMS. Ainsi, après un échange de signalisation SIP, après avoir construit les bearers, l’appel s’effectue. L’UE1 se déplace dans le réseau visité et s’éloigne du eNB, la puissance reçue s’affaiblit.

  1. L’eNb décide alors de mettre en oeuvre le mécanisme SRVCC en envoyant une requête au MME
  2. A partir de cette requete, le MME transmet la demande au MSC afin que ce dernier alloue les ressources au niveau du domaine CS autrement dit avec le RNC puis le Nb.
  3. Le MSC demande la création d’une connexion avec le SCC AS dans l’objectif de transférer la voix (paquet IP) du réseau LTE vers le réseau 3G donc pour transférer la session du PGW vers le MSC.

SRVCC

A ce stade, pour le mécanisme SRVCC définit dans la R8, la procédure est la suivante :

  • Le SCC demande à l’UE de changer la destination de ses messages SIP de l’UE1 vers le MSC.

En parallèle,

  • Le MSC informe le MME de la réservation de ressource dans le domaine CS.

A partir de ce moment, le MME peut demander à l’UE1 de basculer vers le réseau 3G (Handover). Après le Handover, la signalisation SIP est transmise du SCC vers le MSC, le SCC est le point d’ancrage pour la signalisation, et le média pour la voix est envoyé de l’UE2 vers le MSC. L’UE2 est donc le point d’ancrage pour le média.

Or, la modification de l’adresse IP de destination (UE1 vers MSC) pour le média de la voix provoque de nombreuses pertes de paquets et une latence puisque toutes les entités du réseau IMS de l’UE2 et l’UE2 doivent modifier leur chemin de requêtes SIP

En simplifiant la figure avec les entités concernés, le chemin de signalisation et d’appel est représenté par la figure ci-dessous.

SRVCC_fig4

eSRVCC

Le principal défaut  du SRVCC est le suivant : Lorsqu’un HandOver affecte l’UE1 dans son réseau visité (ou en roaming), cela impacte les messages SIP et RTP de l’UE2. Le mécanisme eSRVCC consiste à rajouter des points d’ancrage au niveau du réseau visité de l’UE1 afin que tout handover de l’UE1 soit transparent pour l’UE2.

Ainsi, au niveau du eSRVCC, 2 nouvelles entités ont été rajoutées pour avoir un point d’ancrage dans le réseau visité à savoir :

  • ATCF : Point d’ancrage pour la signalisation
  • ATGW : Point d’ancrage pour le média

SRVCC_fig5

 

 

 

 

 

 

VoLTE – Principe de base

J’ai eu souvent l’occasion de le répéter, le réseau 4G est un réseau tout IP ne permettant pas les appels voix par commutation de circuit comme c’est le cas pour la 2G ou 3G. Dans le précédent article, j’ai présenté le mécanisme permettant de quitter le réseau 4G et se connecter sur le réseau 2G/3G afin d’établir (émettre ou recevoir) un appel voix. Il s’agit du CSFB.

La VoLTE ou Voix sur LTE désigne le principe de service voix sur le réseau à commutation de paquet IP mais acheminée via le réseau LTE/SAE jusqu’au PGW pour être pris en charge par le réseau IMS.

Deux cas d’études  se présentent à nous :

  • L’APN pour le réseau IMS est il le même que l’APN pour accéder à Internet, autrement dit, la session Internet et la session VoLTE passent elles par le même PGW
  • Deux APN différents, un PGW pour accéder à Internet et un PGW pour accéder à l’IMS.

Principe général

Je ne vais exposer ici que le principe général, l’un des points clés est la réservation de ressources entre le réseau LTE et la négociation au niveau de l’entité P-CSCF de l’IMS. Je conseille de suivre la formation Nexcom : De l’ingénierie radio au service voix pour avoir une formation détaillée sur la VoLTE, l’IMS le RCS, et les services.

Pour comprendre le principe du VoLTE, il est nécessaire d’avoir des notions sur :

  • Le réseau IMS et la signalisation téléphonique SIP
  • Le réseau coeur 4G  et réseau d’accès – SAE – LTE
  • La SIG 4G et la mise en place de bearer (défaut et dédié)
  • La négociation de codec (SDP) et la réservation de ressource (PCRF – SPR)

Phase 1 : Procédure d’attachement – Création du Default bearer 

Lors de la procédure d’attachement, le MME met en place un bearer par défaut entre l’UE et le PGW permettant l’accès au réseau IMS. Le bearer par défaut est défini avec une QoS définie par son QCI=5.

defaultbearer_ims

On suppose que le PGW permet d’accéder au réseau Internet et au réseau IMS.

La mise en place du bearer est réalisé via de la SIG 4G permettant la création d’un contexte S5 entre le SGW et le PGW, d’un context S1 entre le SGW et l’eNb et d’un context RAB entre l’UE et l’eNb.

Phase 2 : Signalisation Téléphonique – Enregistrement

Une fois le context crée, l’UE s’enregistre au niveau de l’IMS. Il envoie une requête SIP REGISTER au PGW qui le transfère au premier point de contact du réseau IMS (P-CSCF). Ce dernier redirige la requête vers l’I-CSCF et après avoir définie les capabilités du serveur d’enregistrement au niveau du HSS, l’I-CSCF récupère l’adresse du serveur S-CSCF. Suite à des échanges de SIG Téléphonique SIP (Register, ACK, …) l’UE s’enregistre au niveau du S-CSCF.

Phase 3 : Signalisation Téléphonique – Appel

En règle général, le context S1 et RAB sont relâchés, à moins que l’utilisateur passe immédiatement un appel téléphonique après avoir allumé son portable.

Dans le premier cas, il faut re-établir le context RAB et S1. Une fois le context EPS Bearer default construit, l’UE envoie des requêtes SIP (Invite, …) pour demander la mise en relation avec son correspondant.  La requête SIP INVITE permet de chercher à joindre le correspondant et négocier le type de codec pour l’appel (SDP).

Lorsque le réseau IMS a négocier le type de codec (autrement dit la Bande Passante à garantir), le réseau LTE doit mettre en place un bearer dédié sur lequel la voix sera routée.

Phase 4 : Création du bearer dédié

On parle de Bearer Dédié car le bearer se différencie du bearer par défaut uniquement par la QoS (QCI=1). En effet, les adresses IP/Sources sont les mêmes.

La création du bearer dédié est réalisée par de la SIG 4G (Message NAS ESM PDN Connectivity entre l’UE et le MME puis Création des bearer : Create Session Request, S1-AP Bearer Setup Request, RRC connection Reconfiguration Request)

Dedicated_bearer

Si au cours de l’appel l’UE souhaite transmettre un média (document, tchatter) ou activer la vidéo, le réseau 4G mettra en place un autre bearer dédié (selon la disponibilité, les priorités et la pré-emption).

CSFB : Call Switch FallBack (2)

Dans le précédent article, CSFB : Call Switch FallBack (1), je vous ai présenté le mécanisme de CSFB avec comme exemple un MTC.

De manière général, le call flow est le suivant :

CSFB_callflow_complet

Le point critique du CSFB est la durée du processus, et principalement le temps mis par l’UE pour quitter la connexion 4G et se retrouver connecté en 3G.

CSFB_time1

Ces chiffres ne reflètent pas la réalité, cette figure est extraite d’un document Huawei qui propose une autre technique nommée Ultra-flash CSFB.

Il y a en réalité plusieurs mécanismes qui ont été proposés pour se rapprocher de la durée de connexion de service téléphonique sur le réseau 2G qui sont :

  • Redirection
    • Basic
    • SIB Skipping
    • SI Tunneling
  • Handover

Différences entre handover et redirection

Dans le cas de la procédure de Handover, la cellule cible Nb est informée (selon le type de Handover, soit par le RNC, soir par le MSC/VLR) de la prise en charge d’un UE. Des mesures inter-RAT (IRAT : Radio Access Technology) permettent à l’UE de mesurer la puissance du signal des cellules pouvant prendre en charge l’UE afin de guider le HandOver (HO). C’est au cours de la requête RRC Connection Reconfiguration (optional Measurement reports) que l’eNb demande à l’UE de lui fournir des mesures sur les cellules voisines.

Dans le cas de la procédure de Redirection, l’UE est informé du réseau d’accès sur lequel il doit se re-connecter, mais le réseau n’est pas informé. Par conséquent, l’UE est dans l’obligation de trouver des informations sur sa nouvelle cellule. Ainsi, une fois sur la cellule, l’UE initie des mesures de puissance des fréquences  balises puis, récupère les informations SIB diffusées en broadcast par la cellule cible.

Parmi les deux technique, les mesures ont montrées que la procédure de redirection est plus rapide que le HandOver pour le GSM, mais à l’inverse est moins rapide en 3G.

CSFB_time

Le tableau met en avant différents mécanismes de redirections déjà évoqués dans l’introduction de l’article à savoir :

  • Basic
  • SIB Skipping
  • SI Tunneling

Redirection Basic

R8  Release with Redirection—Basic, l’UE récupère et interprète l’ensemble des SIB avant de faire la demande de connexion à la cellule cible.

SIB Skipping

R8 Release with Redirection—SIB Skipping
(3G), l’UE n’a pas besoin de lire tous les SIB mais seulement les SIBs 1, 3, 5 et 7, en ignorant les autres SIB. Toutefois, les informations concernants les cellules voisines et transmises sur le SIB11 et SIB 12 ont été transmises à l’UE lors des messages de mesure de contrôle et transmise par le Nb une fois l’UE connecté.

R9 Enhanced Release with Redirection—SI
Tunneling

Les informations SIB de la cellule cible sont transmises via un tunnel dans le message RRC Connection Release transmise par l’eNb source.

La solution déployée à ce jour est la redirection basique ou SIB Skipping.

Nous présentons ici le cas du R8  Release with Redirection—Basic

CSFB_rrc

Dans cette capture, on s’aperçoit que finalement le délai apporté par le CSFB est de 3 secondes et 457 ms (jusqu’au Alerting)

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é.

Etats RRC – ECM – EMM

Dans un article précédent, Protocole RRC, j’avais conclu par « Le protocole RRC a pour but est de transférer les informations de signalisation entre l’UE et la station de base » (Le protocole S1AP permet ensuite d’acheminer la signalisation au MME), ce qui avait déjà été présenté via cette figure lors de l’article Protocole NAS et AS :

asnas4G

En s’appuyant sur l’article Protocole NAS et AS, j’avais décrit les procédures EMM, ECM et ESM dans l’article EMM, EPS Mobility Management. Il est temps maintenant de conclure cette série d’article et notamment finalisons l’étude de cette figure :

emm_1

Les états EMM et ECM ont été étudiés plus en détail dans l’article ECM, EPS Connexion Management.

Jusqu’à présent, j’avais occulté le protocole RRC alors que ce dernier porte la signalisation NAS. Mais, l’état RRC du mobile évolue de manière duale avec l’état ECM

La figure suivante montre les états de transition entre l’EMM et l’ECM/RRC. Comme on peut le constater, l’état ECM et RRC sont identiques.

Figure 2. EMM State Transition

Cette figure est expliquée dans l’article ECM EPS Connection Management, mais revenons sur les différents états :

Etat A : EMM Deregisterd, ECM/RRC Idle – L’UE vient de s’allumer pour la première fois après avoir souscrit l’abonnement ou allumé après avoir été éteint plusieurs jours. Aucun context UE n’existe sur le réseau LTE

Etat BEMM Deregisterd, ECM/RRC Idle – L’UE s’allume après avoir été éteint pendant un court laps de temps (timer non connu à la rédaction de cet article) ou l’ECM est coupé suite à une perte de la connexion radio

Etat CEMM Registerd, ECM/RRC Connected – L’UE est enregistré sur le réseau LTE et utilise des services. La mobilité est géré par un handover (cellule à cellule pour ne pas couper le trafic)

Etat DEMM Registerd, ECM/RRC Idle – L’UE est enregistré sur le réseau LTE mais n’utilise aucun service. La mobilité est géré par une procédure de reselection de cellule lorsque le mobile passe d’un TAU à un autre.

Quand l’UE s’est attaché au réseau (cf article EMM – Initial Attach), il passe à l’état EMM-Registered et construit le bearer par défaut. Ce bearer est composé de trois partis (cf article BEARER EPS) :

  • DRB : Data Radio Bearer
  • S1 Bearer
  • S5 Bearer

Ces 3 bearers sont établis et restent activés dans l’état C, ECM/RRC Connected – EMM Registered quand l’utilisateur accède à un service et donc des données doivent être échangées.

Mais, dans l’état D, EMM Registerd, ECM/RRC Idle, ou il n’y a plus de trafic utilisateur, seul le bearer S5 est établi et reste actif.

Etat_EMM_ECM

Bearer EPS

Lors des articles précédent, nous avions décrit le rôle de l’ESM et la mise en place d’une session EPS. Nous allons maintenant expliquer la mise en place de bearer pour le trafic utilisateur.

I) Généralité sur le Bearer EPS

Le bearer EPS est un tuyau (tunnel) construit entre l’UE et le P-GW selon les caractéristiques contenues dans l’EPS session. Le premier bearer EPS construit, nommé default bearer EPS est mis en place lors de la procédure d’enregistrement.

Un bearer EPS est un tuyau caractérisé par des paramètres de QoS car les applications n’ont pas les mêmes besoins : Certaines applications comme le streaming, la visio et la phonie nécessitent un débit garanti (GBR) alors que  le browsing et le téléchargement se suffisent de Best Effort (Débit Non Garanti). On peut envisager à terme l’attribution de critères pour différencier les users premium, gold ou silver.

Pour différencier les bearer, les flux sont identifiés par deux critères :

  • QCI : QoS Class Identifier que l’on traduit par Identifiant de Qualité de Service
  • ARP : Allocation and Retention Priority est la priorité d’allocation et de rétention.

Ces critères sont spécifiés lors de la mise en place du PDN connection (EPS session). Pour plus de renseignement, se référer à l’article ESM – EPS Session Manager

Figure 1. Overview of Session Bearer IDs

Le Bearer EPS traverse plusieurs interfaces, sur chacune de ces interfaces un bearer de niveau inférieur est établi entre les équipements de proche en proche : Data RAdio Bearer, S1 Bearer et un S5 Bearer.

II) Différents Bearer physique

Chaque bearer est identifié par l’identifiant de tunnel TEID (Tunnel Endpoint ID) sur chacune des interfaces. Evidemment, les paramètres CQI/ARP sont identiques sur chaque bearer mis en place pour une EPS session donnée. N’oubliez pas que l’EPS session se charge de gérer les flux sur chaque équipement, autrement dit gère les Bearer entre l’UE-eNb-SGW-PGW.

L’utilisateur pouvant lancer plusieurs applications simultanément, plusieurs EPS bearer peuvent être établis pour un même utilisateur. Chaque EPS bearer est identifié par l’EPS bearer ID, lequel est alloué par le MME.

  • [UE] – [eNB]: Data Radio Bearer (DRB)

EPS bearer est établi sur l’interface LTE-Uu. Le trafic utilisateur (IP packet) est délivré dans le DRB. Differents DRBs sont identifiés par le DRB ID alloués par le eNb

  • [eNB] – [S-GW]: S1 bearer

EPS bearer établi sur l »interface sur l’interface S1-U interface. Le trafic utilisateur est délivré via un tunnel GTP (GTP-U)  Différents S1 bearers sont identifiés par le TEID, qui est alloué par les équipements périphérique (eNB et S-GW).

  • [S-GW] – [P-GW]: S5 bearer

EPS bearer est établi sur l’interface S5.. Le trafic utilisateur est délivré via un tunnel GTP (GTP-U)  Différents S5 bearers sont identifiés par le TEID, qui est alloué par les équipements périphérique (S-GW et P-GW)

  • [UE] – [S-GW]: E-RAB bearer

E-RAB est un bearer logique entre l’UEet le S-GW. Il est constitué du DRB et du S1 bearer

III) Deux types d’EPS Bearer

Nous avons défini au cours du premier paragraphe un EPS bearer, il existe deux types d’EPS Bearer :

  1. EPS Bearer par défaut : Default bearer
  2. EPS Bearer dédié : Dedicated bearer

Figure 2. EPS Bearer Types

Je rappelle que le bearer par défaut est établi pour chaque UE lors de la procédure d’attachement (enregistrement) au réseau. Nous verrons plus en détail le call flow dans un prochain article.

Le bearer par défaut (Default Bearer) est établi avec les paramètres QCI et ARP fournis par le MME. Ces valeurs sont définies par l’abonnement de l’utilisateur dont les données de souscriptions sont sauvegardées dans le HSS. Le bearer par défaut fourni une connectivité IP, le débit n’est pas garanti.

Les dedicated bearers sont des bearer établis à n’importe quel moment après la procédure d’enregistrement pour que l’utilisateur puisse profiter de services nécessitant de la QoS spécifique (latence, débit, …) et sur d’autres PDN. Les valeurs de QoS sont reçues au niveau du P-GW par le PCRF et transférées ensuite au S-GW. Enfin, le MME transfère les valeurs reçues par le S-GW vers le eNb (interface S11)