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

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.

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

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.

Selon 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

Formation 4G

un très bon travail pédagogique a été réalisé par M Lagrange et son équipe sur la plate-forme FUN. Allez vite découvrir les vidéos et quizz publiés

Voici le lien : Comprendre la 4G