Dans un précédent article, j’avais présenté de manière générale la procédure d’attachement au réseau LTE. Je vous invite à relire l’article EMM Procédure – Initial Attach.

Cet article est inspiré du site www.netmanias.com

I) Principe et objectifs.

Ia) Les objectifs

En mettant le téléphone sous tension, ce dernier cherche le réseau 4G en priorité, et lorsqu’il trouve une station de base (eNb), l’UE lance une procédure d’enregistrement. Cette procédure d’enregistrement se nomme Initial ATTACH ce qui permet  d’Identifier et authentifier l’UE au niveau du réseau (cf. call flow simplifié de l’article EMM Procédure – Initial Attach)

L’objectif de cet article est donc de détailler le call flow suivant (présenté dans l’article EMM Procedure  – Initial Attach)

En fait, il y a plusieurs cas d’enregistrement, nous allons aujourd’hui en lister que 3 et ne détailler que le premier cas.

1. L’UE se connecte pour la première fois au réseau 4G, dans ce cas l’UE envoie son IMSI
2. L’UE se reconnecte après une perte de couverture en restant sur le même MME
3. L’UE se reconnecte en ayant changé de MME

Dans les deux derniers cas, l’UE envoie l’identifiant GUTI. Se référer à l’article IMSI, TMSI, GUMMEI, GUTI comme le montre la figure suivante :

(NB : Pour être plus précis, il faut aussi différencier le cas ou le MME connait l’UE car son contexte a été sauvegardé du cas ou le MME ne reconnait pas l’UE car son contexte a été supprimé au niveau du MME).

Afin d’analyser le call flow de demande d’enregistrement, il est nécessaire d’avoir en tête les interfaces et les protocoles entre l’UE et le MME. Nous allons également exploiter dans cet articles les notions vues dans l’article protocole RRC

Ib) Généralité sur la procédure d’enregistrement

L’attachement d’un UE se déroule en 5 phases :

1. UE ID Acquisition : L’UE s’identifie auprès du réseau en communiquant son identifiant IMSI (ou GUTI)
2. Authentication : Authentification mutuelle par la méthode EPS-AKA
3. NAS Security Setup : Chiffrement des données
4. Localisation Update : Le MME informe le HSS qu’il gère l’UE et récupère les services auquel l’UE a souscrit.
5. EPS Session Establishment : Création du Bearer par défaut

II) Description des étapes

II-1)  UE ID Acquisition

L’UE ID acquisition a pour objectif de fournir l’identité de l’UE au réseau (MME). Mais, cette première phase se découpe elle aussi en plusieurs étapes :

1. Synchronisation et recherche de cellule.
2. Etablissement d’une connexion ECM

Etape 1 : Synchronisation et recherche de cellule.

Dans un premier temps, lorsque le téléphone s’allume, sa première démarche consiste à chercher le réseau pour se synchroniser et trouver les informations sur les eNb. Pour rappel (cf article Etat RRC – ECM – EMM), l’U est dans les états suivants :

• EMM Deregistered
• ECM Idle
• RRC Idle

Etape 2 : Etablissement d’une connexion ECM

L’établissement de la connexion ECM a pour objectif de transmettre l’IMSI de l’UE au MME .Cela nécessite la encore plusieurs sous-étapes :

• Synchroniser en temps et en fréquence l’eNb et l’UE pour échanger des données (TTI et PRB) nommé RRC Connection Establishment
• Transmettre les données – Attach Request – jusqu’au MME

2a) Une première connexion RRC est nécessaire pour passer du mode RRC-Idle au mode RRC-Connected. L’UE doit impérativement passer en mode RRC Connected pour pouvoir transférer des données ou transmettre de la signalisation (Les messages NAS sont transférés comme  RRC).

Une fois l’UE en mode RRC Connected, il peut envoyer les informations NAS (requête d’attachement) et passer en mode ECM-Connected.

2-a) RRC Connection Establishment

La connexion RRC permet d’établir un bearer radio pour la signalisation (SRB0/SRB1) et s’effectue en 3 étapes.

2-a.1) [UE → eNB] RRC Connection Request

La requête RRC Connection Request (Establishment Cause=“Mobile Originating Signaling”) est transmis de l’UE vers le mobile sur un canal aléatoire . La raison “Mobile Originating Signaling” est transmis par l’UE lorsque l’UE va faire une des demande suivante : Attach, Detach ou TAU (Tracking Area Update).

2-a.2)  [UE ← eNB] RRC Connection Setup

Le eNb contrôle les liens radios Upling et Downlink de l’UE, en lui allouant un SRB1 qui correspond au lien radio dédié à l’UE. Il porte connaissance à l’UE du lien radio dédié en envoyant cette inforamtion dans le message  RRC Connection Setup, lequel est délivré sur le SRB 0 et le CCCH..

2-a.3)  [UE → eNB] RRC Connection Setup Complete

L’UE acquitte l’eNb par le message RRC Connection Setup Complete via le lien radio dédié SRB 1 et le canal logique DCCH (Dedicated Control Channel). Pour plus d’efficacité, le message  Attach Request est transmis au eNB dans le message RRC Connection Setup Complete.

A partir de l’acquittement, l’UE est dans l’état RRC-Connected

2-b)  La requête d’attachement

L’UE envoie le message EMM – ATTACH REQUEST dans le message RRC.

2-b.1) S1 Signaling Connection Establishment

Les messages de contrôle entre l’eNb et le MME sont transmis sur l’interface S1-MME via le protocole S1AP. La connexion S1 est dédiée pour chaque utilisateur et est identifiée par la paire  (eNB UE S1AP ID, MME UE S1AP ID) allouée par l’enB et le MME, permettant à chaque entité d’identifier l’UE.

A ce stade du call flow, l’eNb a reçu de la part de l’UE une requête ATTACH-REQUEST. L’eNB va définir un identifiaint eNb UE S1AP IE pour l’établissement de la connexion S1 et envoie la requête ATTACH REQUEST au MME* avec le contenu suivant :

La question qui se pose maintenant est la suivante : Comment l’eNb connait l’adresse du MME qui prend en charge la requête. Deux premiers cas se posent :

• Si l’eNb n’est connecté qu’à un seul MME, il peut alors transmettre la requête d’attachement
• Si l’eNb est raccordé à un Pool de MME (cf article précédent), et si l’UE n’a pas d’identifiant GUTI (car dans ce cas, il connait l’adresse du MME sur lequel il était précédemment connecté) alors l’eNB sélectionne le MME en fonction de sa charge. Périodiquement, les MME envoient un rapport de charge à l’eNb (weight factor).

2-c)  ECM Connection Establishment

A la réception de ce message, le MME allou l’identifiant MME S1AP UE ID pour identifier l’UE ce qui permet de finaliser la connexion entre l’eNb et le MME. Les états de l’UE sont maintenant les suivants :

• EMM-Registered
• ECM-Connected
• RRC-Connected.

2-d) IMSI Acquisition 

A partir des informations contenues dans le champs Network Capability du message ATTACH REQUEST, le MME connait les algorithmes de sécurités supportés par l’UE et son IMSI.

Le MME va maintenant procédér à une authentification de l’UE et va permettre à l’UE d’authentifier le réseau EPS selon la procédure EPS-AKA (Authentication and Key Agreement).

II.2 Authentication

L’authentification est dite mutuelle car le réseau authentifie l’UE et l’UE authentifie l’EPS. La procédure se découpe en deux étapes :

1. Acquisition des vecteurs d’authentification : Le MME récupère les vecteurs d’authentification au niveau du HSS (AuC faisant parti du HSS)
2. Vérification des paramètres d’authentifications

Le Call Flow sur l’authentification est représentée sur la figure suivante :

1) Acquisition du vecteur d’authentification

A travers l’interface S6a, Le MME contacte le HSS via le protocole DIAMETER pour récupérer le vecteur d’authentification AV composé des éléments suivants :

• RAND : Un nombre aléatoire
• AUTN : Le sceau d’authentification appelé aussi jeton d’authentification. utilisé par l’application USIM pour authenfier l’EPS
• XRES : Le résultat de l’authentification de l’UE selon la clé connue par le HSS (laquelle est aussi enregistrée sur l’UICC). XRES est le résultat calculé au niveau du réseau à partir du RAND et des paramètres connues de l’UE.
• K_ASME: La clé de cryptage et de chiffrement (nommée Ki et Kc). A la différence du réseau 3G, seule Kasme est transmis permettant de dériver les clés Ki et Kc.

La récupération du vecteur d’acquisition s’effectue en trois étapes :

1. Requête de la part du MME vers le HSS
2. Calcule de l’AV au niveau du HSS
3. Transmission de l’AV du HSS au MME

1-a) Demande du vecteur AV [1]

Le MME demande les vecteurs d’authentifications à chaque message ATTACH_REQUEST.

Dans sa requête, le MME envoie l’identité du mobile (IMSI) et l’identité SN ID composé du MCC et du  MNC du MME faisant la demande afin que l’opérateur HOME puisse connaitre quel opérateur fait la demande d’authentification de son client.

1-b) Génération du vecteur d’authentification AV [2]

Le HSS (en 3G il s’agissait du HLR/AuC) calcule le vecteur d’authentification AV en utilisant la clé LTE K à partir de la connaissance de l’IMSI et de l’identité SN ID.

Dans un premier temps, le HSS génère un numéro de séquence SQN incrémenté à chaque routine et un numéro aléatoire RAND, et l’algorithme de crypto utilisé ces deux paramètres et la clé privé LTE K pour générer le résultat attendu d’authentification de l’UE (XRES), et les clés de chiffrement Kc et d’intégrité Ki.

(XRES, AUTN, CK, IK) = Crypto Function (LTE K, SQN, RAND)

Les valeurs  {SQN, SN ID, CK, IK} permettent de créer la clé de dérivation K_ASME

K_ASME = KDF (SQN, SN ID, CK, IK)

1-c) [MME ← HSS] Delivering Authentication Vectors [3]

Le HSS transmet le vectueur d’authentification AV :  Authentication Information Response au MME.

2) Authentification mutuelle

La procédure EPS-AKA est un accord mutuel d’authentification.Lorsque le MME reçoit le paramètre d’authentification AV il ne transmet que les éléments nécessaire permettant à l’UE d’authentifier le réseau (AUTN : Sceau ou jeton d’authentification) et la variable aléatoire RAND permettant à l’UE de calculer son sceau (ou jeton) d’authentification XRES.

Le MME conserve les valeurs XRES et K_ASME pour authentifier l’utilisateur et connaître les clés de chiffrements et d’intégrité. K_ASME n’est pas transmis à l’UE car ce dernier va le calculer. L’UE a néanmoins besoin de connaitre l’index KSI_ASME correspondant à la valeur SQN pour calculer les clés Ck et le Ci :

2-a) [UE ← MME] Request by MME for User Authentication [2]

Le MME transmet les informations  (RAND, AUTN et KSI_ASME) nécessaire à l’UE dans le message Authentication Request (RAND, AUTN, KSI_ASME).

2-b) [UE] User’s Authenticating the Network: Generating Authentication Vectors and Authenticating the Network [5]

A partir du message Authentication Request (RAND, AUTN, KSI_ASME), l’UE génère d’abord la valeur SQN à partir de l’AUTN,et calcule à partir de son LTE K et du SQN la valeur AUTN_UE. L’UE compare ainsi la valeur AUTN_UE calculée au niveau de l’USIM de la valeur AUTN envoyé par le réseau. Si les deux valeurs sont identiques, l’UE authentifie le réseau et sauvegarde la clé s KSI_ASME comme un index pour calculer K_ASME.

2-c) [UE → MME] Delivery of User RES to MME [6]

L’UE calcule ensuite les clés de chiffrement et d’intégrité et à partir de la valeur RAND, il calcule son sceau (jeton) d’authentification nommée RES (Authentication Response). Cette valeur est transmise au MME

2-d) [MME] Network’s Authenticating the UE [7]

Le MME compare le RES reçu du XRES émis par le HSS et sauvegardé au niveau de l’UE. Si les 2 valeurs correspondent, l’UE est authentifié au niveau du réseau.

D’une manière plus complète, la procédure est la suivante, nous détaillerons cette procédure EPS-AKA dans un autre article.

II-3) NAS Security Setup

A partir de l’authentification mutuelle, l’UE et le MME pourront échanger des données de signalisation. Celles-ci sont transmises dans un tunnel crypté. L’UE et le MME échange donc les algorithmes de chiffrement et d’intégrité en 4 étapes

3-a) [MME] Generating NAS Security Keys [1]

Le MME choisi l’algorithme de chiffremetne t d’intégrité qui sera appliqué à l’échange de message NAS (nous sommes toujours dans le cas de la requête ATTACH). A partir de cet algorithme et de la valeur K_ASME, le MME calcule la clé d’intégrité NAS integrity key (K_NASint) et la clé de chiffrement (K_NASenc). Ces deux clés sont appliquées au message NAS.

3-b) [UE ← MME] Security Mode Commande [2]

Le MME informe l’UE du choix de l’algorithme dans le message Security Mode Command (KSI_ASME, Security Algorithm, NAS-MAC) ce qui permet à l’UE de générer les clés duales.

3-c) [UE] Generating NAS Security Keys [3]

L’UE génère les clés d’intégrité et de sécurité (K_NASint and K_NASenc) en fonction de l’algorithme choisi par le MME.

3-d) [UE → MME] Security Mode Complete [4]

L’UE informe le MME de la génération des clés de sécurités NAS via le message Security Mode Complete (NAS-MAC).

II.4 Location Update

Le MME peut maintenant enregistrer l’utilisateur au niveau du réseau, le localiser et récupérer les services de souscriptions du client. Le MME informe le HSS qu’il gère l’UE et qu’il est enregistré au niveau du MME. Cela est réalisé au cours de la procédure de LU (Location Update Procedure), les échanges s’effectuent en utilisant le protocole DIAMETER sur l’interface S6a.

 4-a) [MME → HSS] Update Location Request  [1]

Le MME envoie la requête Update Location Request (IMSI, MME ID) vers le HSS afin de lui notifier la prise en charge de l’UE (authentifié) et pour réclamer la récupération du profil d’abonnement du client.

4-b) [HSS] Register [2]

Le HSS enregistre l’identifiant du MME afin de savoir sur quel MME gère le client en cas de terminaison de session (MT Mobile Terminated) pour ce client.

 4-c) [MME ← HSS] Update Location Answer [3]

Le HSS envoie le profilde souscription cu client au MME encapsulé dans le message Update Location Answer. A partir de cette confrmation, le MMEpeut créer une session EPS session et un bearer EPS par défaut. Le message de Update Location contient le paramètre de QoS et l’APN avec les informations sur les débits maximums autorisés pour le client

4-d) [MME] Storing Subscription Information [4]

Le MME sauvegarde les informations contenues dans le Update Location Answer dans un contexte pour l’UE.

II.5 EPS Session Establishment

A partir des informations de souscription de l’UE (QoS), le MME va créer la session et le bearer EPS par défauten satisfaisant le critère de QoS

5-a) [MME] Assigning EPS Bearer ID [1]

Un bearer EPS bearer est une connexion virtuelle entre l’UE et le P-GW permettant de délivrer le trafic utilisateur. Un EPS bearer est identifié par 4 bits nommé EPS bearer IDs dont les valeurs sont définies par le tableau suivant :

Le MME va donc attribuée une valeur EPS Bearer ID comprise entre 5 et 15.

5-b) [MME] Selecting P-GW [2]

Le MME interroge le serveur DNS pour connaitre le PDN associé à l’identifiant reçu par le HSS (ex : internet.apn.epc.mnc01.mcc208.monfai.fr) ou directement à partir de l’information P-GW ID si disponible.Le MME choisi également le SGW qui transfera les données utilisateurs au PGW

5-c) [MME → S-GW] Create Session Request [3]

Le MME demande la création de session de données auprès du SGW via le message Create Session Request (interface S11).

Le SGW contacte ensuite le PGW afin que ce dernier valide l’établissement du contexte EPS. Comme on le verra dans le 7ème point (5-g), le PGW peut aussi modifier la QoS associé au débit sur cet APN en imposant une valeur pour l’AMBR. En effet, dans sa requête au SGW, le MME inclue les informations de souscriptions reçues par le HSS permettant ainsi au P-GW d’interroger le PCRF pour les attributs de la session EPS et vérifier la concordance entre la demande et la souscription (facturation).

Voici le détail des informations transmises au cours de la requête Create Session Request :

5-d) [MME → P-GW] Create Session Request  [4]

Le S-GW transfère la requête vers le P-GW sur l’interface S5 via le protocol GTP (UP: GTP-U, CP: GTP-C). Le S-GW alloue un identifiant de tunnel DL S5 TEID (S5 S-GW TEID) au niveau du SGW. 

5-e) [S5 Bearer: Downlink] [5]

A la réception du message au niveau du PGW, ce dernier doit créer un identifiant de tunnel permettant ainsi de définir de bout en bout le bearer S5. Mais avant cela, il faut vérifier le droit d’accéder au réseau.

5-f) [P-GW] Allocating User IP Address [6]

Le P-GW invoque le serveur DHCP afin de fournir une adresse IP à l’UE pour le routage des données avec l’APN

5-g) [P-GW → PCRF] Notifying of EPS Session Setup [7]

Le P-GW et le  PCRF communique à travers l’interface Gx et utilisant le protocole Diameter pour valider si le service demandé par le client fait parti de l’offre de souscription du client. Le PCRF est en charge de contrôler les accès autorisés et le cas échéant d’appliquer les règles de QoS souscrites. Le P-GW envoie la requête DIAMETER CCR (CC-Request) : 

5-h) [PCRF → SPR] Requesting Access Profiles [8]

Le PCRF interroge le SPR pour connaître le profil d’accès du client et déterminer les règles de PCC à mettre en oeuvre.

5-i) [PCRF ← SPR] Returning Access Profiles  [9]

Le SPR renvoi le profil d’accès de l’utilisateur. Le profil peut contenir des informations sur les filtres de sessions de flux de données (SDF Filter) et les paramètres QCI, ARP, APN-AMBR (UL/DL), les méthodes de taxation (e.g. Offline), …

5-j) [PCRF] Determining Policies [10]

Le PCRF détermine la politique  PCC  à appliquer à la session EPS.

5-k) [P-GW ← PCRF] Acknowledging EPS Session Establishment [11]

Le PCRF founit les règles PCC au P-GW, dans sa réponse DIAMETER CCA (CC-Answer).

5-l) [P-GW] Policy Enforcement [12]

Le P-GW applique les règles PCC (le P-GW joue le rôle du PCEF) reçues par le PCRF. Comme les règles PCC sont définies pour chaque flux de sessions de données SDF, le P-GW fait un mapping entre le SDFs et le bearer EPS créée.

◇ 13) ~ 15) EPS Session Creation Response

Du 13ème au 15ème message, le P-GW informe le MME de son choix de QoS appliquée à la session EPS dans le message Create Session Response. Le PCRF peut avoir décidé de conserver la valeur de QoS demandé par le MME ou proposé une autre valeur.

5-m) [S-GW ← P-GW] EPS Session Creation Response [13]

Le P-GW alloue un identifiant S5 TEID (S5 P-GW TEID) pour établir le tunnel GTP sur l’interface S5 avec le  S-GW. Dans la réponse Create Session Response, le P-GW indique l’identifiant du tunnek P-GW TEID et la QoS à appliquer au bearer S5 (et par conséquent au bearer EPS par défaut).

5-n) [S5 Bearer: Uplink] S5 Bearer Established  [14]

La réponse est ensuite transmise au S-GW permettant ainsi de cérer le tunnel de bearer S5 via le protocole GTP-U .

5-o) [MME ← S-GW] EPS Session Creation Response [15]

Le SGW transfère ensuite le Create Session Response au MME en allouant un identifiant S1 TEID (S1 S-GW TEID) pour créer le tunnel S1 GTP associé au bearer S1 entre l’eNb et le SGW.

16) [MME] Le MME Conserve dans son contexte l’identifiant S5 P-GW TEID

Quand l’UE sera attaché au réseau, en cas de Handover vers un autre S-GW il faut construire le tunnel entre le nouveau SGW et le P-GW, point d’ancrage au PDN. Pour cette raison, le MME doit conserver l’identifant S5 P-GW TEID²²

5-p) [MME] Calcule le UE-AMBR [18]

Le MME envoie à l’UE le message  Attach Accept en réponse à la demande de l’UE  Attach Request.  Le MME prépare le support E-RAB (i.e. en allouant des ressources sur le lien radio et en créant le bearer S1). Pour cela, le MME calcule la valeur UE-AMBR qu’il va transmettre au eNB. Cela permet d’ajuster la valeur reçue du HSS avec la valeur réellement utilisée sur le default bearer..

19) Génération de paramètres pour l’E-RAB et le NAS Signaling

A la réception de la réponse du P-GW Create Session Response le MME est informé des ressources à mettre en oeuvre pour l’UE. Le MME à la charge de garantir la même QoS entre le S-GW et l’UE en construisant les bearer DATA et S1. La mise en place de l’E-RAB nécessite de la part du MME les informations suivantes :

• Identitifcation de l’UE par la variable GUTI au lieu de l’IMSI
• Détermination des paramètres pour définir la liste de TAI (TAI list allocation, TAU Timer value)
• Calcul de l’UE-AMBR pour l’eNb
• Définition d’un E-RAB ID

5-q) [UE ← MME] Attach Accept [20]

Les informations précédentes, l’adresse IP de l’UE, l’identification du bearer EPS (EPS Bearer ID), le débit maximum UE-AMBR et les paramètres de QoS reçus dans le message  Attach Accept de la part du S-GW est transféré jusqu’à l’UE permettant ainsi d’aboutir à la réponse de l’UE sur sa demande Attach Request .

Le message ATTACH REQUEST est encapsulé dans le message Initial Context Setup Request du protocole S1-AP et ensuite sur le lien radio via le protocole RRC  RRC Connection Reconfiguration.

[MME]  AS Security Setup : Creating K_eNB  [21]

Les échanges sur la couche radio sont chiffrées selon la clé K_eNB transmise par le MME à l’eNb sur la base du K_ASME. This is to ensure the eNB can generate AS security keys to be used for secured communication between the eNB and the UE over radio link (i.e. for AS security setup).

5-r) [eNB ← MME] Requesting E-RAB Setup [22]

Le MME commence par établir le bearer S1 via le message Initial Context Setup Request. Ce message permet de constuire le S1 bearer entre l’eNb et le S-GW, mais aussi le DRB avec kl’UE. Le message Initial Context Setup Request contient les informations suivantes :

5-s) [S1 Bearer: Uplink] [23]

A partir du message Initial Context Setup Request reçu de la part du MME, l’eNb peut construire le tunnel (identifiant TEID) et mettre en place le support E-RAB. Pour cela il envoi le message Attach Accept à l’UE et termine la mise en place du S1 bearer en incluant l’identifiant S1 TEID dans le message Initial Context Setup Response pour répondre au précédent message du MME. Le MME transfère ainsi le message vers le S-GW pour que ce dernier puisse connaitre le S1-TEID

5-t) [eNB] Generating AS Security Keys [24]

L’eNB choisit l’algorithme de chiffrement et d’intégrité à partir de la clé  K_eNB afin d’assurer la confidentialité et l’intégrité des messages RRC A partir de K_eNB, leNb calcule les clés K_RRCint/K_RRCenc,

5-u) [UE ← eNB] Helping UE to Generate AS Security Keys [25]

L’eNB informe l’UE du choix des algorithmes via la commande Security Mode Command (AS Security Algorithm, MAC-I).

5-v) [UE] Generating AS Security Keys [26]

A la réception du message Security Mode Command, l’UE génère les clés de sécurité AS  (K_RRCint, K_RRCenc et K_UPenc)

5-w) [UE → eNB] AS Keys Generation Complete [27]

Le message  Security Mode Command permet de vérifier le chiffrement A partir de ce moment, l’ eNB établi le lien DRB sécurisé.

28) ~ 29) DRB Establishment

5-x) [UE ← eNB] Reconfiguring RRC Connection [28]

L’eNB alloue une identité DRB Id, et configure les paramètres de QoS pour pouvoir finaliser l’établissement du lien DRB. Pour ce faire, il transmet le message RRC Connection Reconfiguration à l’UE  via le connexion RRC sécurisée. Ce message RRC a pour but d’allouer les ressources radios comme cela a été négocié avec le P-GW. L’eNb transmet également dans le corps du message l’adresse IP de l’UE.

Enfin, le message  RRC Connection Reconfiguration encapsule la réponse Attach Accept

 [DRB Establishment: Uplink and Downlink] DRB Establishment Complete [29]

L’UE peut maintenant émettre et recevoir de la Data avec l’eNb

5_y) [eNB → S-GW] E-RAB Setup Response [30]

Le lien se construit entre l’eNb et le SGW. Pour ce faire, l’eNb transmet son identifiant de tynnel S1 TEID (S1 eNB TEID) pour la construction du bearer S1 et en informe le MME via le message Initial Context Setup Response, ce qui permet de répondre à la requête  Initial Context Setup Request

[eNB] Allocating a Downlink TEID for S1 Bearer [31]

Le S1 bearer, est ainsi établi via le protocole S1 GTP-U tunnel. Le S-GW attend la confirmation de la connexion de l’UE, ce dernier doit confirmer son attachement auprès du MME

5-z) [UE → MME] Sending Attach Complete Message [32]

L’UE envoi le message Attach Complete au MME, en réponse au message [20]

 [UE][MME] EMM State [33]

L’UE et le MME sont dans l’état EMM-Registered. SI le MME envoi le message Attach Reject (cela se ferai à l’étape 20) dans ce cas l’UE libère sa connexion eECM/RRC et se retrouverait dans l’état EMM-Deregistered.

5-aa) [MME → S-GW] Requesting S1 Bearer Modification [34]

Le MME transmet l’identifiant S1 TEID (S1 eNB TEID) reçu de la part de l’eNB vers le S-GW via e message Modify Bearer Request message.

5-ab) [MME ← S-GW] Responding to S1 Bearer Modification Request [35]

Le S-GW envoit un acquittement au MME ‘Modify Bearer Response’ indiquant que le S-GW est prêt pour délivrer le flux de données

5-ac) [S1 Bearer: Downlink] S1 Bearer Setup Complete [36]

La procédure de mise en place du bearer S1 est finie, l’eNb et le S-GW peuvent échanger des données sur el S1 bearer