Protocoles NAS et Protocoles AS

Je vous propose de commencer l’année 2015 par une description fonctionnelle du réseau
cellulaire 3G/4G, en reprenant le concept des strates nommées strates d’accès et strates
de non accès. Les strates représentent les procédures d’échanges d’information à la fois
des informations de signalisations et des informations usagers (payload ou données
utiles) entre l’UE et le cœur réseau
AS : Acces Stratum
La strate d’accès fait références aux protocoles relatifs à l’accès radio qui permettent de
gérer l’échange d’information (pour rappel signalisation et données) entre l’UE et coeur
réseau de l’opérateur. L’AS fait référence aux couches basses de la pile protocolaire OSI.
NAS : Non Acces Stratum
Le NAS (strate de non accès) représente un ensemble de protocoles qui s’établit entre
l’UE et le réseau coeur. Le NAS permet l’échange d’information de contrôle ou de
données quelque soit l’accès radio. Le NAS s’appuie donc sur l’AS pour transporter ses
données.
On peut donc, dans le cadre du réseau 3G, représenter schématiquement les strates
d’accès comme suit (figure 1) :

Figure 1 : Représentation schématique NAS/AS

Les rôles de la Strate d’Accès

Les principales fonctions liées au réseau d’accès (UTRAN Universal Terrestrial Radio
Access Network) sont les suivantes
  ŸGestion des ressources radio
 ŸHandover
 ŸChiffrement/Compression
Les rôles de la Non Strate d’Accès
La couche NAS a deux rôles essentiels (figure 2):
 Gestion des sessions (et des appels pour la 3G)
 Gestion de la mobilité.
Pour la 3G : La gestion des sessions se découpent en deux sous-couches :
 la sous couche de gestion des appels téléphoniques nommées Call Control –CC–
uniquement pour le réseau 3G (puisque le réseau 4G n’est qu’un réseau IP). Cette
sous-couche ne concerne que la gestion des appels en commutation de circuits,
c’est à dire l’établissement, le maintien et la libération des appels du domaine circuit
 la sous couche de gestion des sessions pour l’établissement et le relâchement des
sessions (donc du domaine paquet).
La mobilité pour la NAS est la gestion de l’authentification, de mise à jour de la
localisation et de l’attachement au réseau. Il s’agit du protocole MM : Mobility
Management pour la commutation de circuit et GMM GPRS Mobility Management pour
la partie commutation de paquets.

Figure 2: Représentation couches AS/NAS 3G

Pour le LTE, les protocoles se nomment (figure 3):

 ESM : EPS Session Management
 EMM : EPS Mobility Management.
 Figure 3: Représentation couches AS/NAS 4G
Les rôles de la Strate d’Accès
La strate d’accès regroupe donc les couches basses : RRC, PDCP, RLC, MAC et Phy.
Les messages NAS, entre l’UE et le Nb ou eNb sont encapsulé dans les messages RRC.
Nous verrons le rôle de ces couches dans un autre article.

Protocole RRC
Hérité de la 3G, le protocole RRC permet à l’UE et à l'(e)Nb d’échanger de la signalisation
(messages RRC).
Au cours de l’article Protocoles NAS et Protocoles AS, je vous avais présenté le concept
d’accès au réseau (NAS et AS). Dans cet article, j’avais présenté le NAS (Non Access
Stratum). Comme son nom l’indique les fonctionnalités du NAS sont indépendantes de la
couches d’accès, donc de l’accès radio et par conséquent le NAS permet l’échange
d’information de signalisation entre l’UE et le MME.
Le NAS a pour rôle de permettre :
 l’enregistrement de l’UE au réseau
 l’authentification de l’UE
 la mise à jour de la localisation
 la gestion des appels.
Cf. article Protocoles NAS et Protocoles AS « La couche NAS a deux rôles essentiels
(figure 2): »
 Gestion des sessions (et des appels pour la 3G)
 Gestion de la mobilité.
En fait, les protocoles EMM, ECM et ESM sont des protocoles de signalisation de la
couche NAS, cela concerne l’UE et le MME.
L’AS regroupe les protocoles de signalisation propre au réseau d’accès (Access Stratum)
c’est à dire entre l’UE-eNb et eNb-MME, eNb-SGW pour la 4G.
L’AS est transporté par les messages RRC sur l’interface LTE-Uu. Même si le NAS est
indépendant de la couche d’accès, il est néanmoins transporté par la couche radio dans
le cadre du LTE. Ainsi, le NAS est transporté par le protocole RRC (interface LTE-Uu) et
le protocole S1-AP (interface SA-MME).
A titre d’exemple, pour l’EMM les messages ATTACH/DETACH REQUEST, TAU sont
encapsulés dans le message RRC Connection Setup Complete, tout comme
le SERVICE REQUEST de l’ECM (se référer à al’article correspondant : ECM – EPS
Connection Management)
Pour la 3G, il faut rajouter le RNC comme le montre la figure ci-dessous

Le protocole RRC a pour but est de transférer les informations de signalisation entre l’UE
et la station de base, nous allons pouvoir maintenant étudier les messages d’accès au
réseau et de gestion d’appels, ainsi que les call flow dans les articles à venir.
Commentaires : Bien différencier les protocoles et les interfaces. L’interface S1-MME et
le protocole S1-AP.

EMM – EPS Mobility Management

Les réseaux mobiles doivent être perçus comme une extension du réseau fixe : Les
difficultés des réseaux cellulaires vis-à-vis des réseaux classiques sont d’une part la
gestion de la mobilité et d’autre part, pallier à l’affaiblissement dynamique des liens
radios.
Afin de conserver le fonctionnement du réseau Ethernet de type résidentiel, l’idée de
l’EMM est de gérer la mobilité des utilisateurs pour rendre cette mobilité transparente au
niveau du cœur réseau.
Protocole EMM
Le protocole EMM gère la mobilité de chaque UE, l’EMM permet :
1. L’Enregistrement de l’abonné sur le réseau – Attach
2. La mise à jour de sa localisation – Tracking area update TAU
Il y a 3 types de procédures pour l’EMM :
 Les procédures communes permettant :
 l’authentification des UE (mécanismes AKA)
 la réallocation d’identifiant NAS – GUTI
  Les procédures spécifiques pour la demande d’attachement ou de détachement au
réseau, ainsi que la mise à jour de sa localisation
 Les procédures de gestion de session, autrement dit des procédures de
signalisation ou de connexion NAS sécurisée

Les procédures spécifiques sont déclenchées par l’UE , les procédures communes sont
déclenchées par le MME alors que les procédures de gestion de session peuvent être
soit à l’origine de l’UE (MO) soit du MME (MT).
Les états EMM pour l’UE et pour le MME
Comme nous l’avons vu dans l’article précédent, il y a 2 états d’enregistrement pour
l’EMM:
Pour passer de l’état EMM-Deregistered vers L’EMM-Registered, le mobile doit faire une
demande d’attachement (ATTACH), et inversement la demande de détachement
(DETACH) permet de passer de l’EMM Registered vers l’EMM Deregistered.
Etudions maintenant le contenu de ces états :
EMM-Registered :
Dans cet état, le MME connait la localisation du mobile soit au niveau de l’eNB soit au
niveau de la zone de TA (Tracking Area). Dans cet état, le mobile effectue des Mises à
jour de sa localisation (TAU : Tracking Area Update), il répond au Paging, et il effectue
des procédures de requête de service (Service Request) pour transmettre des données
en Uplink.
EMM-Deregistered :
Dans cet état, le MME ne possède pas d’information de localisation du mobile, ce qui
n’empèche pas au MME de conserver actif des contextes de l’UE afin d’éviter de refaire
la procédure d’authentifacation (AKA) lors de l’attachement. Lors des procédures de TAU
et/ou d’attachement, l’UE passe dans l’état EMM-Registered.
Pour l’UE
1. EMM_DEREGISTERED : L’UE n’a aucun contexte EMM avec le MME, il est
détaché du réseau ou non localisé. Il sort de ce contexte lorsqu’une procédure
d’enregistrement est effectuée
2. EMM_REGISTERED : L’UE est connecté au réseau et partage un contexte EMM
avec le MME

Pour le MME
EMM Procédure – Initial Attach
Au cours de l’article précédent, nous nous étions intéressés aux états EMM de l’UE et du
MME. Nous avons notamment vu que le protocole EMM réalise les fonctions suivantes :
L’attachement et le détachement, l’authentification, la mise à jour de la localisation de
l’UE et la mise en place d’une connexion sécurisée entre l’UE et le MME pour échanger
de la signalisation NAS.
La procédure d’attachement (enregistrement) est initiée par le téléphone afin que ce
dernier puisse accéder au réseau 4G, mais de surcroît la procédure d’attachement est
couplé avec la création de contexte pour établir un support (bearer) par défaut . En effet,
contrairement à l’UMTS, la procédure d’enregistrement permet d’établir un bearer DATA
(sur le plan usager), nommé default bearer.
Cette procédure est donc la première procédure établie par l’UE (ayant un abonnement
4G) lorsque l’utilisateur allume son téléphone. Cependant, sur cette première phase,
plusieurs scénarios peuvent se produire :
 L’UE était déjà attaché sur le réseau et sur la même TA
 L’UE était déjà attaché sur le réseau mais sur une autre TA
 L’UE s’attache pour la première fois au réseau
Comment un téléphone s’identifie t’il auprès du réseau cellulaire? La réponse est assez
simple, l’UE doit envoyer son identifiant IMSI ou GUTI, tout dépend du scénario ci-
dessus. Nous allons illustrer ces scénarios sur une première présentation simplifiée de
l’attachement initiale.
Nous verrons prochainement le call flow détaillé sur la procédure d’enregistrement après
avoir étudié le protocole RRC. Cela sera donc étudié dans un autre article. Dans cet
article nous nous concentrons sur les procédures EMM.
I) Initial Attach – Attachement Initale
L’enregistrement initial est déclenché à l’allumage de l’UE. Suite à cette procédure, l’UE
est enregistré sur un ensemble de zones de TA, zones indiquées par le MME dans le
message EMM Attach Accept.
Comme la procédure d’enregistrement initie également une connexion sur le plan usager,
l’UE peut recevoir et transmettre des sessions. C’est au cours de cette phase que l’UE
obtient une adresse IP (soit IPv4 avec un NAT au niveau du PGW, soit IPv6). Le context
bearer est sauvegardé au niveau du PGW. Cela signifie qu’il n’y a plus de bearer entre
le SGW et le PGW (ni sur le plan usager, ni sur le plan contrôle), seul le contexte est
sauvegardé au niveau du PGW. Si un appel arrive pour l’UE, le PGW contacte le MME
pour positionner l’UE et construit le bearer sans avoir besoin d’authentifier à nouveau
l’UE. Le réseau réduit ainsi la latence pour l’utilisateur.
Au cours de la procédure d’enregistrement, l’UE indique dans le message NAS Attach
Request (transmis à l’eNb) les informations suivantes :
 Identifiant temporaire GUTI s’il existe ou l’IMSI sinon
 Le dernier TA visité s’il existe
 …
Ces informations permettent donc de définir quel scénario d’attachement va être réalisé.
Cas 1 : L’UE fait une demande d’attachement avec son IMSI.
Dans la suite, l’UE possède un GUTI (attribué par un MME lors de son dernier
attachement). A partir du GUTI, on connait l’adresse du précédent MME (GUMMEI). La
procédure est la suivante : Le MME sur lequel l’UE fait sa demande d’attachement (qui
peut être le même que celui sur lequel il était attaché) va demander à l’ancien MME de
lui transférer le contexte de l’UE via le message IDENTIFICATION REQUEST. L’ancien
MME répond par IDENTIFICATION RESPONSE
Cas 2 : Le contexte de l’UE n’est plus sauvegardé dans le précédent MME
Le précédent MME n’ayant pas le contexte répond par un message d’erreur. Le nouveau
MME va alors demander à l’UE de lui fournir l’IMSI comme identifiant (EMM Identity
Request)
Cas 3 : Le contexte de l’UE est sauvegardé
Le précédent MME envoie le contexte au MME. Le contexte contient l’IMSI de l’UE et les
clés K_asme, ainsi que les clés de chiffrement et d’intégrité NAS. Un message de
vérification des clés (Clé d’intégrité NAS et de chiffrement) s’effectue entre le MME et
l’UE par l’envoi du message EMM SECURITY MODE.
Ainsi, pour le cas 1 et le cas 2, l’identification via l’IMSI permet de lancer une procédure
d’authentification : le MME demande au HSS de fournir un numéro aléatoire RAND, le
sceau d’identification du mobile et un sceau d’identification du réseau et une clé Kasme.
Une fois authentifié, il est nécessaire d’activer la sécurité de la signalisation en dérivant
de la clé Kasme trois clés, CK_nas, IK_nas et K_eNb.
Pour le cas 3, le MME récupère le contexte.
Une fois la mise en sécurité effectuée, le MME récupère le profil de l’utilisateur du
HSS (APN, QoS de l’utilisateur et AMBR) et le HSS sauvegarde l’adresse du MME qui
gère l’UE
La création du bearer par défaut s’effectue ensuite.
Lorsque le MME a récolté ces dernières informations, il sélectionne le SGW et déclenche
la création de contexte au niveau du SGW, lequel demande la création de contexte vers
le PGW. Le PGW peut valider ou refuser la création du contexte en fonction de la réponse
du PCRF.
II) Call Flow simplifié
Nous allons présenter un call flow simplifié permettant à un UE de s’enregistrer sur le
réseau de son opérateur. Rappelons avant tout l’architecture du réseau afin de présenter
les différentes interfaces existantes entre les équipements.

Le call Flow est extrait d’une formation EFORT, lequel détaille dans ce document le rôle
du HSS. DIAMETER est un protocole sur lequel s’appuie le coeur de réseau pour
permettre :
 l’authentification des UE
 l’autorisation de l’accès au réseau et aux services
 la taxation des services.
Lorsque l’UE s’allume, voici l’échange de trames entre l’UE et le réseau permettant
l’enregistrement de l’UE au niveau du réseau.
L’ attachement au réseau EPS correspond à :
 L’authentification de l’UE
 Rappatriement du profil souscrit par le client au niveau du MME qui gère l’UE
 La création d’un default bearer permanent correspondant à une connectivité
permanente IP.
Lorsque l’UE s’allume, il procède dans un premier temps à la recherche d’information sur
la cellule dans laquelle il est situé (synchronisation et récupération des informations de la
cellule, le tout étant émis périodiquement par le eNb). Une fois cette étape passé :
1. L’UE fait la demande d’enregistrement en émettant la requête Attach a destination
du MME. Le protocole de signalisation d’accès appelé EMM (EPS Mobility Management
Protocol est porté par DIAMETER (Signalisation réseau).
2. Le MME envoie un message DIAMETER AIR (Authentication Information Request)
au HSS sur l’interface S6a. C’est par ce message que le MME demande au HSS
de fournir un vecteur d’authentification de l’UE. L’UE étant défini par son identifiant IMSI,
cet identifiant est transmis dans la requête DIAMETER. Le HSS fait une requête dans sa
base de données afin de trouver la clé K correspondant à l’IMSI. Il tire ensuite un numéro
aléatoire RAND et calcule le sceau du mobile RES, le sceau du réseau AUTN et la clé
Kasme à partir de laquelle le MME va construire une clé de chiffrement NAS (CKnas),
une clé d’intégrité NAS (IKnas) et une clé de chiffrement pour l’eNb (KeNb). Par
conséquent, le HSS renvoie au MME par le message AIA (Authentication Information
Answer) les paramètres suivants : RAND, RES, AUTN et Kasme (3GPP TS 35.206).
3. Le MME envoie à l’UE un requete d’authentification. Cette requête est émise par le
protocole EMM. Via le message EMM Authentification Request, le MME transmet
le nombre aléatoire RAND et le sceau d’authentifcation du réseau AUTN à l’UE. Ces deux
paramètres sont transférées vers la carte USIM, laquelle calcule le résultat XRES (obtenu
à partir du rand et de sa clé privé), vérifie le sceau d’authentification du réseau, et calcule
la clé Kasme.
Si la valeur calculée par l’UE est identique au sceau AUTN, alors l’UE considère le réseau
comme le réseau de confiance.
L’UE retourne sa réponse XRES au MME afin que celui-ci vérifie le résultat
d’authentification RES obtenu par le HSS avec le résultat XRES calculé par l’UE. Si les
résultats sont identiques, cela signifie que les clés privées sont les mêmes et par
conséquent la double authentification est validée (AKA).
4. L’abonné (la carte USIM) est authentifié, mais pas le terminal. Le MME demande à
l’UE de lui fournir son IMEI.
5. A partir de la réponse obtenue, le MME interroge l’EIR pour savoir si le terminal fait ou
ne fait pas partie de la liste des équipements interdits (black list). L’interface DIAMETER
S13 est utilisée entre le MME et l’EIR.

6. Si l’UE et l’USIM sont authentifiés, le MME délivre une requête Update Location
Request (adresse MME sous forme de hostname, IMSI) au HSS via l’inteface S6. Sur
cette même interface, le HSS acquitte la mise à jour de localisation par une réponse
Update Location Answer au MME qui contient les données de souscription EPS de l ’UE
incluant la liste de tous les APNs que l’UE est en droit d’accéder, une indication sur l’APN
par défaut, et les paramètres de QoS associés à chaque APN. Si le HSS rejette la
procédure de mise à jour de localisation, alors le MME rejette la demande d’attachement
de l’UE.
7. Le MME établit le premier default bearer pour l ’UE.
8. Le MME retourne à l’UE une réponse EMM Attach Accept informant l’UE qu’il est
accepté par le réseau. Cette réponse permet à l’UE de connaître l’APN qui a été activé
et l‘adresse IP du PGW assignée à l’UE pour cet APN
NB : Les étapes 2 et 3 correspondent à l’authentification EPS, nommée EPS AKA. Cela
consiste (en attente d’un article décrivant la procédure complète) :
1. Authentifier l’UE de la part du réseau
2. Authentifier le réseau de la part de l’UE (pour garantir que le réseau est bien celui
de son opérateur et non un réseau tiers malveillant)
3. Créer un contexte de sécurité pour le calcul de clé de chiffrement.
ECM – EPS Connection Management
La connexion ECM (EPS Connection Management) a pour but de mettre en oeuvre des
ressources physique (SRB – Signaling Radio Bearer) et des ressources réseaux (S1
bearer) entre l’UE et le MME : La ressource physique génère des supports radios entre
l’UE et l’eNb alors que les ressources réseaux génèrent des supports (bearer) entre l’eNb
et le MME. Cela permet donc de créer une connexion entre l’UE et le MME (connexion
NAS) comme le rappelle la figure ci-dessous (extrait article)

Les procédures de gestion de connexions sont réalisées lors des procédures suivantes :
 Procédure d’accès aléatoire
 Procédure d’enregistrement LTE
 Procédure d’établissement de connexion pour le plan usage
 Procédure de libération de connexion

L’état de l’ECM permet aussi de déterminer si l’UE est localisée à l’eNb près ou sur un
zone nommée Tracking Area. Pour cela, l’ECM décrit l’existence ou non d’une connexion
NAS, c’est à dire une connexion entre l’UE et l’EMM selon l’un des deux états suivants :

 ECM-Idle
 ECM-Connected.

Les états ECM

ECM_idle : L’UE est dans l’état ECM_idle lorsqu’aucune connexion de signalisation NAS
existent entre l’UE et le MME, c’est à dire pas de connexion sur l’interface S1_MME. Dans
l’état ECM_idle, l’UE est localisé sur une Tracking Area.
Lorsque l’UE est dans l’état ECM_idle, sa mobilité est gouvernée par la procédure de
sélection/resélection de cellules comme indiquée dans la norme 3GPP TS36.304. Dans
ce cas, l’UE peut toujours être enregistré et localisé au niveau du MME (donc l’UE est
EMM_ENREGISTERED) mais la connexion de signalisation est perdue (ECM_idle).
ECM_Connected : Dans cet état, une connexion NAS est établie entre l’UE et le MME.
L’UE est localisé au niveau de l’eNb.
Ainsi, quand l’UE doit transmettre des paquets, l’UE envoie au MME un Service
Request pour passer dans l’état ECM_Connected.
II) Les états ECM et EMM

A priori les états ECM et EMM sont indépendants l’un de l’autre, par exemple la transition
de l’état EMM-REGISTERED vers EMM-DEREGISTERED peut se réaliser quelque soit
l’état ECM de l’UE ou du MME. Cela signifie que l’UE peut faire une demande de
détachement dans le mode ECM_idle ou ECM_Connected.
Lorsque l’UE libère la signalisation, ce dernier va dans l’état ECM_idle, mais il reste dans
l’état EMM_REGISTERED.
Cependant, certaines transitions nécessitent un état particulier de l’ECM. A titre
d’exemple, la transition EMM-Deregistered vers l’EMM-registered se réalise soit pendant
la demande d’enregistrement (LTE Attach) soit au cours de la procédure TAU. Dans ce
cas, l’UE passe simultanément dans l’état ECM-Connected State..
En combinant maintenant l’état EMM de l’UE, on peut différencier trois premiers cas :
 EMM-REGISTERED et ECM_idle

L’UE est localisé dans un zone TA, l’UE étant enregistré possède l’identifiant S-TMSI
mais n’a plus de connexion avec le réseau, dans ce cas, l’UE
1 – Peut réaliser une mise à jour de sa localisation.
1-1) Le TAU est déclenché lorsque le TA mesuré par le téléphone est différent du
précédent TA ou déclenché périodiquement à la fin du timer T3412.
1-2) Cela permet de maintenir l’enregistrement de l’UE et d’être toujours localisé par
l’EPC (notamment en cas de paging). L’UE envoie ainsi une notification à l’EPC pour
l’informer de sa présence.
2 – Est à l’écoute de Paging
 EMM-DEREGISTERED et ECM_idle

L’UE n’est pas localisé par le réseau, et doit s’attacher avec l’identifiant IMSI.
 EMM-REGISTERED et ECM_Connected

L’UE est localisé à la cellule près, il y a des échanges de signalisation entre l’UE et le
MME et des échanges de données entre l’UE et le SGW.
Sur la figure suivante, on présente les états de transitions entre les états ECM et EMM.
ESM – EPS Session Manager
Continuons notre étude sur les protocoles établis entre l’UE et le MME, et intéressons
maintenant au protocole ESM : EPS Session Manager.

I) Principe Général
Lorsqu’un utilisateur souhaite accéder à un service sur Internet (Internet, Streaming, …),
l’UE doit mettre en place une session.
Une session EPS (aussi nommée PDN Connection) est en charge de coordonner
une connexion IP entre l’UE et le PDN. La session est caractérisée par l’adresse IP de
l’UE et l’APN caractérisant le PGW d’accès au PDN. Lorsqu’une session EPS est établie
alors, la QoS et les règles de taxation sont définies (PCC avec le PCRF) et un Default
EPS bearer ou un Dedicaded EPS bearer est mis en place pour délivrer les paquets IP.
Le Default EPS bearer ou Dedicated EPS bearer correspond à un support (tuyau) sur
lequel sont transmis les flux IP jusqu’à la passerelle du réseau (PGW)
Le rôle de la session EPS est donc de gérer les flux de paquets IP de l’UE vers le SGW
jusqu’au PGW en s’assurant que les règles PCC soient correctement appliquées.
Etablir une session EPS signifie :
1. Sélectionner le PDN approprié pour apporter le service demandé par l’utilisateur.
(APN sur la carte USIM ou délivré par le HSS)
 2. Attribuer une adresse IP joignable et connue par le PDN
3. Appliquer les règles de politique sur la QoS et la taxation par rapport à l’abonnement
de l’utilisateur
4. Créer un Default EPS bearer pour délivrer les paquets IP
Toute session est controlée par le MME, l’UE doit en conséquence informer le MME
même si la DATA ne passe pas par le MME. Le MME prend connaissance de la demande
(caractérisé par un contexte de bearer), afin de créer un support (bearer) pour la DATA
entre l’UE et le SGW et entre le SGW et le PGW concerné (c’est à dire le PGW
correspondant à l’application et fourni soit par le téléphone soit par le HSS via l’APN).
Ceci permet de créer une connectivité de bout en bout jusqu’au réseau de donné PDN.
Le protocole ESM a donc pour rôle de :
 Activer et désactiver des contextes de bearer EPS
 Modifiier des contextes de bearer
Dans le cadre du GPRS et de la 3G, nous parlions de PDP context. L’équivalent en 4G
est l’EPS bearer.
II) ESM
Lors de la création d’une connexion IP entre l’UE et le PDN (à la demande de l’UE)
un contexte de bearer EPS par défaut (à ne pas confondre avec un Default EPS bearer)
est créé au niveau du MME. Le contexte définit les paramètres du bearer (QoS, le SGW
associé, …) et la connectivité IP (APN, @IP UE). Il s’agit de l’équivalent du PDP Context
établi pour la 3G.
Le MME peut aussi lancer une procédure ESM pour activer, modifier ou désactiver un
context de Bearer EPS (à la demande de l’UE ou de l’EPC).

IMSI, TMSI, GUMMEI, GUTI

Dans l’article précédent, nous avons étudié une approche simplifiée de l’enregistrement
de l’UE au niveau du MME. Lors de l’attachement, l’UE et le réseau s’authentifie
mutuellement. Au cours de cette procédure, l’authentification s’appuie sur l’IMSI contenu
dans l’UICC et le HSS.
Une fois l’UE authentifié, le réseau suit la mobilité du terminal en communiquant avec ce
dernier par le TMSI.
Nous allons dans cet article précisé le sens et le rôle de chacun de ces termes. L’article
s’appuie sur la spécification ETSI 3GPP TS 23.003 V10.1.0 (2011-03).
I – Identification du client mobile sur le réseau (GSM/GPRS/UMTS/LTE)
Un numéro d’identifiant unique (IMSI – International Mobile Subscriber Identity) est
attribué à chaque mobile ayant accès au réseau cellulaire. Ce numéro est valable pour
le réseau GSM/UMTS et EPS.
L’IMSI est composé de trois parties :
 1. MCC : Mobile Country Code permet de désigner le pays dans lequel est situé
l’opérateur.
2. MNC : Mobile Network Code permet de spécifier l’opérateur dans un pays
3. MSIN : Mobile Subscriber Identification Number, identifie de manière unique un
client de l’opérateur.

Figure 1 : Identification d’un utilisateur : IMSI

Lorsque l’UE se connecte, le réseau l’identifie à partir du numéro IMSI. L’IMSI n’est
enregistré qu’à deux endroits : Dans la carte SIM/USIM et au niveau du HLR/HSS. Ce
dernier est donc transmis après cryptage vers la station de base. Cependant, pour éviter
le décryptage de ce numéro, le réseau alloue à chaque UE un numéro temporaire
: TMSI (Temporary Mobile Subscriber Identities).
II – Identification du client mobile via le Temporary IMSI
Les équipements de localisation du réseau doivent être en mesure de mettre en relation
le TMSI du mobile avec l’IMSI. Le TMSI est sauvegardé au niveau des équipements
réseaux VLR, SGSN, MME et sur la carte SIM. L’échange se fait donc avec l’identifiant
TMSI au lieu de l’IMSI. Le TMSI sera modifié quand l’UE ne sera plus géré par le même
équipement réseau (VLR/SGSN ou MME). Mais le TMSI peut aussi être modifié de façon
périodique. Le TMSI n’est donc pas sauvegardé au niveau du HLR/HSS.
La valeur du TMSI est codée sur 4 octets, seule la combinaison constituée de 32 bits à
‘1’ est interdite (cette valeur indique que le TMSI n’est pas disponible). Le rôle du TMSI
est donc de contacter le mobile lors de la procédure de paging afin d’établir une
signalisation NAS entre le coeur réseau et l’UE.
Avec le GSM, le MS était repéré par le TMSI pour les services de phonie, puis avec
l’arrivé du GPRS, un nouvel identifiant temporaire, nommé P-TMSI était alloué aux MS.
Avec la 4G, les téléphone possèdent un nouvel identifiant nommé M-TMSI (MME TMSI).
III – Globally Unique Temporary Identifier
Le GUTI (Globally Unique Temporary Identifier) est assigné à l ‘UE par le MME lors de
la première demande d’attachement de l’UE.
L’objectif du GUTI est de fournir une identité unique à l’UE sans dévoiler l’identification
confidentielle, privée et unique de la carte SIM (IMSI). Le GUTI est composé de deux
identifiants, le GUMMEI (Globally Unique Mobility Management Entity
Identifier) qui identifie de manière unique le MME parmi tous les MME sur lequel l’UE est
inscrite et leM-TMSI qui identifie de manière unique l’UE parmi tous les autres UE gérés
par le MME.
Ainsi, lorsque l’UE envoie le GUTI à l’eNb, ce dernier utilise le GUTI pour identifier ver
quel MME la requête doit être transmise. En effet, un eNb peut être connecté à plusieurs
MME (pour faire un partage de charge).
Si l’UE était initialement enregistrée sur le réseau 3G ce dernier possède un identifiant
P-TMSI. Supposons qu’après une sélection de cellule l’UE s’attache au réseau 4G, alors
au cours de la procédure TAU, le MME qui va dorénavant gérer l’UE contacte le SGSN
pour demander le profil de l’UE (Adresse IP, PDP context). De manière identique, lorsque
l’UE quitte le réseau 4G vers le 3G, le GUTI est transmis et le SGSN lors du RAU (Routing
Area Update).
La figure ci-dessous décrit la manière d’écrire le GUMMEI et le GUTI : Le GUMMEI est
construit à partir du code pays (MCC), du code opérateur (MNC) et du MMEI (Mobility
Management Entity Identifier). Le MMEI représente une MME compris dans un groupe
de MME, il est ainsi constitué du MMEGI (Mobility Management Entity Group ID) et de
MMEC (MME Code).
En rajoutant le M-TMSI au GUMMEI, on obtient le GUTI.

Figure 2 : GUTI – Décomposition en plusieurs champs

Pour résumer, voici les identifiants permettant de caractériser de manière unique un

mobile au niveau du MME d’un opérateur dans un pays précis.
 Figure 3 : Détail du GUTI

A partir des différents identifiants énumérés ci-dessus, la norme définit d’autres attributs
comme :
 MME Identifier composé du MMEGI et MMEC
 S-TMSI composé du MMEC et du M-TMSI

Figure 4 MMEI et S-TMSO

Le S-TMSI est exploité dans le cadre de la procédude de Paging. Comme le montre la
figure précédente, le S-TMSI est construit à partir du MMEC et du M-TMSI. Par
conséquent, lorsque l’UE est enregistrée, le S-TMSI est déduit du GUTI à partir des 40
derniers bits du GUTI.
Questions : Quels sont les équipements de l’opérateur qui ont connaissance du TMSI?

PDP Context ou EPS bearer

Dans le réseau 3G, la mise en place d’une session de données est obtenue par la
procédure d’activation de PDP Context. Mais, pour que le PDP Context puisse être établi,
l’UE doit initialement avoir réalisé une procédure d’enregistrement (ATTACH
Procédure). Le PDP Context permet à la fois d’obtenir une adresse IP pour le terminal
et de définir la QoS associée à la demande. Notez que si l’utilisateur lance plusieurs
applications, l’UE fera la demande d’activation d’un PDP context Secondaire avec une
QoS associé à chaque PDP context.
La procédure d’attachement est exécutée lorsque l’UE s’allume, l’objectif est d’informer
le SGSN de la présence de l’UE. Une fois la procédure acceptée, l’UE ne peut rien d’autre
que d’émettre des requêtes de PDP Context. Dans ce cas, il ne peut pas recevoir de
données en provenance du réseau, ni de SMS over IP, puisque le réseau ne peut pas
initier des requêtes d’activation de PDP Context. Pour recevoir des SMS over IP et des
paquets, le réseau informe l’UE par un PUSH SMS. Un PUSH SMS est un message qui
demande au terminal d’initier une session, donc un PDP Context car sans cela l’UE n’a
pas d’adresse IP.
Dans le cadre du LTE, la connecitivité PDN (Session EPS) nécessite l’activation d’un
contexte EPS et l’établissement conjoint d’un bearer EPS par défaut.
Dans le cas ou l’UE souhaite accéder à d’autres services (nécessitant une QoS
différente), le réseau va associer un autre bearer dédié.
Il y a donc deux types de mise en place de sessions DATA pour transporter le flux IP et
un contexte Session pour mettre en place les supports (bearer) entre les équipements.
Concernant les bearer de DATA, le LTE définit
 Le Default EPS Bearer, et se met en place dès que l’UE s’enregistre auprès du
réseau. Le Default EPS Bearer est défini avec une QoS nominal suffisant pour le
transfert de la signalisation.
 Le Dedicated EPS bearer. Ce bearer va obtenir une QoS spécifique à l’application
demandée par l’utilisateur.
A titre de comparaison, le Default EPS bearer mis en place lors du LTE ATTACH est
équivalent à la procédure UMTS Attach suivi de la demande d’établissement d’un PDP
Context primaire. Le PDP context secondaire pour la 3G est comparable au
Dedicated EPS Bearer.
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
Le Bearer EPS traverse plusieurs interfaces, sur chacune de ces interfaces un bearerde
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
bearerpeuvent ê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
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 MMEtransfère les valeurs reçues par le S-GW vers le eNb (interface S11)

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 :
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 :

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.
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 B : EMM 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 C : EMM Registerd, ECM/RRC Connected – L’UE est enregistré sur le réseau LTE
et utilise des services. La mobilité est gérée par un handover (cellule à cellule pour ne
pas couper le trafic)
Etat D : EMM Registerd, ECM/RRC Idle – L’UE est enregistré sur le réseau LTE mais
n’utilise aucun service. La mobilité est gérée 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.
EMM Procédure – Initial Attach (Part 2)

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 où 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 l’eNB 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é 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 connus de l’UE.
 KASME: 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 KASME
KASME = 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 KASME pour authentifier l’utilisateur et connaître
les clés de chiffrements et d’intégrité. KASME n’est pas transmis à l’UE car ce dernier va le
calculer. L’UE a néanmoins besoin de connaitre l’index KSIASME 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 KSIASME) nécessaire à l’UE dans le
message Authentication Request (RAND, AUTN, KSIASME).

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

A partir du message Authentication Request (RAND, AUTN, KSIASME), 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 AUTNUE. L’UE compare ainsi la valeur AUTNUE 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 KSIASME comme un index pour calculer KASME.

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 KASME, le MME calcule la clé d’intégrité NAS integrity key
(KNASint) et la clé de chiffrement (KNASenc). 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 (KSIASME, 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é (KNASint and KNASenc) 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ée 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 KeNB [21]

Les échanges sur la couche radio sont chiffrées selon la clé KeNB transmise par le MME
à l’eNb sur la base du KASME. 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é KeNB afin d’assurer
la confidentialité et l’intégrité des messages RRC A partir de KeNB, leNb calcule les
clés KRRCint/KRRCenc,

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 (KRRCint, KRRCenc et KUPenc)

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

CSFB : Call Switch FallBack (1)

Bien qu’aillant déjà consacré 2 articles sur le CSFB (http://blogs.univ-poitiers.fr/f-
launay/2014/03/14/technologie-de-transport-de-la-voix-en-4g-csfb/ et http://blogs.univ-
poitiers.fr/f-launay/2014/03/20/technologie-de-transport-de-la-voix-en-4g-csfb-part-2/) je
vous propose d’expliquer à nouveau l’interet du CSFB et le fonctionnement de celui-ci via
des call flow. Je finirai par presenter plusieurs techniques pour réduire le temps de
basculement du réseau 4G vers le réseau 3G.
Le CSFB est un mécanisme permettant aux téléphones couvert par le 4G de se replier
sur le réseau 2G/3G (plutot 3G) pour pouvoir passer un appel : La 4G étant un réseau
tout IP, la voix est vue comme un service réseau, nécessitant la mise en place de l’IMS
Mobile pour permettre la voix sur LTE dénommée VoLTE (qui fera l’objet d’un autre
article). La VoLTE arrivera en septembre chez Orange et Bouygues, et fera
prochainement l’objet de plusieurs articles.
Lorsque vous êtes couvert par la 4G, pour savoir si la fonctionnalité CSFB ou si le VoLTE
est activé, regardez l’icône réseau. Normalement vous devriez voir le symbole 4G.
Passez un appel, si vous voyez apparaitre le symbole 3G (ou 3G+ ou H+), alors votre
téléphone est passé en 3G, si le symbole est 4G alors vous êtes en VoLTE.
CSFB (Circuit Switched Fallback):- est une fonctionnalité spécifiée par le 3GPP pour
fournir à l’UE les services à commutation de circuit traditionnel (comme la voix, les SMS..)
lorsque ce dernier est attaché au réseau de voix 4G.
Les fonctionnalités CSFB doivent être implementées au niveau de l’UE, du MME, du
MSC/VLR, et du HSS : lorsque l’UE s’attache au PLMN, il effectue un attachement
combine sur le MME et le VLR. Une nouvelle interface, nommée SG, est aussi créée
entre le MME et le VLR.
Pourquoi un attachement combine – IMSI Attach, EPS Attach ?
On suppose que le mobile est attaché au réseau 4G uniquement. Un appel arrive dans
le domaine CS, la demande est soumise au GMSC qui interroge le HLR/HSS. Pour ce
dernier, l’UE n’est pas connectée au réseau 2G/3G (rattaché à aucun VLR), l’appel est
donc renvoyé à la messagerie
Comment est réalisé l’attachement conjoint?
Pour plus d’information, se référer au document 3GPP TS 23.272
La question qui se pose maintenant est comment le MME peut dériver le VLR? N’y a t’il
pas conflit de localisation?
Revenons sur l’article Pool MME (http://blogs.univ-poitiers.fr/f-launay/2015/05/16/pool-
de-mme/), le MME gère plusieurs TA (Tracking Area), mais lorsque l’UE est en mode
connecté le MME sait précisément sur quelle TA il se trouve. Le MSC quant à lui localise
l’UE sur une LA (Location Area). La couverture d’une TA est plus petite qu’une LA pour
avoir de bonnes conditions radios et assurer un SNR minimum compatible avec le debit
espéré. Donc plusieurs TA sont regroupées dans une LA. Il suffit à l’opérateur d’éviter
tout chevauchement de TA sur deux LA pour qu’il n’y ait pas ambiguïté.
Donc, une LA est découpée en plusieurs TA et aucune TA chevauche deux LA. Il n’y a
donc plus de conflit de derivation de VLR, une TA n’appartenant qu’à une seule LA.

Fonctionnement présenté dans le cas d’un MTC

On suppose maintenant pour l’UE A, le double attachement EPS Attach et IMSI Attach.
L’utilisateur B appelle l’UE A. Le GMSC transfère l’appel au MSC/VLR lequel, via
l’interface SG, informe le MME du’un appel en cours (Paging). Le MME va redirigerl’UE
du réseau LTE vers le réseau 3G.
L’UE perd sa connexion au réseau LTE, le mobile cherche les informations SIB sur sa
nouvelle cellule pour se rattacher au Nb. Une fois connecté au réseau 3G, la procédure
de paging est transmise du MSC vers le Nb et l’UE demande une connexion au réseau
CS. Lorsque l’appel est terminé, l’UE retourne sur le réseau 4G.

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

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

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
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)
Technologie de transport de la voix en
4G : CSFB

CSFB : Circuit Switched FallBack

Le réseau cœur déployé pour la 4G (nommé EPC : Evolved Packet Core) a été conçu
pour s’interconnecter aux réseaux IP comme le LAN, la 3G, et évidemment le LTE.
Le principe du CS FallBack est assez simple : Lorsqu’un terminal mobile reçoit un appel
téléphonique (Voix), il est informé via le message de Paging que le réseau auquel il doit
accéder est le réseau de Commutation de Circuit (CS). Par conséquent, si le mobile était
attaché sur le réseau 4G, il bascule vers le réseau 3G, et le mobile envoie une réponse
d’acquittement vers le cœur de réseau en commutation de circuit (CS-Core). A partir de
ce moment, toute la signalisation pour la session d’appel téléphonique est prise en charge
par le réseau 3G. La figure 1 rappelle l’architecture des deux réseaux : CS sur le réseau
3G et PS sur le réseau 4G (EPC)

Figure 1 : Coeur Réseau 2G/3G et 4G

Pour que le Coeur de réseau 4G (EPC : Evolved Packet Core) soit compatible avec la
technologie CSFB, il est nécessaire que ce dernier puisse communiquer avec le cœur de
réseau en commutation de circuit CS-Core du réseau 2G/3G. En effet, le MME (mobility
Management Entity) doit pouvoir contacter le MSC (Mobile Switch Center) et la VLR afin
de donner procuration au réseau 2G/3G de la gestion de la mobilité. L’interface utilisée
se nomme SG, et fait référence, en reprenant son rôle, à l’interface Gs existante entre le
SGSN et le MSC dans le réseau 3G.
Lorsque l’appel est accepté, la technologie CSFB utilise à nouveau l’interface SG pour
informer le réseau LTE de l’acceptation de l’appel. L’acquittement est donc transmis par
le réseau en Commutation de Circuit (CS) vers le réseau LTE en empruntant l’interface
SG.

Technologie de transport de la voix en

4G : CSFB (part 2)

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

Comme nous l’avons entrevu dans le précédent article, un réseau doit en permanence
savoir localiser un mobile afin de fournir les services à l’ayant droit. La procédure de
localisation se nomme « Mobility Management », c’est-à-dire Gestion de la mobilité.
Pour terminer un appel via la fonction CS Fallback, le domain CS doit connaitre la position
du mobile en se référant à la localisation fournie par le réseau LTE, c’est-à-dire en se
basant sur l’aire d’enregistrement du mobile indiquée par le MME. Le MME a donc la
charge d’informer la VLR de la zone de localisation du mobile sur le réseau 4G.
Le cœur de réseau 3G possède déjà la fonction permettant de gérer simultanément la
mobilité sur le réseau en commutation de circuit (CS) et en commutation de paquets(PS),
chaque mobile étant géré sur une zone nommée LA (Location Area) pour la partie CS et
RA (Routage Area) pour la partie PS.
Afin de réduire le trafic de signalisation sur les réseaux mobiles 2G/3G et 4G,
l’enregistrement de localisation du mobile sur le réseau SGSN par la VLR est ré-utilisé
par la technologie CS FallBack : Concernant les informations de localisation du mobile
sur le réseau 4G (TA : Tracking Area), le MSC/VLR exploite donc la même logique que
pour le réseau PS en 3G, c’est-à-dire la VLR demande les données d’enregistrement du
mobile sur le réseau 4G et les exploite de manière identiques aux données
d’enregistrement de localisation fournies par les requêtes venant du SGSN.
Cela permet d’une part d’éviter une mise à jour trop fastidieuse des MSC pour prendre
en compte les requêtes de localisation sur le réseau 4G pour la voix.
Il faut également se rappeler qu’un terminal sur le réseau 4G ne peut être sur le réseau
2G/3G en même temps. Ceci implique que le MME, qui contient la zone d’enregistrement
du mobile sur le réseau LTE (TA) doit être en mesure d’identifier vers quel VLR il doit
envoyer ses messages de gestion de mobilité. Le MME contient donc une base de
données de localisation permettant d’avoir la correspondance entre la zone de
localisation du réseau 4G (TA) avec la zone de localisation du mobile sur la VLR (LA).
Cette base de données permet donc de déterminer quel MSC/VLR doit être contacté pour
l’enregistrement de la localisation du mobile.
La figure 2 détaille l’échange d’information entre le MME et la VLR : La VLR a identifié le
MME sur lequel était géré le mobile et le MME connait la VLR et le LA associé à la position
du mobile si ce dernier est sur le réseau 3G CS. A l’inverse, la VLR connait l’équipement
MME associé.
 Figure 2 : Mise à jour des données de localization sur la VLR et le MME

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

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

SRVCC – Single Radio Voice Call Continuity

Lorsque le réseau VoLTE sera déployé (2ème semestre 2015), l’opérateur devra garantir la
continuité d’appel en réalisant
 Un HandOver entre le réseau 4G et le réseau 2G/3G (nommé IRAT Handover) tant pour
l’appel téléphonique (passage de la voix du domaine PS vers le domaine CS) que pour les
sessions Data
 Un Transfert de session au niveau du cœur réseau entre le MME et le MSC. L’appel est
géré par le réseau IMS, et plus précisément pour les mobiles compatibles SRVCC (Single
Radio Voice Call Continuity), le point d’ancrage de l’appel est réalisé par un serveur
d’application nommé SCC AS (Service Centralization and Continuity).
Nous allons dans un premier temps décrire les notions Single Radio et Voice Call Continuity
(SCC AS). Le SCC AS est un serveur d’application IMS, cette solution se diffère donc du CSFB
pour lequel l’IMS n’est pas mis en place.
SCC AS
Avec le déploiement de l’IMS, lorsque le mobile émet ou reçoit un appel, la requête SIP
INVITE est transmise jusqu’au S-CSCF. L’exécution de la tâche qui est associée (renvoi de la
requête vers un AS) dépend des règles de souscription de l’abonné et la tâche qui est réalisée
est obtenue en appliquant l’événement (par exemple un appel) à la liste de règles définie à
travers les paramètres du filtre iFC (initial Filter Criteria). Si le mobile n’est pas compatible au
mécanisme SRVCC ou si ce dernier n’est pas déployé, l’appel sera transmis au Serveur
d’application Téléphonie (TAS : Téléphony Application Server). Dans cet article, le cas qui
nous intéresse est le mécanisme SRVCC on suppose donc que la technologie est déployée et que
le mobile est compatible, dans ce cas, l’appel sera dirigé vers un serveur qui sera considéré
comme le serveur d’ancrage dans le réseau IMS. Ce dernier se nomme SCC AS avec la
particularité suivante :
 Si l’UE est à l’origine de l’appel, l’appel sera transmis d’abord au SCC AS avant d’être
traité par le TAS.
 Si l’UE est à destination de l’appel, l’appel sera transmis au TAS qui le transfert au SCC
AS.
 ICS : IMS Centralized Service.

Single Radio ou Dual Transfer Mode

La solution CSFB que nous avons étudiée est un mécanisme transitoire permettant, au
téléphone en mode 4G initiant un appel, de passer du réseau LTE (PS) au réseau 2G/3G (CS).
Dans le cas où le téléphone migre vers le réseau 3G, les sessions Data en commutation de
paquets peut à la fois gérer les services datas et la voix (VoHSPA).
Dans le cas de la migration vers la 2G, les sessions Datas seront suspendues jusqu’à la fin de
l’appel téléphonique en CS c’est à dire jusqu’à ce que l’UE revienne sur le réseau 4G, sauf si
l’UE 2G supporte le Dual Transfer Mode (DTM) qui permet à la fois la voix et la Data.
SRVCC: Single Radio Voice Continuity Call

L’arrivée de la VoLTE est concomitante avec le déploiement du réseau 4G de l’opérateur, il est

donc nécessaire de pouvoir basculer l’appel en VoLTE sur le réseau IMS vers le réseau
traditionnel en cas de perte de couverture 4G, tout en garantissant la QoS.
C’est le rôle du mécanisme SRVCC que de basculer l’appel du mode PS 4G vers le mode CS
2G/3G. Cela impacte le MSC car ce dernier doit gérer l’appel de l’UE vers le point d’ancrage
IMS. Le MSC est renommé « MSC Server enhanced for SRVCC ». La méthode présentée est à
la fois compatible pour la VoLTE et la VoHSPA.
NB : Il y a deux mécanismes SRVCC, le premier SRVCC vers le GERAN/UTRAN que nous
abordons ici et proposé par le 3GPP, le second permet de basculer vers le réseau CDMA et est
proposé par le 3GPP2.
Les entités impactées par ce mécanisme (SRVCC – R10) sont :
  UE
 MSC
 eNb
 MME
 P-CSCF
 HSS

Avec l’ajout de deux autres entités lors de la R10 :
 ATCF : Point d’ancrage de la signalisation SIP
 ATGW : Sous le contrôle de l’entité ATCF

Le MME dans cette procédure doit être en mesure :

 Séparer le flux Data (PS) du flux Voix (géré par le mode CS après basculement)
 Gérer le handover des bearers PS non voix avec la cellule cible
 Initier la procédure de handover SRVCC (en s’appuyant sur le QCI=1)
Une nouvelle interface, nommée Sv, est créée entre le MSC et le MME. Cette interface permet
au MME de:
 Demander au MSC de réserver des ressources radios au niveau de l’interface d’accès radio
CS (BTS ou Noeud B). Le MSC est donc responsable de la réservation de ressource pour
la continuité d’appel
  Donner l’adresse du SCC AS au MSC afin que ce dernier émette une demande d’appel de
la part de l’UE.
Procédure
Au cours de l’attachement au réseau, le MME récupère le STN-SR (Session Transfer Number
for SR-VCC) de la part du HSS. Il s’agit d’un numéro au format téléphonique répondant à la
spécification E.164. C’est cette adresse que le MME transmet au MSC afin que ce dernier puisse
émettre un appel et créer un acheminement entre l’UE et le point d’ancrage IMS.
En effet, l’objectif du SRVCC est de transférer l’appel PS vers le mode CS, or l’appel est géré
par le réseau IMS, et plus précisément par un serveur d’application nommé SCC (Service
Centralization and Continuity). Le MSC quant à lui a besoin d’un numéro d’appel ou de
commutation pour réaliser la jonction avec le réseau IMS. Le STN-SR est envoyé du MME au
MSC via l’interface Sv.

Le MSC initie une requête SIP vers l’IMS via le numéro STN-SR. Le SCC-AS reçoit la
requête INVITE avec le STN-SR avec le message de demande de transfert d’une session active.
C’est au SCC AS de gérer ce transfert de session.
Sur le call flow suivant, on retrouve les deux étapes du SRVCC
 un HandOver
 un Transfert de session
Dans un prochain article, nous détaillerons la procédure.

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ées, le chemin de signalisation et d’appel
est représenté par la figure ci-dessous.

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

Gratuité de l’itinérance (Part 1): Bouygues

dégaine en premier
Architecture du Roaming LTE

En début d’année, les opérateurs (Free, suivi de Bouygues puis Orange) avaient annoncé
la gratuité du Roaming (itinérance) sur l’ensemble de l’Europe ou dans certains pays
(Italie, Portugal pour Free), et/ou réservé à quelques abonnements. Ainsi, par exemple
Bouygues avait annoncé le 22 janvier l’itinérance gratuite en Europe sur ses forfaits
Sensation à partir du 24 février.
Nous allons montrer dans cet article comment la gratuité peut être effective sur le réseau
4G. Mais, comme l’objectif de toute entreprise, c’est de gagner de l’argent, nous
aborderons donc dans cet article la partie facturation (billing) et le chargement
d’information de tarification sur le type de service (charging).
Dans un premier temps, il faut revenir sur le concept de routage pour la LTE, le
fonctionnement du LTE se diffère à ce niveau par rapport à la téléphonie 2G/3G. En effet,
il existe deux méthodes de routage, le Home Routing et le Local breakout. A chaque
méthode est associée des processus de tarification qui différent par conséquent par
rapport à la 2G et 3G).
Nous allons donc naturellement commencer cet article par l’architecture de Roaming du
LTE
I-1) Roaming LTE
Un réseau mobile déployé par un opérateur dans un pays se nomme PLMN (Public Land
Mobile Network). Chaque utilisateur ayant souscrit à un opérateur utilise de préférence
le réseau de cet opérateur, on parle de H-PLMN (Home PLMN). L’itinérance (roaming)
permet à cet utilisateur de se déplacer en dehors du réseau de son opérateur et d’utiliser
les ressources d’un autre opérateur (concurrent ou complémentaire). Cet opérateur est
appelé V-PLMN (Visited PLMN).
Un utilisateur en itinérance est connecté à l’interface E-UTRAN, au MME et au S-GW du
réseau LTE visité. Cependant le LTE/SAE permet de router les paquets vers un P-GW
lequel appartient soit au réseau de l’opérateur visité (V-PLMN) soit à celui de son propre
opérateur (H-PLMN), comme le montre la figure ci-dessous.

L’avantage du Home Routing est la capacité d’accéder aux services souscrits chez son
opérateur (H-PLMN) même si le client (abonné) est sur un réseau visité. Le P-GW dans
le réseau visité permet à l’abonné un accès local (Local Breakout) au réseau Internet via
le réseau de l’opérateur visité.
L’interface entre le S-GW (Serving Gateway) et la passerelle P-GW permettant d’accéder
au réseau de données (PDN : Packet Data Networks) est nommée S5 dans le cas du
Local Breakout ou S8 pour le Home Routing.
I-2) LTE roaming Charging

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

plus nombreux que pour la 3G
 Les cartes Pré-payées. Le standard CAMEL, qui permet l’accès par pré-payement
aux services 3G n’est pas compatible avec la 4G. Ains, les accès au réseau PDN
par des utilsateurs de cartes pré-payées doivent être obligatoirement routées vers
le H-PLMN et ne peuvent donc pas être routés via le V-PLMN. Les opérateurs
doivent donc mettre en place un flux de taxation spécialement dédié au clients de
carte prépayé afin que ces derniers puissent accéder au PDN via leur P-GW
 Les forfaits : La facturation s’appuie sur les mêmes tickets que le 3G.
Dans le cas de Local breakout, les opérateurs n’ont pas la même visibilité sur les activités
des abonnés puisque la connexion de l’abonnée est gérée par le V-PLMN. Cependant,
afin que l’opérateur Home puisse avoir des informations en temps réels (nécessaire entre
autre pour les forfaits bloqués), il doit établir une interface DIAMETER entre son système
de facturation et le P-GW du réseau visité.
Dans le cas d’un Local Breakout sur des services IMS, le réseau visité crée un CDR (Call
Detail Records ) en provenance du S-GWS-Gateway(s). Cependant le CDR ne contient
pas toutes les informations requises pour créer un TAP selon la version 3.12 pour le
service utilisé (évènement ou session). En conséquence de quoi, les opérateurs doivent
corréler les CDRs émis par leur proper réseau avec le CDR crée par l’IMS pour constituer
un enregistrement TAP.
I-3) TAP 3.12
TAP : Transferred Account Procedure est le mécanisme permettant aux opérateurs
d’échanger des informations de facturations des clients en roaming. TAP 3.12 correspond
à la version 12 et la release 3, laquelle décrit la syntaxe des fichiers TAP transmis entre
les opérateurs depuis le 1er mai 2013.
Le TAP est transmis au HPLMN au plus tard 36 heures après la fin de la session.

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

des UE
Part 2 : Gestion de la mobilité

II-1) – La signalisation

Le réseau GSM et 3G s’appuie sur l’architecture traditionnelle de la téléphonie commuté

et exploite le protocole de signalisation SS7 (cf. http://mooc-ipad-formation.eu).
Ainsi, la gestion de la mobilité, la gestion de la localisation et de l’authentification étaient
pris en charge par le protocole MAP (Mobile Application Part).
Ce protocole décrit les messages transmis entre les différents équipements du réseau de
l’opérateur Home (HPLMN) et l’opérateur visité (VPLMN). Lors d’une première phase de
migration vers l’IP, la signalisation SS7 initialement transportée sur des liens traditionnels
TDM comme le E1/T1 est dorénavant encapsulée sur l’IP via le protocole SIGTRAN.
Mais, le réseau LTE n’utilise pas le protocole de signalisation SS7 : Diameter a été préféré
et remplace le protocole MAP en supportant toutes ses fonctionnalités.
Le protocole DIAMETER a été adapté pour le LTE afin de gérer la gestion de mobilité
des UE au sein du LTE mais le protocole doit également assurer l’interconnexion entre
le LTE et les réseaux 2G/3G (DIAMETER to MAP). Pour échanger des données de
signalisation, DIAMETER utilise des AVPs (Attribute Variable Pair) afin d’encapsuler les
données en provenance d’applications reconnues.
Sur le tableau suivant, en guise d’exemple, nous donnons la traduction des messages
MAP/DIAMETER.
II-2) L’architecture du réseau LTE

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

Les interfaces en rouges sont exploitées lors du roaming, nous allons les détailler pour
plus de clarté :
 Gestion de la mobilité :
L’interface S6a permet de transférer des données d’authentification et de localisation
entre le MME et le HSS via Diameter afin d’autoriser ou non l’accès d’un utilisateur au
réseau LTE.
En général, l’authentification est réalisée en respectant le protocole AAA lequel réalise
trois fonctions : l’authentification, l’autorisation, et la traçabilité (en anglais :
Authentication, Authorization, Accounting/Auditing)

L’interface S6d autorise les échanges d’informations relatives au protocole AAA entre le
SGSN et HSS sur (over) DIAMETER.
 Policy Control and Charging

L’interface S9 transfère la politique de contrôle de la QoS et les informations de taxation

entre le HPCRF (Home Policy and Charging Rules Functionality) et le PCRF (Policy and
Charging Rules Function) du V-PLMN toujours sur Diameter (cf. architecture SAE/LTE)
Le PCRF supervise les flux sur le réseau LTE : Il peut détecter les types de flux et de
services (DPI : Deep packet Inspector) et met en relation la taxation adaptée
(abonnement, calendrier) sur ce type de flux.
 GTP Traffic

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

II-3) Mise à jour de la localisation

Lorsqu’un utilisateur authentifié est en déplacement, le premier message reçu par le cœur
de réseau est un message de Mise à Jour de la localisation (Location Update), quel que
soit le protocole MAP ou DIAMETER utilisé.
Cependant, dans le cas
 GSM MAP; le message ISD (Insert Subscriber Data) transporte le profil complet de
l’abonné et si l’information complète ne peut être transmise dans un seul message
ISD, le V_PLMN demande la transmission des informations complémentaires via
d’autres messages ISD.
En 2G/3G, le protocole INAP/CAMEL est utilisé chaque fois qu’un utilisateur est en
itinérance sur un autre réseau. LTE ne supporte pas le protocole CAMEL, il n’existe pas
de traduction de message INAP vers le protocole DIAMETER
 Pour DIAMETER, le LUA (Location Update Answer) transporte le profil de l’abonné.
Ainsi, le DIAMETER ISD n’est utilisé que lorsque le H-PLMN demande un
changement dans le profil de l’abonné.
Sur les figures ci-dessous, nous illustrons la partie Location Update via le protocole MAP
(figure de gauche) et via le protocole Diameter (figure de droite)
II-4) Contrôle de la politique de QoS et facturation en temps réel

Dans le précédent article, nous avions vu deux techniques de routage de trafic, soit via
le P-GW du réseau visité (Local Breakout) soit via le P-GW du réseau home (Home
Routing).
Dans le premier cas, il est nécessaire de définir un accord pour échanger les informations
de contrôle d’appel via l’interface Gy entre les deux PLMN. Ainsi, le PDN du V-PLMN
peut interagir directement avec le système de tarification (charging system) du H-PLMN.
II-4.1) Home Routing

Basons-nous sur l’architecture du LTE, en focalisant notre attention sur les équipements
impliqués lors du roaming. Sur la figure suivante, le V-PCRF communique avec le H-
PCRF via l’interface S9 mais la facturation en temps réel (Real Time Charging) n’est pas
transmise sur l’interface S9, mais via l’interface Gy selon le protocole DIAMETER RFC
3588.
Concernant le roaming 2G/3G vers la 4G (on parle de roaming INTER-RAT), il faut savoir
que le PCEF n’est pas pris en charge sur le réseau 2G/3G, ce qui pose un souci de QoS
lors d’un roaming inter-RAT. En effet, dans le cas du réseau 2G ou 3G, le GGSN était
dédié aux données et la QoS était spécifiée par la création d’un PDP context, la
téléphonie était géré par le MSC, les SMS par le SMSC, et les services avancés par
CAMEL.
II-4.2) Local Breakout

La procédure est légèrement différente, puisque c’est le PCEF du réseau visité qui
transmet les informations de facturation en temps réel au H-PLMN. Les mêmes interfaces
que précédemment sont utilisées.
Gestion de l’itinérance (Part 3) : IP eXchange – IPX
IPX : IP eXchange

Le roaming de Data (et de la VoIP) n’est pas qu’un simple échange de flux entre les
différents opérateurs car les opérateurs (V-PLMN et H-PLMN) doivent aussi assurer sur
le réseau visité la même qualité pour les services souscrits par l’abonné par rapport à
l’accès aux services sur le réseau nominal (HPLMN), tout en assurant l’intégrité des
données et la sécurisation du flux. C’est à ce prix-là que les opérateurs pourront se
différencier des OTTs et vendre la plus-value des services proposés (RCS, VOLTE, …)
Le réseau IPX est un réseau IP autorisant une interconnexion entre plusieurs opérateurs
mobiles et opérateurs fixes, dont les conditions de raccordements (interconnexion) et
surtout de services sont stipulés par des accords entre les opérateurs et les fournisseurs
de services. L’objectif est d’assurer la qualité d’expérience du client (QoE) en spécifiant
contractuellement les accords entre les différents acteurs et monnayer la plus-value
apportée par chaque maillon de la chaine de transport (SLA : Service Level Agreement).
IPX est donc un réseau IP d’interconnexion proposé par les opérateurs afin de garantir
une qualité d’échange de données via des accords commerciaux sur des spécifications
techniques. Chaque service doit être transmis sur le réseau d’un opérateur selon la
spécification de QoS correspondant au service en question : La voix et la Vidéo
supposant une demande de QoS élevée doit être transmises sur des bearers (Canaux
de Données) prioritaires alors que les MMS seront transportés sur des bearers de
priorités basses. Cela nécessite donc que la facturation pour chaque flux soit
contractualisée entre les différents opérateurs pour que la rémunération soit couplée au
type de réservation de liens mis en place par les opérateurs.

L’IPX permet aux opérateurs de définir plusieurs accords afin de garantir les services
proposés à ses abonnés ou qu’il soit dans le monde comme par exemple les services
suivants : Rich Communication Suite-enhanced (RCS-e), Near Field Communication
(NFC), Voice over LTE (VoLTE), Mobile Money (paiement par mobile).
L’IPBX doit donc répondre aux points suivants :
 Un Environnement sécurisé : Le réseau IPX est un réseau IP transparent non
accessible depuis Internet.
 Des services d’interconnexions IP flexibles et ouvert à tout opérateur fixe ou mobile
et fournisseur de service (ISP): Un seul contrat pour des accès plus facile et plus
rapide aux services « à la carte »
 Contrat Bilatéral : Le fournisseur de service paye un lien assurant la QoS de
bout en bout (comme une demande de lien privé sur différents opérateurs)
 Contrat Multilatéral : Un seule contrat mais de multiples connexions. Un
fournisseur de service peut joindre plusieurs pays.
 Suivi de la Facturation (Cascading Payments) : Gestion des flux
d’informations nécessaire à la mise en place des connexions entre les
opérateurs et les fournisseurs de services. Chaque opérateur est responsable
des performances des flux sur la partie du réseau qu’il exploite.
 Qualité d’interconnexion : Le trafic doit être géré en respectant la QoS et les
niveaux de services doivent être spécifiés par contrat entre opérateurs (SLA)
Gestion de l’itinérance (Part 4) : VoLTE
Roaming LTE

VOLTE (prononce volti:) fait référence à plusieurs technologies pour délivrer des
communications en temps réels par paquets IP. Le VOLTE permet de fournir des services
existants comme la voix et les SMS sur le réseau LTE. Le standard IR.92 proposé par le
GSMA s’appuie sur une partie de l’architecture IMS. L’IMS, pour résumer, est une plate-
forme standardisée pour délivrer des services multimédias sur un support IP.
L’itinérance sur le réseau IMS (IMS Roaming) est spécifiée dans le document GSMA
IR.65, faisant lui-même référence au document 3GPP 32 221. Nous allons utiliser ces
documents pour écrire cet article.
Dans le cas du roaming LTE, on suppose l’interconnexion entre deux opérateurs
assurées par un réseau de transport qualifié IPX.
La signalisation (par exemple TAU : Location Update du terminal par le protocole
Diameter) et le roaming de données (Applications IP encapsulées dans un tunnel GTP)
sont échangées entre l’opérateur A (Home – Opérateur nominal) vers l’opérateur B
(Visited) via IPX.
 Figure 1 : Roaming entre 2 réseaux LTE via un fournisseur de service IPX
Le fournisseur de service IP, nommé IPX est connecté aux réseaux des opérateurs LTE
via une passerelle de bordure (BG). Dans la norme GSMA (IR.65), l’IPX se nomme
InterService Provider.
Dans le cadre du VoLTE, la téléphonie est prise en charge par le réseau IMS (IP
Multimédia Subsystem). Pour un UE, dans son réseau nominal ou un réseau visité, il y
a trois possibilité de se connecter à un serveur IMS comme le présente la figure 2
 Figure 2 : Domaines d’adressages IP vers le réseau PS et IMS
Un UE souhaitant accéder au sous-système IMS nécessite une adresse IP. Une fois
l’adresse octroyée, il est possible de connecter le P-GW/GGSN du réseau visité ou du
réseau nominal au serveur IMS. Lorsque l’UE est sur un réseau visité, pour des raisons
d’efficacité (lien direct notamment en roaming) il peut être préférable de connecter l’UE
au réseau IMS du réseau visité comme le montre la figure 1 ou de passer par le réseau
IMS du réseau nominal (Figure 2).
Il faut bien noter que l’accès au réseau visité IMS (l’accès au Proxy du réseau IMS,
nommé P-CSCF) est directement connecté au PGW du réseau visité.
Figure 3 : L’UE accède au réseau IMS du réseau visité via le PGW du réseau visité
Dans le cas où l’IMS exploité est dans le réseau de l’opérateur nominal, l’UE a une
connectivité IP sur le réseau visité mais toutes les fonctionnalités IMS sont fournies par
l’opérateur nominal (Home Network).
Figure 4: L’UE accède au réseau IMS du réseau nominal via le PGW du réseau visité
La différence est la suivante, l’UE est virtuellement présente sur le réseau de l’opérateur
nominal. Il faut bien noter que l’accès au réseau IMS du réseau home (l’accès au Proxy
du réseau IMS, nommé P-CSCF) est directement connecté au PGW du réseau visité.
Enfin, dans le troisième cas de figure (figure 5), le réseau IMS utilisé est celui de
l’opérateur nominal, comme c’était le cas précédemment sur la figure 4, mais en passant
par le PGW du réseau nominal

Figure 5 : L’UE accède au réseau IMS du réseau visité via le PGW du réseau visité

Pour bien comprendre la différence, il est nécessaire de décrire le réseau IMS, et les
équipements de la couche de contrôle (CSCF).
Pour simplifier et finir cet article sur le roaming, nous allons illustrer le roaming LTE par
la figure 6 ci-dessous qui montre les différents types de roaming qui est une autre
représentation de la figure 2.
 Figure 6 : Domaines d’adressages IP vers le réseau PS et IMS
Cette figure suppose un réseau Full IMS avec la gestion de la QoS via un opérateur tiers.
Or, le déploiement du VoLTE est une finalité en soi, en réalité à ce jour différentes
techniques sont mises en œuvre pour contourner la VoIP sur le réseau LTE.
En effet, si l’objectif principal est de promouvoir l’utilisation du réseau de commutation de
paquets (réseau IP) pour fournir des services multimédias (communication téléphoniques
ou visiophonie) avec la même qualité de service que celle offerte par la commutation de
circuit et sans coupure. La difficulté est donc double : le maintien de la QoE (Quality Of
Experience), et l’interconnexion pour le service de la voix entre un réseau tout IP (LTE)
et un réseau 2G ou 3G (commutation de circuit). Durant cette transition de la 4G, diverses
alternatives sont proposées pour la transmission de la voix :
 CSFB : Circuit Switch FallBack
 SRVCC : Single Radio Voice Call Continuity permet l’interconnexion entre le réseau
à commutation de paquets (PS) et commutation de circuit (CS) sans incidence sur
la QoE
 VOLTE