LTE et WiFi : Les attentes de la R.13 et R.14

WIFI et LTE
En général, on choisit un mode d’accès WiFi ou LTE pour accéder à Internet et pourtant, actuellement, les terminaux peuvent se connecter simultanément au WiFi pour toutes les sessions IP ne nécessitant pas de QoS, et au réseau LTE. L’accès au WiFI est souvent préférable pour l’utilisateur lorsqu’il peut profiter d’un débit plus élevé que par le LTE et préférable pour l’opérateur qui décharge ainsi ses stations de base pour un trafic vers des utilisateurs résidents.
Par contre, dans le cas ou le débit du WiFi est faible (soit ponctuellement à cause d’un encombrement ou factuellement car le point d’accès est loin du DSLAM), lorsque l’utilisateur configure son smartphone pour un accès WiFi, ce dernier utilisera cet accès même si la qualité d’expérience serait meilleure en LTE.
Afin d’aider l’UE à se connecter au meilleur réseau, et définir des règles de politiques en fonction des applications (temps réels ou non), l’opérateur déploie l’entité ANDSF (Access Network Discovery Selection Function) dans le cœur du réseau.
Dans la R.8, lorsque l’UE détecte la présence du WiFi, tout le trafic était routé via le point d’accès WiFi ou restait en 4G.
La R.9 propose un mécanisme (MAPCON : Multi Access PDN Connectivity) permettant plusieurs connexions IP sur le réseau WiFi et sur le réseau LTE.  Dans ce cas, l’entité ANDSF indique quel accès radio choisir pour différentes applications en fonction de règle de trafic se basant sur l’identification de l’APN, l’adresse IP et le port de destination. Les règles s’appellent ISRP (Inter System Routing Policies).
La R.11 apporte plus de flexibilité sur l’analyse des flux comme par exemple séparé des applications temps réel ou non qui utilisent le même port http, définir une règle en fonction du débit attendu, de la taille du fichier, …
La R.10 propose également une mobilité des flux : un flux IP sur un réseau d’accès peut sans coupure être dirigé vers un autre réseau d’acccès (DSMIPv6 : Dual Stack Mobile IPv6), cependant les opérateurs ont préféré utiliser la mobilité sur le protocole GTP, et la R.13  propose la solution de mobilité IFOM (IP Flow Mobility)
Dans la release R.12, le réseau LTE propose une procédure de sélection du réseau afin d’aider le smartphone à choisir le meilleur réseau d’accès. Dans cette release, le réseau configure un niveau de puissance du signal ce qui permet au dispositif de comparer la puissance reçue à ce niveau et ainsi déterminer sur quel réseau d’accès exécuter la session IP.
La R.12 propose aussi à l’UE de profiter d’une double connexion : Connexion LTE et connexion WiFI simultanée. Il s’agit d’aggrégation dans le cœur réseau et celle-ci s’effectue au niveau de l’entité PGW (PDN Gateway).
Deux scénarios d’agrégation existent :
  1. LWA : L’agrégation des accès LWA (LTE / WLAN Aggregation) s’effectue au niveau de la couche PDCP de l’eNb et le point d’accès WiFI
  2. LWIP L’agrégation des accès LWIP (LTE / WLAN radio level integration with IPsec tunnel) s’effectue au niveau du SGW et le point d’accès WiFi

La R.13 propose l’utilisation du spectre WiFi pour émettre des signaux LTE. L’opérateur déploie des eNb qui émettent dans la bande du WiFi pour faire de l’agrégation de porteuses (CA). Les eNb déployés ne doivent pas interférer avec les bornes WiFi, il est donc nécessaire de mettre en œuvre des mécanismes d’écoute avant émission (LBT/CCA) avant d’émettre. On parle de LAA – License Assisted Access.

  • La R.13 propose le LAA uniquement sur le DL
  • La R.14 propose le LAA sur le DL et UL sur 32 bandes de 20 MHz

MTC : Le réseau M2M / IoT sur la 4G – 2ème partie

Au cours de l’article précédent, nous avions évoqué les évolutions du réseau 4G vers le MTC. Cette évolution est une brique de base pour le réseau 5G et les fonctionnalités que nous avions décrites sont les 4 suivantes :
• control plane CIoT EPS optimization
• user plane CIoT EPS optimization
• EMM-REGISTERED without PDN connection
• S1-U data transfer and header compression

(Je vais reprendre la notation de l’article précédent)
II-3-a) Control plane CIoT EPS optimisation
C-Plane CIoT EPS Optimization est une méthode destinée à encapsuler les données utilisateurs dans les messages du plan de contrôle. En évitant de mettre en place de la signalisation pour rétablir les bearer, cette méthode permet de réduire le nombre de message sur le plan de contrôle lorsque les données à transmettre sont de petites tailles et par conséquent, on réduit la bande utilisée et la consommation du dispositif.
Les fonctionnalités supportées par cette méthode sont :
• Transport de données utilisateurs (IP et Non IP)
• Point d’ancrage de la mobilité du dispositif
• Compression d’entête pour les flux IP
• Protection par intégrité et chiffrement de la Data transmise dans le plan de contrôle
• Interception légale.
Cette méthode s’appuie sur le MME, ce dernier est considéré comme un nœud de transfert de données et l’eNb est vu comme un relai :
• entre l’UE et le PGW (connectivité PDN : UE -> eNb -> MME -> SGW -> PGW) en utilisant les protocoles de signalisation (S1-AP et GTP-C)
• ou entre l’UE et l’entité SCEF (connectivité PDN : UE -> eNb -> MME -> SCEF).

Si l’UE a un stack IP, les données sont transmises en IP de l’UE vers le PGW.

Figure 5a : Control plane IP DATA

Si l’UE ne contient pas de stack IP (NIDD), les données sont transmises au MME via le protocole S1-AP et envoyées soit vers le PGW soit vers le SCEF. Lorsque l’UE fait une demande de connexion vers l’AS en non IP, l’UE indique l’APN  de passerelle. Le choix de la connectivité PDN entre le PGW et le SCEF est défini au niveau du HSS dans la donnée de souscription APN.

Le profil du device au niveau du HSS indique l’APN que doit utiliser le dispositif pour transmettre des données non IP. L’APN route les messages vers le PGW ou vers le SCEF.

On considère ici que l’APN renvoie vers le PGW.

Lorsque l’UE fait une demande d’attachement, il indique :

  • Qu’il souhaite une connection PDN non IP
  • Le réseau utilise l’APN fourni par l’UE ou l’APN contenu dans le profil de l’UE au niveau du HSS et transmis au MME
  • Le PGW donne à l’UE la taille maximale autorisée des paquets (qui peut etre de 128 octets)
  • Les paquets non IP sont transmis via le plan de contrôle par des messages NAS

 

Figure 5b : Control plane Non IP DATA vers le SGW

 

Connection non IP via le SCEF

Dans les deux cas, l’UE émet une demande de transmission de données via la procédure RRC SERVICE REQUEST en encapsulant le message ESM DATA TRANSPORT (message NAS entre l’UE et le MME via l’eNb en relais). Dans le cas précis ou l’UE ne contient pas de stack IP, il informe le MME qu’il souhaite établir une connexion PDN non IP.

Dans le cas de données entrantes :

  • Les données peuvent être bufferisées dans le SGW lequel transmet un message de notification « Downlink Data Notification Message » au C-SGN. Le C-SGN répond au SGW en indiquant le temps restant avant que le device soit joignable (PSM Mode). Cela permet au SGW d’étendre le temps pendant lequel le message sera conservé.
  • Les données peuvent être bufférisées dans le SCEF

 

II-3-b) User plane CIoT EPS optimisation

Dans le cas ou l’UE supporte l’optimisation sur le plan de données (User Plane CIoT EPS Optimization), il doit obligatoirement supporter la méthode S1-U Data transfer. Ainsi,  les données sont transmises via l’interface S1-U, c’est-à-dire entre l’eNb et le SGW.

L’optimisation User plane CIoT EPS optimisation est apportée par une amélioration du contrôle de bearer et par de nouveaux messages RRC ainsi que de nouveaux états RRC permettant un établissement de bearer plus rapide et plus efficace.

 

Les nouveaux états RRC sont : RRC-Suspend et RRC-Resume.

  • Procédure RRC Suspend. Cette procédure est activée par l’eNb permet de libérer le bearer radio entre l’eNb et le device, ainsi que le bearer S1 entre l’eNb et le SGW. Au niveau du SGW, cela supprime dans la table de contexte le numéro d’identifiant TEID du flux et l’adresse IP du eNb mais les autres informations sont conservées (QoS, clé de sécurité,…). Le MME conserve les informations de la connexion S1-AP et du bearer, place le device dans l’état ECM-Idle et répond à l’eNB de la libération du bearer par le message UE Context Suspend response. Le eNB conserve le contexte mais transmet à l’UE le message « RRC Connection Suspend ». Le device conserve les informations AS (clé de sécurité, information sur le flux de trafic) et se met en état ECM-Idle et RRC-Idle
  • Procédude RRC Resume permet de ré-activer les états qui ont été sauvegardés au niveau du device, de l’eNb et du MME. Dans un premier temps, le device récupère les informations de la couche AS et contacte l’eNB. Ce dernier accomplit une vérification de la sécurité pour ré-établir le bearer radio. L’eNB informe le MME par le message « UE Context Resume Request » de la ré-activation du bearer radio. Le MME récupère le profil du S1-AP et place le device dans l’état ECM-Connected. Il retourne vers l’eNb une confirmation « UE REsume Context Response » contenant l’adresse IP du SGW et le MME envoie l’adresse du eNb et le TEID du eNB (informations S1-AP conservées) vers le SGW.

Figure 6 : Messages RRC reprendre ou suspendre un contexte

 

Figure 7 : Call Flow

Pendant l’état RRC-Suspend, le device n’a plus de connexion radio. Il peut de plus être en mode eDRX, donc en cas de mobilité il ne détecte pas le changement d’eNB. Lorsque le device exécutera la procédure RRC Resume vers le nouvel eNb, celui-ci va demander à l’ancien eNb de lui transférer les informations AS. L’ancien eNb en profite pour supprimer le contexte (clé de sécurite, …). Le nouveau eNb crée un TEID, informe le MME lequel transfère le nouveau TEID et l’adresse du nouvel eNb vers le SGW.

De plus, cette méthode permet aussi de transférer des données non IP entre le SGW et le PGW

II-3-c) EMM-REGISTERED without PDN connection

Lors de la procédure d’attachement, l’UE informe le MME qu’il peut être dans l’état EMM-REGISTERED without PDN connection par le message “attachwithoutPDN Connectivity”. Classiquement, un smartphone (Human UE) émet dans la requête EMM d’attachement  un message ESM pour définir les caractéristiques du bearer par défaut. Dans le cas qui nous intéresse, le message ESM PDN CONNECTIVITY REQUEST est remplacé par le message ESM DUTY MESSAGE, l’UE reste connecté au réseau (EPS attached) même si toutes les connexions PDN ont été libérées. On se retrouve donc dans le cas 3G ou le contexte de l’UE n’existe pas au niveau des entités du réseau.

Remarque : « EMM-REGISTERED without PDN connection » à la même signification que « EPS attach without PDN connectivity

Lorsque le dispositif s’allume, avant d’émettre sa demande d’attachement, il lit le SIB2 transmis par l’eNb pour savoir vérifier la compatibilité de la cellule. Si le MME ne supporte pas l’état « EMM-REGISTERED without PDN connection » alors l’UE établie un bearer par défaut. Lorsque l’UE souhaitera émettre des données, un bearer EPS par défaut sera mis en place sauf si l’UE indique une méthode de transmission, par exemple SMS seulement, lors de son attachement.

II-3-d) S1-U data transfer and header compression

L’UE qui supporte le User Plane Optimisation EPS doit supporter le S1-U data transfer afin de transmettre les données sur le plan utilisateur.

On suppose maintenant que l’UE et le MME supporte à la fois la fonctionnalité S1-U data transfer et la fonctionnalité Control Plane EPS Optimization pour encapsuler la DATA entre le CN et l’UE dans des messages NAS

Lorsque le MME reçoit une requête de connexion PDN, le MME détermine la quantité de données à transmettre sur le lien UL et DL et décide ainsi si les données doivent être transmises sur le plan de contrôle ou sur le plan utilisateur. Il vérifie également si l’UE peut supporter

 

Figure 8 :  Etablissement du S1-U bearer pendant le transport de données dans le plan de Controle

1 – L’UE transmet/reçoit des données dans le plan de control (Control Plane CIoT EPS Optimisation).

2 –3 L’UE reçoit une réponse pour faire une demande d’établissement de bearer dans le plan utilisateur (User Plane Bearer). Dans ce cas, l’UE envoie un message NAS vers le MME. Le message est encapsulé dans un message RRC-Service Request émis au eNb, et un message S1-AP UL entre le eNb et MME. De manière classique, le message contient les informations suivantes :

  • NAS message
  • TAI+ECGI de la cellule sur laquelle l’UE est en communication
  • S-TMSI
  • CSG ID (si la cellule sur laquelle est connectée le mobile est une cellule CSG)
  • CSG access Mode

4 – Le MME fait le transfert des données transmises sur le plan de signalisation vers le bearer

Dans le prochain article, nous décrirons certaines procédures et protocoles

MTC : Le réseau M2M / IoT sur la 4G – 1ère partie

I – Introduction

Les opérateurs en France proposent aujourd’hui des solutions  de connectivité pour les objets (réseau de l’Internet des Objets qui sont des réseaux longues portées sans fil à basse consommation dénommés LPWAN– LoW Power Wide Area Network) en s’appuyant sur des infrastructures de réseaux bas débit comme LoRa (Long Range pour Orange/Bouygues) ou SIGFOX (SFR). Mais, en 2018 les technologies LTE-M et NB-IoT sont attendues (en France) et viennent compléter les offres LPWAN pour des uses cases nécessitant un plus grand débit et une meilleure réactivité par rapport aux réseaux tels que SIGFOX et LoRA.  En 2020, l’Internet des Objets sur la 5G apportera en plus une très faible latence (nouveaux uses cases sur les communications critiques) et dans l’idéal à très faible pertes de paquets (les opérateurs espèrent se rapprocher de la règle des 3 neufs).Cette infrastructure réseau MTC : MTC (Machine Type Communication ou eMTC) constitue le socle sur lequel va s’adosser l’IoT sur la 4G et la 5G.

Les spécifications du MTC sont décrites dans les releases 3GPP R10, R11 et R12. La 3GPP R.13 introduit la notion de eMTC.  La R14 introduit de nouvelles fonctionnalités dans l’architecture du réseau pour gérer le roaming (SCEF), pour optimiser le transfert de faible quantité de données (Ip ou non IP nommé NIDD).

L’objectif de cet article est de comprendre l’évolution de l’architecture du réseau 4G pour l’Internet des Objets (Cellular IoT). La R.13/R.14  pour le réseau 4G MTC propose des optimisations pour le transport de faible quantité de données. Je ne présenterai pas ici des mécanismes d’optimisation d’énergie (DRX, PSM) qui ont déjà été présentés dans un précédent article (http://blogs.univ-poitiers.fr/f-launay/2016/11/04/paging-et-mecanisme-psmdrx/).

Concernant le DRX, le principe consiste pour l’UE à ne décoder le PDCCH que périodiquement selon un cycle DRX constitué :

  • D’une période d’éveil (entre 1 ms et 200 ms) pendant laquelle l’UE décode le PDCCH et effectue des mesures sur les cellules voisines. L’UE est dans l’état RRC_Connected
  • D’une période de repos (sleep sta te)

On appelle cycle DRX l’enchainement de ces deux périodes, un cycle DRX à une durée qui est comprise entre 2 ms et 640 ms. Si l’UE décode un message lors de la phase d’éveil, il passe de l’état RRC_Idle à l’état RRC_Connected. Dans ce cas, il reste alors en phase d’éveil pendant une période d’inactivité DRX allant de 1 ms à 2.56 secondes.

Concernant l’eDRX, dans l’état RRC_Connected, le cycle est étendu à 10,24 secondes (1024 trames), dans l’état RRC_Idle, le cycle est étendu à 43mn54 secondes pour les terminaux de catégories M1 et à 2h54 mn pour  les terminaux NB-IoT.

Il est possible d’augmenter la durée de l’état dormant du dispositif sur plusieurs jours avec le mécanisme PSM – Power Save Mode. Les deux mécanismes sont résumés sur la figure 1 ci-dessous :*

Figure1 : PSM/DRX

Mais, pour plus d’explication, se référer à l’article : (http://blogs.univ-poitiers.fr/f-launay/2016/11/04/paging-et-mecanisme-psmdrx/)

II – Architecture, protocoles et procédures

II-1) Généralité de l’IoT et du réseau cellulaire 4G

Revenons au concept général du réseau cellulaire 4G. Les réseaux cellulaires ont été conçus pour séparer la couche de signalisation et la couche de transfert de données (payload utile). L’UE (déjà enregistré sur le réseau) contacte le MME afin de préparer le tunnel pour le transfert des données. Cette procédure de rétablissement de bearer (le bearer S5 existe, la procédure consiste à rétablir le bearer radio et le bearer S1) génère un trafic de signalisation. Dans le cas d’un usage humain (Internet, messagerie, vidéo, …) la signalisation engendrée par le rétablissement de bearer est faible par rapport à la quantité de données qui va être transportée par ce bearer.

Dans le cas de l’IoT, la taille du TBS (Transport Bloc Size) de l’UE peut être limitée à 1000 bits sur le lien montant et 680 bits sur le lien descendant (cat NB1/M2 et cat M1). L’objectif de l’évolution du cœur radio, nommée EPS optimization consiste à réduire la signalisation en encapsulant de manière transparente les données dans un message NAS EPS transmis au MME. L’architecture CIoT présentée dans la R.13 a donc pour but d’optimiser le transfert de faibles quantités de données entre l’application IoT et le dispositif IoT même si le dispositif IoT ne dispose pas de pile protocolaire IP (stack IP non fourni dans le end-device). On parle alors de transmission NIDD (Non IP Data Delivery) que le réseau CIoT doit savoir gérer (TS 23.682).

II-2) Architecture du réseau Cellulaire 4G – IoT

L’architecture du cœur réseau 4G pour l’IoT, présenté sur la figure 2, intègre une entité supplémentaire nommée SCEF – Service Capability Exposure Function

Le SCEF est une entité destinée à sécuriser le réseau de l’opérateur vis à vis d’une requête extérieure (API). Les fonctions de bases sont :

  • Double authentification avec le device
  • Correspondance entre les identités privées (IMSI/IMPI) et une identité pubique
  • Autorisation ou non des services demandées par le serveur d’application (AS) du client
  • Gestion d’ACL
  • Génère des CRA

Figure 2 : Architecture générale

On peut noter en passant l’API qui est l’interface entre le réseau 3GPP et le serveur du client. C’est une nouveauté entre la R.12 et la R.13. Dans la R.12, l’entité SCEF n’existait pas, le client devait reveiller le dispositif via une requête DIAMETER vers l’entité MTC-IWF. L’entité MTC-IWF sera remplacée par le SCEF et le message DIAMETER par une API. Dans la R.12, le serveur client ne pouvait lancer qu’une procédure de reveil de device par SMS (on parle de procédure de trigger).

Revenons sur le principe d’optimisation du cœur réseau. La quantité de données à transmettre pouvant être faible, les données peuvent être acheminées de deux façons différentes :

  1. Via le plan de contrôle (MME) s’il y a peu de données : Control plane
  2. Via le plan de données (SGW/PGW) à travers un tunnel IP : User plane

Pour ce faire, les spécifications 3GPP définissent

  1. deux optimisations définies sous le nom :
  • Control plane CIoT EPS optimisation;
  • User plane CIoT EPS optimisation;

2 – trois nouvelles entités :

2-1) MTC-IWF : MTC Interworking Function (remplacé par le SCEF qui sera décrit dans un autre article

2.2) SCEF – Service Capability Exposure Function

2.3) C-SGN (CIoT Service Gateway Node).

3-Une nouvelle interface pour le transport de données entre le SGW et le MME : S11-U

Le SCEF est une passerelle sécurisée permettant à une tiers player non 3GPP d’être connecté au réseau opérateur par des API. Nous allons nous contenter d’étudier le rôle du  SCEF dans le plan utilisateur. Nous allons considérer que le SCEF se limite à récupérer les données émises par le dispositif lorsque ce dernier ne possède pas de stack IP. Ainsi, lorsque l’objet ne peut pas utiliser la couche IP, les données reçues par le MME seront soit transférées au SGW et PGW (donnée IP ou non IP encapsulé dans un tunnel IP) soit émises du MME vers le SCEF. On appelle cette procédure NIDD Non Ip Data Delivery.

Figure 3 : Architecture du réseau MTC

Le C-SGN représenté sur la figure 3 réunit la fonctionnalité du MME et du SGW sur la même entité. Le C-SGN est défini comme une nouvelle entité pour le CIoT EPS optimization.

II-3) CIoT EPS optimization : Nouvelles Méthodes

Les Releases R.13 et R.14 définissent de nouvelles procédures afin d’optimiser le transfert de faible Data comme c’est le cas pour l’IoT. Il est donc nécessaire dans un premier temps de s’assurer que le device UE est compatible avec ces évolutions. Ainsi, si l’UE supporte les fonctionnalités du réseau optimisé par l’IoT, il en informe le réseau lors de la procédure d’attachement et à chaque TAU (UE supporting CIoT EPS optimizations). Il indique ainsi au réseau quelles fonctionnalités il peut supporter parmi les 4 suivantes :

  • control plane CIoT EPS optimization
  • user plane CIoT EPS optimization
  • EMM-REGISTERED without PDN connection
  • S1-U data transfer and header compression

 

Le Control plane CIoT EPS optimization permet de transporter des donner utilisateurs (IP, non IP ou SMS) sur le plan de contrôle vers le MME sans déclencher l’établissement de RAB (bearer radio pour la data). De la compression d’entête sur les données IP peuvent, de façon optionnelle, être appliquées sur les connexions de type PDN.

Le User plane EPS optimization permet de passer du mode EMM-IDLE mode au mode EMM-CONNECTED sans avoir besoin de déclencher la procédure de Service Request. Si le MME supporte le User Plane EPS Optimization, il doit obligatoirement supporter le S1-U Data Transfer

Si l’UE indique « Attach without PDN connexion » au cours de la procédure d’attachement, alors l’UE n’a pas besoin d’une connexion PDN pendant l’attachement (bearer S5). S’il indique « SMS only », dans ce cas, il n’a pas besoin d’un attachement conjoint sur le réseau 2G

L’UE optimisé pour

le plan de contrôle

(Control Plane CIoT EPS – en rouge sur la figure 4) est obligatoire pour les UE de catégorie LTE-M1 (cat M1) ou NB-IoT (cat M2 ou cat NB1 – le nom est en évolution).

L’UE optimisé dans

le plan utilisateur

(user plane CIoT EPS optimization – en bleu sur la figure 4) est optimisé pour gérer les contextes en mobilité.

Les deux plans supportent les transmissions de données IP ou non IP.
Nous allons décrire dans le prochain article les 4 fonctionnalités citées ci-dessus.

Mécanisme DRX en mode connecté et en mode idle. Extension à l’eDRX et au PSM

Dans l’article précédent, Allocation de ressources et scheduling, nous avons vu que l’eNB transmet dans la zone PDCCH des informations de contrôle DCI vers l’UE, comme par exemple le DCI 1A, informant l’UE de l’emplacement des données sur le PDSCH destinée à l’UE.

La sous-trame est composée d’une paire de slot. Un slot est découpé en RB, chaque RB est composée de 12 porteuses et de 7 symboles. Le PDCCH correspond à un zone de 1 à 3 symboles (la valeur est défini par le PCFICH) du premier time-slot (pour une bande d’au moins 3 MHz) sur toutes les RB de la bande. Le reste porte les données utiles (PDSCH)

Pour prendre connaissance de l’allocation des données, l’UE doit lire le DCI toutes les 1 ms pour ne pas rater l’allocation proposée par l’eNb :

RRC connected

Figure 1 : Lecture du PDCCH en mode connecté et DRX en mode de veille

1 – DRX : La réception Discontinue

Afin de réduire la consommation de puissance dans l’état RRC Connected et RRC Idle, il existe un mécanisme propre au LTE consistant à éteindre le module RF de l’UE pour le rallumer périodiquement afin de monitorer le canal PDCCH. On appelle cycle DRX (cf. figure 2), une période pendant laquelle le module de transmission est au repos (DRX sleep) alternée d’une période d’activité (DRX Active State). C’est au cours de cette période d’activité que l’UE scrute le PDCCH et effectue les mesures sur les cellules voisines.

fig2Figure 2 : Cycle DRX

Les valeurs du cycles DRX varient entre 2 ms et 640 ms. Le cycle est composée d’une période de repos (DRX Sleep) au cours de laquelle la chaîne de réception RF est éteinte et d’une période de scrutation (ON Duration). La valeur de la période d’activité est comprise entre 1 et 200 ms (donc la valeur de repos se calcule facilement). Ces valeurs sont fixées par l’eNb. Pour que l’UE prenne connaissance de ces valeurs, l’eNb transmet dans le SIB2 les informations de configuration du PCCH comprenant les indicateurs suivants :

  • OnDurationTimer indique le nombre de sous-trame pendant laquelle l’UE écoute le PDCCH
  • DRX Inactivity Timer indique la période pendant laquelle l’UE doit rester en état connecté (le mode DRX est inactif donc l’UE est en phase de réception). Ce timer démarre lorsque l’UE détecte, lors de la phase d’écoute du PDCCH, une information DCI le concernant, par exemple une allocation de données DL ou UL à venir. Le DRX Inactivity Timer doit être suffisamment long pour que l’eNb puisse avoir le temps de préparer le séquencement (l’allocation) des données. La valeur du timer varie de 1 ms à 2,56 secondes
  • HARQ RTT Timer : Indique la durée en TTI pendant laquelle l’UE est susceptible d’attendre un HARQ de la part de l’eNb
  • Short DRX Cycle/Long DRX Cycle  est la durée d’un cycle DRX court (période de scrutation pendant la période OnDurationTimer et période de repos). Le compteur OnDurationTimer démarre à chaque cycle DRX.
  • DRX Short Cycle Timer indique la durée en TTI pendant laquelle l’UE suit le cycle DRX court. La durée DRX Short Cycle Timer est un multiple du Short DRX Cycle. L’UE va suivre une phase composée de plusieurs cycles court consécutifs à la fin du Timer d’inactivité DRX. Cela signifie que si l’UE décode un DCI, il est en état d’écoute pendant la durée DRX Inactivity Timer et en fin de cette période, il entre dans un cycle DRX court qui se répète plusieurs fois. Le nombre de cycle court est égal à la fraction DRX Short Cycle Timer / Short DRX Cycle.

Le cycle court est optionnel,et dépend de la configuration du DRX Short Cycle Timer. Si celui-ci n’est pas configuré, l’UE n’exécute que des cycles longs.

fig4Figure 3 : Paramètres DRX

Au cours de l’état RRC-Connected, l’UE va périodiquement scruter les canaux PDCCH et se mettre en état de repos entre deux scrutations (DRX Sleep, DRX On). Sur la figure 4, on suppose qu’en fin de Timer DRX Inactivity Timer, l’UE suit deux cycles court et trois cycles long avant de passer en état déconnecté.

fig6

Figure 4 : Cycle Long/Cycle Court

Exemple d’application de la procédure DRX en mode connecté.

  • L’UE se réveille et pendant la durée du Timer OnDurationTimer décode le PDCCH
  • Si l’UE reçoit une commande DCI sur le canal PDCCH, il décode le bloc reçu et déclenche la temporisation d’inactivité DRX. Le rôle de ce temporisateur est de maintenir l’UE en état d’éveil pour que l’eNb puisse envoyer des allocations de ressources pour le sens descendant (l’eNb peut ainsi ordonnancer les données à transmettre vers l’UE sur plusieurs TTI consécutifs). A chaque allocation d’un DCI sur le PDCCH (de nouvelles données), le Timer redémarre.
  • Si l’UE ne parvient pas à décoder le bloc de données reçu, il démarre le timer HARQ RTT (permettant la retransmission du bloc, la durée pour  le FDD est de 8 ms)
  • A la fin de l’expiration du timer DRX-InactivityTimer, l’UE démarre un ou plusieurs cycles DRX court. Le nombre de cycle court consécutif est compris entre 1 et 16. Le cycle court a une durée DRXShortCycle dont la durée varie de 2ms à 640 ms, par conséquent la durée totale des cycles courts s’étend jusqu’au plus 16*640 ms soit 10.24 s. Cette période s’appelle DRXShortCycleTimer. Durant le cycle court, l’UE réalise deux fonctions :
    • Analyse du canal PDCCH sur la durée OnDurationTimer
    • Si l’UE ne décode aucune information sur le PDCCH, il entre en mode de veille jusqu’à la fin du temporisateur DRXShortCycle
  • A la fin du Timer du cycle court (DRXShortCycleTimer), l’UE bascule dans un cycle long

Les figures 4 et 5 présentent un schéma pour lequel le cycle DRXShortCycleTimer se compose de 2 cycles courts.

fig5Figure 5 : Exemple de cycle DRX

A la fin de la procédure, s’il aucune activité n’est détectée, l’UE passe dans l’état RRC_Idle, le cycle DRX est un cycle plus long. Le module RF est éteint sur une longue période et ne sera activée que pour détecter des éventuels paging. On parle de cycle de Paging DRX.

2 – DRX en mode Idle : Introduction au Paging

Un UE présent sur une cellule du réseau cellulaire est en mode de veille lorsqu’il n’a pas de connexion activée avec la station de base (on dit que le mobile est dans l’état RR Idle si l’UE est campé sur le réseau 2G ou RRC Idle dans le cas ou l’UE est campé sur le réseau 3G ou 4G). Ainsi, si le coeur réseau mobile (2G/3G/4G) souhaite communiquer avec un UE (appel téléphonique en Commutation de Circuit -2G/3G- ou en commutation de paquet via une requête SIP -4G-, un message court, une authentification, un PUSH Data, une notification d’alerte), l’entité du coeur réseau qui gère l’UE émet un message de Paging.

La procédure de Paging est réalisée dans l’un des 4 cas suivants :

  • Informer l’UE d’une terminaison d’appel en commutation de circuit
  • Informer l’UE d’une terminaison de session en commutation de paquet
  • Déclencher l’UE pour faire une lecture d’un SIB
  • Notifier l’UE d’information sur la sureté civile (ETWS Earthquake and Tsunami Warning System)

Si on se place dans le réseau 4G, la notification de Paging (message RRC de paging) est transportée par le canal logique PDCCH. La notification de paging est broadcastée par la cellule avec l’identifiant P-RNTI. Comme l’identifiant P-RNTI est commun à tous les UE (la valeur de l’identifiant est fixe : 0xFFFE ; et le P-RNTI est transmis sur l’espace de recherche commun du canal PDCCH), tous les terminaux vont donc être notifiés d’une procédure de paging. Chaque UE doit alors décoder le canal PDSCH (l’information de paging est contenue sur le PDSCH et se trouve sur les RB indiqués par le PDCCH) pour savoir si le paging le concerne (au message de paging utile est ajouté un code correcteur d’erreur CRC lequel est codé par l’identité S-TMSI du mobile concerné. Le codage est effectué par un OU logique).

En général, la procédure de Paging est initiée par le MME, et par conséquent la procédure s’applique lorsque l’UE est dans l’état EMM-IDLE,  ce qui signifie que l’UE est aussi dans l’état RRC-Idle (se reporter à l’article Etat RRC – EMM). Cependant, la demande de paging peut aussi être initiée par l’eNB dans les deux cas particuliers évoqués ci-dessus :

  • L’eNB génère une procédure de paging en cas de modification des informations SIB (exemple de congestion avec une modification de la classe d’accès).
  • L’eNB génère une procédure de paging en cas d’événement ETWS

Lorsque le paging est initié par l’eNb, l’UE peut être à l’état RRC-Connected.

Quand la procédure de paging est initiée par le MME, l’UE est forcément en état de veille (sinon le MME initierait éventuellement un RAB supplémentaire via un message RRC avec l’eNB sur lequel est connecté l’UE donc pas de paging). Lorsque l’UE est en veille, il est localisé par le MME sur une zone étendue (TAI). Ainsi, tous les eNb concernés (inscrit sur le même TAI que la dernière position de l’UE) autrement dit toutes les cellules définies avec le même TAI (soit entre 100 et 500 cellules) transmettront le message de paging. Sans aucune optimisation, chaque UE doit scruter toutes les 1 ms, l’espace commun du  PDCCH pour prendre connaissance d’un indicateur du message de Paging et décoder le PDSCH pour savoir s’il est à destination du paging.

Lors du décodage du message de paging (PDSCH : message + CRC codé), si le CRC décodé avec l’identité S-TMSI de l’UE est cohérent avec le message de paging, alors l’UE est destinataire du message et va prendre connaissance de la raison de la demande de connexion (Paging Cause) afin d’initialiser la procédure appropriée avec le cœur réseau. L’UE passe alors de l’état RRC_Idle à l’état RRC_connected (avec le DRX correspondant au cycle expliqué dans le paragraphe 1)

3 – La procédure de Paging

La durée du cycle Paging DRX est soit définie par la cellule (SIB2 dans le paramètre PCCH : defaultPagingCycle nommé Tc dans le tableau ci-dessous) soit imposée par le MME si ce dernier transmet un message NAS (UE specific DRX cycle) à l’UE pour lui indiquer la durée spécifique du cycle DRX. La durée maximum du cycle est de 2.56s, valeur maximum du paramètre Long DRX Cycle (figure 2), les valeurs du tableau s’exprime en durée trame (10 ms).

Tableau paramètres DRX

Tableau 1 : Paramètres DRX

Ainsi, T=T_UE ou T_C en fonction du choix du cycle DRX. Si Tc=128, alors le cycle DRX est configurée pour 1.28 secondes (1 trame=10 ms).

nB est un paramètre qui définit le nombre de PO (Paging Occasion) par cycle DRX autrement dit le nombre de fois que l’UE écoute le canal PDCCH pour détecter un Paging.

1er cas : nB<T

Si nB=T/32 avec T=128  alors il y aura 4 PO durant le cycle de 1,28s soit un PO toute les T/32 trames. La trame qui va porter le message de Paging n’est évidemment pas aléatoire. Pour synchroniser l’UE et l’eNB à l’émission/réception d’un message de Paging, le MME transmet à l’eNb le paramètre UE_ID (UE Identity Index Value) via le protocole S1_AP, sachant que UE_ID=IMSI mod 1024. L’UE calcule de son coté la valeur UE_ID, le paging pour un UE est donc sur une trame dont le numéro de trame (SFN) dépend de l’IMSI.

Numéro des trames SFN portant un Paging = 32*(UE_ID mod 32). Le compteur est remis à 0 à chaque cycle donc :

PFN =SFN modulo 128

Le calcul est différent si nB>T.

2ème cas : nB>T

Si nB=2T, alors on aura 256 PO par cycle DRX (2 PO par trame), 1 PO toutes les 5 ms.

Numéro des trames SFN portant un Paging = 256*(UE_ID mod 128). Le compteur est remis à 0 à chaque cycle donc :

PFN =SFN modulo 128

Formule Générale : On pose N=min(T,nB) :

  • SFN = (T div N)*(UE_ID mod N)
  • PFN = SFN mod N

Il ne reste plus qu’à déterminer la sous trame portant le Paging (PO). On pose Ns=max(1,nB/T)

i_s = floor(UE_ID/N) mod Ns

Application :

1er cas : nB<T :  Ns=1, donc is prend pour valeur 0 ou 1

2ème cas : nB<T  Ns=1, 2 ou 4 donc _s prend pour valeur 0,1 ou 2 ou 3.

La sous trame est définie par le tableau ci-dessous :

Sous trame portant le PO

Tableau 2 : Sous trame portant le PO

4 – Call Flow et étude simplifiée

Le call Flow présenté en figure 6 porte plusieurs informations que nous allons détailler, comme par exemple le mécanisme DRX (Discontinuous Receive cycle) sur lequel se synchronise le cycle de PO (Paging Occasion), le rôle du Timer T3413 et les messages.

Call Flow PagingFigure 6 : Call Flow Paging détectée par l’UE et spécifique à l’UE

II-a) Etat du téléphone

L’état du téléphone ne doit pas vous échapper, vous pouvez revenir sur l’article ETATS RRC – ECM EMM pour plus de détail.

Dans le cas du call flow, l’UE est dans l’état ECM Idle et RRC Idle, cela signifie qu’il n’a pas de connexion radio avec l’eNb.

Le téléphone est enregistré sur le réseau, il existe donc un contexte au niveau du MME, un contexte au niveau du PGW et le HSS connait l’identité du MME sur lequel l’UE est enregistré. En cas de session DATA en provenance du réseau (VoLTE  par exemple), le PGW sera en mesure de router les paquets vers le SGW et ce dernier informera le MME de paquets en attente.

II-b) Première lecture du call flow

Le MME va générer le message S1AP Paging et va ensuite démarrer le timer T3413. Ce Timer a pour rôle de limiter la période pendant laquelle le MME considère le message S1AP valide. Il s’agit donc du temps de réponse maximum autorisé pour que l’UE réponde au message S1AP.

Le message S1AP est transmis à une liste de eNB. Cette liste est connue par le MME car ce dernier maintient le contexte de l’UE (celui est attaché car l’UE est en état MME registered, les eNb concernés sont définis par le TAI), c’est donc le MME qui connait la position approximative de l’UE (Tracking Area ou TA List). Chaque eNb qui reçoit le message S1AP décode l’identité de l’UE (S-TMSI) et transmet la requête de paging sur l’accès radio.

L’UE destinataire recevant et décodant le message de paging répond à la requête en faisant une demande d’accès radio (procédure d’accès aléatoire : Random Access Procedure). Une fois l’accès radio mise en oeuvre, l’UE est en état connecté. Le Timer DRXInactivityTimer est déclenché, l’UE est en écoute jusqu’à la fin du Timer ou il se mettra en cycle DRX court puis long si rien ne se passe.

5) eDRX et Mode PSM – Power Saving Mode – Extension pour le MTC (IoT)

eDRX (R.13)

Dans le cas de l’IoT, la durée en mode de veille du cycle DRX est allongée et peut s’étendre jusqu’à 44 mn (Trigger eDRX Long Cycle) en prenant comme référence non plus la durée d’une trame, mais d’une hyper-trame H-SFN. L’Hyper-trame a une durée de 1024 trames soit 10.24 secondes. Il est donc nécessaire que l’eNb et le MME se synchronise sur le H-SFN.

A titre d’exemple, sur la figure 7 on représente le mode discontinue en mode de veille.

fig10Figure 7 :  Extension du timer -eDRX

Le eDRX s’applique pour l’UE dans l’état RRC-Idle et RRC-Connected. La figure 7 présente un exemple dans l’état RRC-Idle.

Les valeurs du trigger TeDRX (mode de repos) et TPTW sont indiquées au device lors de la procédure d’attachement ou de RAU sous le nom respectif T331 et T332 (Information Element lors du message RRC), mais la valeur eDRX peut aussi être broadcastée par l’eNb. L’UE prendra alors la plus petite valeur des deux.

PSM (R.12)

Le mode PSM est un mode pour lequel le device s’éteint sans faire la demande de détachement. Pour le mode PSM, le device utilise deux valeurs de triggers (T3324 et T3412) lesquelles lui ont été fournies lors de la procédure d’attachement ou de mise à jour de sa localisation (TAU). La première valeur de timer, le T3324 indique le temps pendant lequel l’UE reste en mode de veille suite à la procédure d’attachement (c’est la durée du mode DRX et est nommée Active Timer) et le deuxième Trigger est le temps pendant lequel le device est endormi avant une mise à jour périodique de sa localisation. Ainsi, la valeur du trigger T3412 correspond toujurs à la durée de la demande de Mise à Jour de localisation Périodique (periodic TAU). Durant cette période, le device reste attaché au réseau mais est non joignable : Il ne lit aucune signalisation, et par conséquent, le MME ne doit envoyer aucun message. Le MME enregistre l’état du device (enregistré et non localisé). La durée maximum du trigger T3412 pour le mode PSM est de 12,1 jours, mais le device peut à tout moment interrompre ce mode en émettant une requête de TAU (Mobile Originated Transaction).

Mode PSM

Figure 8 : Mode PSM

Figure 9  : Call Flow

Différence entre PSM et eDRX

Concernant les cycles DRX, l’UE et l’eNb sont synchronisés, autrement dit l’UE connait les instants pendant lesquels l’UE est en écoute (DRX awake). Ainsi, si l’eNb doit adresser un message au mobile (allocation par exemple) sur le PDCCH, il devra attendre la période de réveil pour séquencer l’UE, ce qui introduit un peu de latence. Les transmissions Uplink ne sont pas affectées par le DRX puisque l’UE peut à tout moment activé le module RF pour transmettre une demande d’allocation (Scheduling Request).

 

Les cycles DRX sont émis par le SIB 2, mais la couche MAC de l’eNb peut aussi contrôler les paramètres DRX de l’UE en transmettant des commandes MAC CE DRX.

Commandes MAC CE : MAC Contrôle Element est une structure MAC du LTE qui porte des informations de contrôle spécifiques entre l’eNb et l’UE comme le Timing Advanced, le PHR, les commandes DRX, …

 

Dans le mode PSM, le device fait une demande de TAU périodiquement. Lorsque le mobile est à l’état PSM, toutes ses fonctions non critiques sont désactivées, ce qui permet de consommer encore moins d’energie que l’UE en mode idle, et ceci tant que le Timer n’a pas expiré. En contrepartie l’UE est injoignable pendant toute cette phase. Le PSM est donc réservé uniquement aux UE en commutation de paquet qui n’ont pas à être déclenché.  La durée maximum du Timer T3412 est de 12.1 jours.

Dans le cas eDRX, le device scrute périodiquement le PDCCH sur une courte durée. Par conséquent, les devices susceptibles de recevoir des notifications du réseau (trigger) mais qui sont tolérants au délai seront programmé en mode eDRX devices qui fonctionnent plutôt en transmission de données (originated device) seront plutôt programmés en mode PSM.

fig12
Figure 9: Comparaison PSM/DRX

Pour aller plus loin : https://www.youtube.com/watch?v=wY7XHrbm1oQ

Cet article constitue aussi deux mécanismes de gestion de batterie sur lesquels nous reviendront dans un futur article traitant du MTC (Machine Type Communication).

Remerciement :

Merci à André PEREZ d’avoir contribué à la rédaction de l’article. L’article s’appuie sur le livre VoLTE et ViLTE

Merci à Louis Gibault d’avoir relu l’article et annoté des remarques

Allocation de ressources et scheduling

Dans cet article nous allons voir la signalisation émise par l’eNb pour informer l’UE de la taille du bloc de transport (TBS) alloué à l’UE pour transmettre ses données utiles (payload). La taille dépend de la qualité du lien radio (renseigné par l’UE via le CQI) et des ressources allouées par l’eNb à l’UE (scheduling).

Nous ne nous intéresserons pas ici à la procédure de scheduling mais uniquement à l’échange de signalisation pour informer l’UE de la taille et des ressources allouées pour transmettre ses données.

Allocation de ressources

La trame physique du LTE est partagée entre tous les utilisateurs, et nécessite la transmission de signalisation 4G sur des ressources blocs commun aux UES allouées au canal physique nommé  PDCCH* et l’échange de données sur des RB specifiques avec un format de modulation et de codage imposée par l’eNb et qui dépend des conditions radios.

Le mapping physique LTE (cf http://blogs.univ-poitiers.fr/f-launay/2013/08/27/rsrp-et-rsrq/) rappelle la répartition des ressources en temps et en fréquence entre utilisateurs et la disposition de RB spécifique pour la gestion des ressources.

L’UE doit donc attendre l’ordre spécifiant :

  • Le Time Slot sur lequel il va recevoir/émettre des données
  • Le RB (les blocs de fréquence) sur lequel il va recevoir/émettre des données
  • Le schéma de codage et de modulation (MCS) pour démoduler/moduler les données
  • La puissance d’émission

*Le canal PDCCH est le canal physique de contrôle dans le sens descendant qui porte les informations permettant à  l’UE de connaître les ressources qui lui sont allouées dans cette sous-trame (position des RB, format MCS) et des informations de contrôle permettant à l’UE de connaître les ressources et le schéma de modulation qu’il utilisera 4 TTI plus tard pour émettre ses données vers l’eNb.

Alloc_ressource_fig1

Figure 1 : Schéma général d’un échange d’information de contrôle

L’eNb doit donc transmettre de nombreuses informations vers chaque UE par un message nommé DCI  (Downlink Control Information). Le DCI est transmis soit à un groupe d’UE, soit spécifiquement à un UE afin de lui porter à connaissance l’attribution des ressources pour la transmission de ses données (payload). Dans ce cas, l’information portée par le PDCCH (et transmis en broadcast) est destiné à un seul UE. Pour savoir si le PDCCH lui est destiné, l’UE doit décoder le CRC avec ses identifiants RNTI (P-RNTI, C-RNTI, SPS-RNTI, RA-RNTI).  Toutefois, l’eNb doit aussi transmettre des informations systèmes destinées à plusieurs UE simultanément donnant ainsi des règles d’allocation suivant le mode de transmission de l’UE (la classe du terminal permet de définir ses capacités notamment sur la diversité de transmission, de réception et le MIMO). Dans ce cas, le CRC du PDCCH est codé avec la valeur du SI-RNTI.

Puisqu’un mobile ne peut deviner si un PDCCH lui est transmis, chaque UE qui n’est pas dans l’état discontinue (DRX) décode sur la sous-trame correspondante l’ensemble des CRC en fonction de ses identifiants RNTI. La taille allouée pour le PDCCH est néanmoins connue par le mobile sur un espace de recherche dit espace de recherche commun et son emplacement est toujours situé sur les premiers symboles OFDM. Quant à sa taille, elle est formée par l’agrégation de 1,2, 4 à 8 CCE sur lequel l’eNb transmettra respectivement 8 PDCCH, ou 4 ou 2 ou 1 (selon le format du PDCCH c’est  dire à la quantité d’information à transmettre). Sur l’espace de recherche commun, l’eNb transmet des informations système (SI-RNTI).

Lorsque le PDCCH est spécifique à un UE, on parle alors d’espace de recherche spécifique. L’emplacement de ce dernier est défini en fonction du RNTI de l’UE et du numéro de trame. Lorsque l’UE a reconnu un PDCCH spécifique, il répond en retour sur le PUCCH ou PUSCH. Il informe notamment  l’eNb de la qualité du lien radio via l’indication de la qualité du canal nommé CQI, ce qui permet à l’eNb d’adapter les paramètres de transmission à savoir :

  • L’efficacité du code correcteur.
  • Le type de modulation (QPSK, 16 QAM, 64 QAM).
  • Dans le cas du MIMO, les indicateurs RI et PMI.

Pour satisfaire aux différents besoins, il existe plusieurs formats DCI spécifiant le type d’information à transmettre (de taille par conséquent différent, ce qui revient à une allocation en terme de CCE différent) et décrites dans la norme 3GPP R8/R10 :

  • DCI Format 0 est utilisé pour informer l’UE de l’allocation des ressources sur la voie montante
  • DCI Format 1 est utilisé pour informer l’UE de l’allocation des ressources de la voie descendante lorsqu’il y a une diversité de transmission (MISO ou MIMO rank 1)
  • DCI format 2 est utilisé pour informer l’UE de l’allocation des ressources de la voie descendante pour le MIMO.
  • DCI format 3 est utilisé pour la transmission des commandes de contrôle de puissance (TPC commande) pour le canal de la voie montante.
  • DCI format 4 est utilisé pour informer l’UE de l’allocation des ressources sur la voie montante dans le cas MIMO

 

Pour un format donnée, les informations transmises dépendent du type de RNTI (P-RNTI, C-RNTI, RA-RNTI, …) et du mode de transmission. Ainsi , en se basant sur le mode de transmission,  la norme précise des sous-formats :

Alloc_ressource_tab1Tableau 1 : Format DCI et informations transmises

Nous avons précédemment dit que le PDCCH était décodé selon l’identifiant RNTI. Pour faire une synthèse, le tableau 2 reprend selon l’état du mobile (connecté, en veille)la liste les formats DCI correspondant en fonction du type d’identifiant :

Alloc_ressource_tab2Tableau 2 : Correspondances entre le type RNTI et les formats DCI compatibles

Entre la Release 8 et la Release 10, le 4ème format est apparu. Ce dernier est utilisé pour informer l’UE de l’allocation des ressources sur la voie montante en utilisant le multiplexage spatial, ce qui nécessite donc de transmettre davantage d’informations comparé au DCI format 0.

Alloc_ressource_tab3

Tableau 3 : Les différents formats selon la release

Mais, ce n’est pas la seule différence, car en effet, la R10 traite du LTE-Advanced laquelle autorise l’agrégation de plusieurs bandes de fréquences et par conséquent chaque format du R10 comporte un champ supplémentaire précisant la porteuse concernée.

Alloc_ressource_tab4

Tableau 4  : Les différents champs concernant les informations portées par le DCI selon la release pour le format 0

Alloc_ressource_tab5

Tableau 5  : Les différents champs concernant les informations portées par le DCI selon la release pour le format 2

 

 

Exemple

Alloc_ressource_fig2

Figure 2 : Exemple issu du site http://niviuk.free.fr/lte_dci_decoder.html

Le tableau donne des informations concernant la valeur hexadécimales du DCI. En remplaçant 2584A800 par 2585A800, la modulation est une 64QAM

(Cf Specification ETSI 3GPP TS 36.213 R8, Table 7.1.7.2, http://www.qtc.jp/3GPP/Specs/36213-920.pdf, la table TBS donne la taille 9144 à la ligne 22, colonne 18)

Alloc_ressource_fig3

Figure 3 : Exemple issu du site http://niviuk.free.fr/lte_dci_decoder.html

 

Comme dernier exemple, je vous propose de découvrir les informations contenues dans le PDCCH spécifiant le niveau de puissance

Alloc_ressource_fig4

 

Ref : http://blogs.univ-poitiers.fr/f-launay/tag/pdcch/ pour calculer le nombre maximum d’UE pouvant simultanément échanger des données avec l’antenne et le nombre maximum d’UE pour la VoLTE

http://www.sharetechnote.com/html/DCI.html

http://nitintayal-lte-tutorials.blogspot.fr/2013/05/all-about-pdcch-and-cce-allocation.html

 

 

Quand le eNb sature t’il?

Les équipementiers qui vendent l’infrastructure 4G limitent les capacités des entités en soumettant leur solution à des licences. D’un autre coté, les licences garantissent aussi le traitement d’un nombre de sessions maximum en temps réel. A titre d’exemple, les eNB ont une capacité (en terme de licence) de 512 bearers, c’est à dire que l’eNb peut ouvrir 512 connexions (bearer) garantissant le maintien de 512 sessions avec les utilisateurs en mode actif.

A ce jour le nombre de bearers que l’eNB met en oeuvre sur certains site de Nantes et aux heures de pointe atteint ce chiffre. On parle alors de saturation de l’eNb, mais nous verrons dans cet article que le déploiement de la VoLTE peut aggraver cette limitation.

Nous allons calculer le nombre d’UE pouvant avoir des accès au cours d’un TTI (Transmission Time Interval correspond à une unité de temps de 1ms pour le LTE, c’est la plus petite unité de temps pendant laquelle un user peut recevoir ou émettre des données). Sous des hypothèses simplificatrices, nous allons calculer le nombre maximum d’utilisateur pouvant, au cours d’un TTI, transmettre ou recevoir des données. Mais, le nombre d’utilisateurs actifs peut être plus élevé puisque un user peut nécessiter des ressources à un TTI mais pas au(x) TTI(s) suivant(s).

Combien d’utilisateurs maximum sont actifs par TTI sur l’eNB ?

Nous allons nous intéresser dans cet article au nombre maximum d’UE pour lesquelles l’eNb alloue des données sur un TTI. Nous aborderons dans un premier la méthode de répartition des canaux de contrôles sur la bande LTE afin de calculer le nombre d’allocation possible.

1 – Structure de la trame.

1-a) PDCCH

Les données transmises entre l’eNb et l’UE sont séquencées de manière dynamique. L’UE est informé de l’allocation de PRB en réception et de l’attribution de PRB en émission via les informations portées par le canal PDCCH. Outre l’allocation de ressource, le PDCCH informe l’UE du type de modulation et du codage utilisés (MSC) et en cas de réception multiples (MIMO), le PDCCH transporte le type de précodage (PMI).

Ainsi, le PDCCH transporte des informations de contrôle :

  • sur la voie descendante permettant d’informer l’UE de l’existence de données à recevoir dans la trame courante et des caractéristiques de modulation
  • des informations sur les ressources que l’UE utilisera sur la voie montante pour la sous-trame émise par l’UE 4 TTI plus tard.

Il est à noter que plusieurs PDCCH peuvent être transmis dans une sous-trame, soit pour transmettre des données respectivement à plusieurs UE, soit pour un seul UE. En effet, plusieurs PDCCH peuvent être transmis à un seul UE dans le cas ou le nombre d’information est conséquent, comme par exemple pour informer l’UE de l’allocation dynamique et du schéma de codage sur la voie descendante et montante, ainsi que la commande de contrôle de puissance.

Afin de spécifier le type d’information transporté par le PDCCH, l’UE décode l’information portée par le DCI (Downlink Control Information) qui stipule le type d’information transmise par le PDCCH parmi  10 formats possibles. Les 10 formats sont récapitulés dans le tableau ci-dessous :

DCI

Les formats DCI 0, DCI 3 et DCI 3A portent des informations destinées à l’UE pour la transmission sur la voie montante. En effet le format DCI 0 alloue des PRB pour l’émission du mobile vers l’eNB, et les formats DCI3/DCI 3A portent de contrôle de puissance pour la voie montante.

Le PDCCH est transmis sur un CCE (control channel elements) ou sur plusieurs CCE (on parle d’aggrégation de CCE dont les valeurs sont 2, 4 ou 8 CCE). Un CCE est composé de 9 REG – Ressource Element Group, un REG étant constitué de 4 RE. Le PDCCH est modulé en QPSK.

PDCCH_format

1-b) PCFICH

De plus, le PDCCH est obligatoirement transmis sur les premiers symboles OFDM de chaque sous-trame (De 1 à 3 symboles voir 4 symboles au maximum si le nombre de RB est faible, ce qui correspond au cas où la bande est de 1.4 MHZ). Pour savoir sur combien de symboles est transmis le PDCCH, l’eNb transmet une information complémentaire nommée CFI (Control Format Indicator) dans le canal de control PCFICH. Le PCFICH est transmis quant à lui sur le premier symbole OFDM de chaque sous trame, réparti sur toute la bande pour profiter de la diversité en fréquence. Les 4 valeurs possibles de CFI sont encodées dans un mot de 32 bits avec une forte redondance pour assurer la détection/correction au niveau de l’UE.

PCFICH_Mot

De surcroît, le canal PCFICH est modulé en QPSK pour assurer une meilleure immunité au bruit. Le CFI étant codé sur 32 bits, 16 RE sont donc nécessaires, soit 4 REG. La position des REGs est définie en fonction de l’identité de la cellule (Cell Id), laquelle est une valeur comprise entre 1 et 504.

PCFICH_REG

1-c) PHICH

Outre le PCFICH, l’eNb transmet des informations d’acquittement (ACK/NACK) sur les trames émises par l’UE. Il s’agit du canal PHICH (HARQ), dans lequel 1 bit d’information (ACK/NACK) est répété 3 fois et étalé par un code de Walsh Hadamard (code orthogonal) et modulé en BPSK.

Ainsi, un ACK a pour valeur 111 et un NACK a pour valeur 000. Le PHICH est modulé en BPSK (signal complexe situé sur le cercle trigonométrique à +pi/4 ou 5*pi/4), il faut donc 3 symboles. Le signal modulé est ensuite étalé par un code d’étalement de facteur SF=4, permettant d’obtenir 32 combinaisons complexes et d’extraire 8 codes orthogonaux (4 codes et l’équivalent déphasé de pi/2). Grace aux 8 codes orthogonaux, il est possible de transmettre 8 PHICH simultanément.

Il est donc nécessaire de réserver 12 RE pour transmettre jusqu’à au plus 8 PHICH. On parle de groupe de PHICH, codé par des codes orthogonaux.

PHICH_Code_Orthogonaux

2 – Calcul du nombre de PDCCH.

Nous allons maintenant calculer le nombre de ressources PDCCH, permettant ainsi d’obtenir le nombre d’utilisateurs simultanés sur la bande totale de l’eNB.

Il s’agit donc de calculer le nombre de ressource disponible (RE) sur les premiers symboles (1 à 3) pouvant porter le canal PDCCH. L’objectif est donc de calculer le nombre de RE disponible sur tout la bande et retrancher les canaux PFCICH, PHICH et les signaux de références (RS).

Les signaux de références (RS) sont transmis par l’eNB à chaque RB et tous les 6 RE du premier symbole si l’eNb n’a qu’une seule antenne. Si l’eNb possède au moins deux antennes, les RS sont également transmis sur 6 RE du premier symbole pour la 2ème antenne. Le RS est nécessaire afin de mesurer la distorsion apportée par le canal de propagation et de ce fait, dans le cas ou l’eNb possède deux antennes, l’eNb ne transmet aucun signal sur le RE correspondant à la position du RS de l’autre antenne.

RS_antennes

On va donc considérer qu’il y a 2 ou 4 RS par PRB.

Nous pouvons maintenant calculer le nombre de ressources PDCCH.

Rappelons que selon la bande allouée au LTE qui s’étend de 1.4 MHz  minimum à 20 MHz, le nombre de PRB noté N_PRB est le suivant :

1,4 MHz =>  6 PRBs

3  MHz   =>  15 PRBs

5  MHz   =>  25 PRBs

10  MHz  => 50 PRBs

15  MHz  => 75 PRBs

20  MHz  => 100 PRBs

Chaque PRB est composé de 12 sous porteuses, le PDCCH est transporté sur N_pcfich symboles (canal PCFICH). Le nombre total de RE sur N_pcfich symbole est donc de :

12*N_PRB*N_pcfic

Nous allons maintenant calculer le nombre de RE à soustraire :

  • Info_PCFICH=16
  • Info HARQ. On sait qu’il est possible de transmettre un groupe de 8 ACK/NACK dans un seul PCICH. Par conséquent, sur N_PRB, le nombre de groupe de PCFICH sera de E[N_PRB/8], avec E la partie entière supérieure. Enfin, le groupe de PCICH nécessite 12 RE, donc le nombre de RE sera de 12* E[N_PRB/8].
  • RS pour une antenne : 2*N_PRB
  • RS pour deux antennes ou plus : 4*N_PRB

2 – Application et cas de la VoLTE.

2-a) Calcul sur 5 MHz, 10 MHz et 20 MHz

Nous allons faire une application pratique sur 10 MHz, puis à partir des tableaux, je fournirai les résultats sur 5 MHz et 20 MHz

10 MHz =>50  PRB soit 50 *12 RE =600 dans le premier symbole. Si le nombre de symbole utilisé par le PDCCH monte à 3, alors il y a aura 1800 RE pouvant transporter les PDCCH

On retire :

  • 16 RE pour le PCFICH
  • 12* E[50/8] = 12*7=84 RE pour le PCICH
  • 100 RE pour les RS si une antenne et 200 RE pour deux antennes

Soit un total de 200 RE ou 300 RE pour deux antennes.

Pour rappel,  le PDCCH nécessite au moins un CCE (mais peut nécessiter 2 CCE, 4CCE ou 8CCE). Un CCE est composé de 36 RE et le PDCCH est positionné sur N_pcfich symboles (canal PCFICH). Pour finir, étudions les 3 cas possibles

  1. N_pcfich=1 => 600 RE, moins 100 RE pour une antenne et 200 pour 2 antennes. Il reste donc 400 ou 300 RE. Dans le cas ou il y a 2 antennes, 300/36=8.33 soit 8 PDCCH donc 8 utilisateurs simultanés
  2. N_pcfich=2 => 1200 RE, moins 100 RE pour une antenne et 200 pour 2 antennes. Il reste donc 1000 ou 900 RE. Dans le cas ou il y a 2 antennes, 900/36=25 soit 25 utilisateurs simultanés
  3. N_pcfich=3 => 1800 RE, moins 100 RE pour une antenne et 200 pour 2 antennes. Il reste donc 1600 ou 1500 RE. Dans le cas ou il y a 2 antennes, 1500/36=41.66 soit 41 utilisateurs simultanés

Voilà une synthèse pour 3 bandes LTE différentes et deux antennes :

Nbre_PDCCH_5MHZ

Nbre_PDCCH_10MHZ

Nbre_PDCCH_20MHZ

NB : L’UE détecte le PDCCH en fonction de son identifiant RNTI – Radio Network Temporary Identifier :

  • P-RNTI si le mobile est en veille. Il écoute le canal PDCCH pour être informé d’un Paging
  • C-RNTI en mode connecté ou SPS-C-RNTI quand il reçoit des informations périodiquement (par exemple de la VoIP reçue toutes les 20 ms)

Le RNTI est codé sur 16 bits et réalise un ET logique avec le code CRC du canal PDCCH.

2-b) Impact de la VoLTE

Les eNb sont limités à 512 bearers actifs, quel sera l’impact de la VoLTE?

Nous supposons une bande de 10 MHz, si le PDCCH est codé sur 3 symboles (hypothèse de 2 antennes), le nombre maximum d’utilisateur sur une bande de 10 MHz est donc de 41 utilisateurs par TTI.

Or, la VoLTE nécessite la transmission d’information que tous les 20 TTI, donc en supposant que des utilisateurs en VoLTE, le nombre de sessions actives est de :

41 * 20 = 820 utilisateurs.

Par contre dans le cas ou la bande n’est que de 5 MHz, le nombre d’utilisateurs actifs sera limité à 400, en dessous du seuil des 512 licences.

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.

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

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.

IMSI-cut

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). Mail 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 inscrit et le M-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é 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 profile 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 MMEI, on obtient le GUTI.

GUTTI

 

Figure 2 : GUTI – Decomposition 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.

GUTI

 

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

MMEID

 

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