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

SRVCC_fig3

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 transfère au SCC AS.

SRVCC_fig1

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

SRVCC_fig2

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.

SRVCC

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

SRVCC_callflow

Dans un prochain article, nous détaillerons la procédure.

VoLTE – Principe de base

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

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

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

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

Principe général

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

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

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

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

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

defaultbearer_ims

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

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

Phase 2 : Signalisation Téléphonique – Enregistrement

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

Phase 3 : Signalisation Téléphonique – Appel

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

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

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

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

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

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

Dedicated_bearer

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

CSFB : Call Switch FallBack (2)

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

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

CSFB_callflow_complet

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

CSFB_time1

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

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

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

Différences entre handover et redirection

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

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

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

CSFB_time

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

  • Basic
  • SIB Skipping
  • SI Tunneling

Redirection Basic

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

SIB Skipping

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

R9 Enhanced Release with Redirection—SI
Tunneling

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

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

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

CSFB_rrc

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

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.

CSFB_principe

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

Combined_attach

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.

DoCoMo_MME1_database

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 rediriger l’UE du réseau LTE vers le réseau 3G.

CSFB_callflow

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.

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)

EMM call flow

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 :

Figure 2. Initial Attach Cases by Unknown UE

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

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

lte_control_plane_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

Figure 1. Summary of Initial Attach Procedures

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.

Figure 2. Procedure for IMSI Acquisition

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.

RRC_establishment

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

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

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

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

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

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

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

2-b)  La requête d’attachement

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

2-b.1) S1 Signaling Connection Establishment

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

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

Initial UE message

 

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

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

2-c)  ECM Connection Establishment

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

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

2-d) IMSI Acquisition 

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

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

II.2 Authentication

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

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

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

Figure 3. Procedure for Authentication

1) Acquisition du vecteur d’authentification

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

  • RAND : Un nombre aléatoire
  • AUTN : Le sceau d’authentification appelé aussi jeton d’authentification. utilisé par l’application USIM pour authenfier l’EPS
  • XRES : Le résultat de l’authentification de l’UE selon la clé connue par le HSS (laquelle est aussi enregistrée sur l’UICC). XRES est le résultat calculé au niveau du réseau à partir du RAND et des paramètres connues de l’UE.
  • 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.

(XRESAUTN, 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)

Figure 4. Generating Authentication Vectors

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.

Authentification_4G


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

Figure 5. Procedure for NAS Security Setup

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.

Figure 6. Procedure for Location Update

 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

Figure 7. Procedure for EPS Session Establishment (1)

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 :

Table 2. EPS Bearer ID value assignment range

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

◇ 13) ~ 15) EPS Session Creation Response

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

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

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


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

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

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

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

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

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

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

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

Figure 8. Procedure for EPS Session Establishment (2)

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

Pool de MME

I) Principe et rappels

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

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

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

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

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

imgf0001

II) Enregistrement de l’UE sur Plusieurs TA

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

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

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

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

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

IV) Mécanisme ISR

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

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

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

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

Etats RRC – ECM – EMM

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

asnas4G

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

emm_1

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

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

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

Figure 2. EMM State Transition

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

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

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

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

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

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

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

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

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

Etat_EMM_ECM

Bearer EPS

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

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

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

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

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

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

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

Figure 1. Overview of Session Bearer IDs

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

II) Différents Bearer physique

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

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

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

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

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

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

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

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

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

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

III) Deux types d’EPS Bearer

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

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

Figure 2. EPS Bearer Types

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

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

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

Protocole RRC

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

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

Le NAS a pour rôle de permettre :

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

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

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

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

lte_control_plane_RRC

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

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

lte_protocol_layers

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

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

asnas3G

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

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

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.

 

LTE_UMTS