Interfonctionnement du LTE et du WiFi

Cet article est une extension de l’article de l’article du 8 octobre : LTE et WiFi : Les attentes de la R.13 et R.14

L’architecture EPC (Evolvec Packet Core) est le cœur réseau tout IP définie dans la release R.8 pour le réseau de mobiles 4G. Le réseau EPC supporte l’interconnexion avec les réseaux  de mobiles 2G et 3G ainsi que le réseau WiFi. Il devient ainsi le point d’ancrage pour la mobilité des utilisateurs sur les réseaux d’accès 3GPP et les réseaux d’accès non 3GPP. Il est également le point d’ancrage pour la politique de QoS, de taxation et de services de facturation. Par contre, les fonctionnalités décrites dans la release R.8 n’autorise pas le mobile UE d’être sur le réseau 3GPP et non 3GPP simultanément. Par contre, dans la release R.10 plusieurs mécanismes sont proposés pour autoriser le mobile UE accéder aux deux réseaux d’accès LTE et WLAN simultanément soit :

  • en établissement une ou plusieurs connexions portées par un support radio (bearer) sur l’interface LTE et un accès radio sur le WLAN. Il s’agit du mécanisme MAPCON Multi-access PDN Connectivity) ;
  • en établissant une connexion PDN entre l’UE et le PGW, avec un mécanisme permettant de router le flux data vers l’UE (qui conserve toujours la même adresse IP) par routage vers le réseau d’accès LTE ou le réseau d’accès WiFi. Il s’agit du mécanisme IFOM (IP Flow Mobility) qui nécessite de la part du mobile UE et de l’entité PGW (nommé HA Home Agent) de supporter le protocole DSIMPv6 (Dual Stack Mobile IPv6) afin de pouvoir établir un routage sur le réseau IpV4 ou IPv6.

L’architecture du réseau 4G est rappelée sur la figure 1 :

Figure 1 : Architecture du réseau 4G

Le routage des flux entre le réseau WiFi et le réseau opérateur est conditionné au type de flux à transmettre. Afin de satisfaire la qualité d’expérience de l’utilisateur, les flux exigeant une QoS (Qualité de service) particulière comme un débit garanti, une priorité seront pris en charge par le réseau 4G alors que les autre flux seront transportés sur le réseau Best Effort via l’accès WiFi.

Le réseau opérateur doit donc analyser les types de flux et définir l’accès adéquat. Cette fonction est supportée par l’entité ANDSF (Access Network Discovery and Selection Function). Ce dernier doit donc connaitre le profil de l’utilisateur et doit pouvoir joindre l’entité  PCRF pour connaître la QoS à appliquer. A chaque demande de l’utilisateur, l’ANDSF :

  • Transmet les politiques sur le routage de flux en fonction de la capacité du mobile UE :
    • politique de mobilité ISMP (Inter-system Mobility Policy) permet de sélectionner le type de réseau 3GPP ou non 3GPP dans le cas où le mobile UE ne supporte pas une connexion simultanée sur les deux réseaux ;
    • politique de routage ISRP (Inter-System Routing Policy) permet de mettre en œuvre les mécanismes IFOM ou MAPCON
  • Détecte les réseaux d’accès pouvant apporter une connectivité radio avec le mobile UE et gère les listes des accès réseaux disponibles à proximité de l’UE (localisation et profil du mobile UE).

Les rôles de la politique de mobilité ISMP (release R.8) sont :

  • Définir les règles de priorité des réseaux d’accès (PLMN, TAC, RAC, EUTRAN, UTRAN, GERAN, SSID, …)
  • Définir le choix au réseau d’accès 3GPP/WiFi
  • Mettre à jour des règles de politiques à la demande du mobile UE ou à l’initiative du réseau (PUSH/PULL)

La politique de mobilité ISMP permet de choisir un type de réseau d’accès. Ainsi, dans ce cas si l’opérateur choisit de délester un utilisateur UE vers le WiFi, c’est tout le trafic IP de cet utilisateur UE qui sera délesté vers le réseau WiFi.

Pour avoir une granularité sur les types de flux à délester, il est nécessaire d’analyser la demande de connexion PDN.

Les rôles de la politique de routage ISRP (release R.10) sont :

  • Autoriser l’UE à accéder à deux réseaux simultanément en établissant plusieurs PDN
  • Sélectionner le réseau pour délester le trafic

L’ISRP s’appuie sur l’identité du nom de point d’accès APN pour définir la règle de routage (MAPCON), ou sur le type de flux grâce aux informations récupérées par l’entité ANDSF en consultant le PCRF.

Dans le cas de la procédure IFOM, le PGW est le Home Agent. Il définit une adresse IPv6 permanente au mobile UE qui est l’adresse IP sur  le réseau 3GPP et une adresse IP temporaire (CoA : Care of Address) pour échanger avec le mobile UE via le réseau d’accès WiFi. Ainsi, lorsque l’entité ANDSF décide d’utiliser le réseau d’accès WiFi, il informe le PGW via un message PBU (Proxy Binding Update) et l’UE du changement d’adresse IP (stockée au niveau du PGW). Pour pouvoir différencier les flux, IFOM étend la notion de CoA à plusieurs adresses CoA dans une table étendue (binding cache) et une table d’association de flux (flow binding). La table d’association de flux est une table contenant autant d’entrée que de flux. Chaque entrée de la table est définie par un identifiant de flux, par une priorité, un champ de sélection de trafic (traffic selector) et un champ d’identification de la table de cache nommé BID : Binding Identification.

Pour faciliter la compréhension, j’ai remplacé l’adresse source par le nom de domaine.

Ainsi, lorsque le PGW reçoit un paquet provenant de l’adresse univ-poitiers.fr, il va utiliser l’adresse dans le cache (Binding cache) :

L’UE dispose ainsi de plusieurs adresses IPv4 ou IPv6 qui l’obtient lors de la procédure d’établissement de connexion (PDN Connexion) soit réalisé à travers le réseau 3GPP ou via le réseau d’accès WLAN.

 

Selon le type d’accès WiFi (trusted ou non trusted), le support data est établi :

  • Trusted : Directement entre la station de base AP WiFi à l’entité PGW grâce à l’algorithme d’authentification EAP-AKA ou EAP-SIM avec les informations contenues dans l’application USIM;
  • Non Trusted : Via une entité ePDG sous le contrôle de l’opérateur afin d’établir un tunnel sécurisé IPSEC pour le transport des données entre l’UE et l’EPC. L’entité ePDG est une passerelle pour sécuriser le réseau d’accès non 3GPP.

 

Dans la release R.13, trois autres mécanismes sont proposés :

  • LWIP : LTE / WLAN radio level integration with IPsec tunnel. Le mobile UE est connecté au SGW via un support 3GPP et un support chiffré non 3GPP. Le SGW commute le trafic vers chaque point d’accès.
  • LWA : La station de base eNB contrôle la station de base AP WiFi (Control Plane) et établit un tunnel Data (User Plane) pour échanger le trafic. Le LWA va donc séparer et séquencer les flux de données entre l’accès LTE e t l’accès WiFi. L’avantage de cette solution est la possibilité pour la station de base LTE d’ordonnancer les flux en fonction des conditions radios entre le mobile UE et chaque point d’accès (LTE et WiFi). Le mécanisme LWA est transparent pour l’utilisateur.
  • LAA : La station de base supporte le LTE mais exploite la bande radio WiFi. Le LAA s’appuie sur la procédure d’ajout d’établissement de support (bearer) du CA.

 

 

 

LTE Gigabit

Entre la Release 8 qui normalise le LTE et la Release 15 qui a va standardiser le réseau 5G, le réseau LTE a connu trois phases d’évolution importante :

  • LTE – R8/R.9
  • LTE-Advanced aussi nommé la 4.5G : R10 à R12.
  • LTE-Advanced Pro ou 4.9 G : R13/R14.

Réseau opérateur : Accès radio

L’évolution du cœur radio du LTE-Advanced permet d’atteindre des performances allant à 1 Gb/s sur le lien radio. On retrouve ainsi cette norme sous le nom commercial LTE Gigabit. Le premier déploiement du LTE Gigabit a été lancé par Telstra en février 2017 avec Qualcomm et Ericsson mais Monaco a également déployé ce réseau.

Pour comprendre les performances atteintes, revenons sur le principe radio du LTE :

  • Bande spectrale : 20 MHz
  • Modulation DL : QPSK, 16 QAM, 64 QAM et 256 QAM
  • MIMO : Pas de MIMO, MIMO 2×2, MIMO 4×4.
  • Agrégation de porteuse (CA).

Dans un précédent article, nous avions estimé le débit total LTE à 100 Mbps sans MIMO et avec une modulation 64 QAM. L’estimation était biaisée car le trafic estimé prenait en compte à la fois les signaux de références et les canaux de contrôle PDCCH, ainsi que les canaux de synchronisation et de broadcast (PSS, SSS, BCCH). Prenant en compte que le PDSCH, le débit utile maximal était de 75 Mbps.

L’évolution de la modulation de 64 QAM à 256 QAM permet de transmettre 8 bits par symbole (256 QAM) au lieu de 6 bits par symbole (64 QAM), améliorant d’un rapport 4/3 le débit.

L’utilisation de 4 antennes en émission et en réception permet la transmission simultanée de 4 flux de données, soit une augmentation de débit 4 fois supérieure.

Au total, on arrive donc à un débit maximum de 400 Mbps.

L’agrégation de porteuses permet à l’opérateur de proposer plusieurs bandes LTE pour un seul UE. Le LTE a terme proposera, pour un seul UE, jusqu’à 5 bandes LTE. L’opérateur dispose de plusieurs bandes LTE. En France, les opérateurs disposent de bande de 10 MHz, 15 MHz ou 20 MHz sur les fréquences de 800 MHz, 2600 MHz et 1800 MHz. Prochainement, les opérateurs utiliseront les bandes de 700 MHz.

Avec 20 MHz de bande, le 4×4 MIMO et une modulation de 256 QAM, le débit utilisateur maximal est de 400 Mbps. Ainsi, avec 30 MHz de bandes supplémentaires sur 3 porteuses différences, les opérateurs en France pourront proposer du Gigabit LTE.

Pour résumer, l’opérateur doit disposer d’un minimum de 50 MHz de bande pour pouvoir commercialiser du Gigabit LTE sur 3 porteuses différentes.

Les terminaux : Catégorie de UE

Les terminaux doivent aussi supporter de telles fonctionnalités. La 3GPP a défini différentes catégories de terminaux, et seuls les terminaux de catégorie 16 vendus actuellement supportent de telles performances. Le premier terminal est le Samsung S8 avec la puce Exynos 8895.

A ce jour, on liste :

  • HTC U11
  • LG V30
  • Sony Xperia XZ1
  • Iphone X

L’IPhone 8 n’utilise pour l’instant que du MIMO 2×2, mais les prochains terminaux vendus en 2018 devraient (?) profiter de nouvelles puces pour exploiter le MIMO 4×4.

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.10 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). 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 données 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 NB1).

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.

Bearer par défaut, bearer dédié et Application à la VoLTE

Bearer par défaut ou bearer dédié ?

Le bearer est un circuit virtuel qui s’établit sur le plan utilisateur (user plane) entre l’UE et la PGW (exemple circuit en rouge de la figure 1).

Figure 1 : EPS Bearer

L’association du flux IP avec le bearer est déterminée par un gabarit de trafic nommé filtre TFP (Traffic Flow Template). Ce filtrage est réalisé au niveau du PGW pour les paquets entrants et au niveau de l’eNb pour les paquets sortants. Le gabarit de filtre TFT s’appuie sur les adresses IP (source et destination), les numéros de ports (source et destination) et le protocole IP. Le SDF (Service Data Flow) correspond à un ensemble de flux IP associé à un service utilisateur avec la même QoS (par exemple, plusieurs flux IP provenant de site différents). Les flux ayant les mêmes caractéristiques de QCI/ARP (QoS Class Identifier et Allocation and Retention Priority) seront transmis dans le même bearer (cf. figure 2).

Figure 2 : Association d’un flux dans un bearer

Chaque entité du plan de transport du réseau 4G (eNb, SGW, PGW) a pour rôle de transmettre les paquets vers l’entité suivante. Les paquets sont transmis à travers un bearer entre deux entités. Le choix du bearer est défini de manière unique par un couple d’identifiants entre l’entité qui émet le paquet et l’entité qui reçoit le paquet. Cet identifiant est nommé TEID (couple : TEID_émission, TEID_reception) et la valeur du TEID est définie de manière unique au niveau de chaque entité. Par exemple, on suppose la création d’un bearer (par défaut) pour permettre un accès IP entre l’UE et le PGW. Le PGW crée un TEID=124 pour un bearer, et informe le SGW de son TEID. Le SGW sauvegarde le TEID du PGW et crée lui-même un numéro TEID (par exemple 2028 ou par coïncidence on pourrait aussi avoir un TEID 124 si ce numéro TEID n’existe pas au niveau du SGW, il s’agit alors d’une coïncidence avec une probabilité très faible) qu’il communique au PGW. Le SGW va créer un autre identifiant de bearer (par exemple le 11014) qu’il communique à l’eNB. L’eNb crée un numéro de bearer (ex : 100) qu’il communique au SGW.

Le SGW peut ainsi créer une table de contexte : Le TEID 2028 est associé au TEID 124 du PGW. Le TEID 11014 est associé  au TEID 100 du eNB. Le SGW fait l’association entre son TEID 2028 et le TEID 11014.

Exemple d’une table de contexte simplifiée au niveau du SGW

TEID_SGW TEID_entité @IP_entité Association TEID QoS
2028 124 @IP_PGW 11014 QCI=8 ARP
11014 100 @IP_eNb 2018 QCI=8 ARP

 

Ainsi, lorsqu’un paquet arrive sur le TEID=2028 du SGW, il associe le TEID=2028 au TEID=11014 et réalise l’action qui consiste à transmettre le paquet vers le numéro TEID=100 de l’entité dont l’adresse est @IP_eNb .

Le traitement des paquets est donc réalisé à partir d’une table de contexte, indiquant le « routage » à effectuer vers le TEID de sortie lorsque le paquet arrive par le TEID entrant. Cette table de contexte est créée par la signalisation 4G lors de l’attachement du mobile pour un bearer par défaut, ou déclenchée soit par le mobile soit par le PGW pour la création d’un bearer dédié. C’est ce que nous allons présenter dans cet article.

Par conséquent, nous allons dans cet article décrire le rétablissement d’un bearer par défaut et l’établissement d’un bearer dédié pour la mise en place d’une session. Afin de faciliter la compréhension de l’article, nous allons respecter un code couleur :

  • Message RRC en noir
  • Message EMM en bleu
  • Message ESM en vert
  • Les procédures en rouge

Cet article s’appuie sur le livre : VoLTE et ViLTE de M Perez André.

Procédure de demande de session

Lorsqu’un UE souhaite établir une session, il transmet au MME (il s’agit donc d’un message NAS) une demande d’établissement de session initiée par la sous-couche ESM. Les messages ESM seront encapsulés dans les messages RRC. Les messages RRC transportent également des messages NAS de la sous couche EMM. Les procédures seront définies par un code couleur rouge. Suite à la demande de création d’une session, le MME va déclencher l’établissement de bearer grâce aux protocoles RRC (bearer radio), S1-AP et GTPv2-C (respectivement pour la création du bearer radio, du bearer S1 et S5).

Cet  article s’appuie sur la spécification 3GPP TS 24.301

Rappel sur la mise en place du bearer par défaut lors de l’attachement.

Le default bearer est le bearer par défaut mis en place lors de la procédure d’enregistrement de l’UE (aussi nommée attachement de l’UE) : L’UE fait une demande d’attachement au MME, le MME sélectionne le PGW en fonction de l’APN de l’UE (l’opérateur doit s’assurer que l’algorithme de résolution d’APN au niveau du MME est correctement implémenté). En cas de roaming, le HSS peut notifier au MME de nouvelles données de souscriptions EPS (le HSS fournit donc un nouvel APN), permettant ainsi de réaliser un roaming selon le service LBO (Local Break Out, un contrat d’itinérance particulier). Le PGW fait une requête d’adresse IP au serveur DHCP et attribue une adresse IP permanente à l’UE (permanente signifie tant que l’UE reste attaché au réseau). Le PGW vérifie les valeurs des paramètres de QoS (QCI, ARP, GBR, MBR, AMBR) proposées par le MME (valeurs récupérées au niveau du HSS).

Comme nous l’avions déjà évoqué dans des articles précédents,  le bearer par défaut est un bearer sans débit garanti qui s’établit en même temps que la procédure d’attachement réalisée par la sous-couche EMM  : La sous-couche EMM de l’UE, lors de la demande d’attachement, envoie le message NAS ATTACH à la sous-couche RRC laquelle encapsule le message EMM dans le message RRC Connexion Setup. La sous-couche ESM demande en plus l’émission du message PDN Connectivity Request, comme le montre le tableau 1. Il s’agit d’une différence entre le réseau 3G et le réseau 4G, ce dernier profite de l’attachement pour demander la création de contexte de bearer et accélérer l’accès au réseau pour des demandes de sessions.

Se référer à l’article http://blogs.univ-poitiers.fr/f-launay/2015/05/19/emm-procedure-initial-attach-part-2/ pour plus de détail

Table 1 : RRC Connection Setup : ATTACH REQUEST

Après la procédure d’authentification (détaillé dans l’article …), le MME contacte le HSS (informe le HSS de la localisation du MME qui gère l’UE et le MME récupère le profil de l’UE dont les paramètres de QCI, MBR, …). A partir de cette information, le MME demande la création du bearer S1 et S5 (messages Create Session Request avec le SGW et Create Default Bearer Request portés par le protocole GTPv2-c et transmis respectivement au SGW et au PGW) avec la valeur de QoS du profil. Le PGW vérifie quant à lui les caractéristiques du bearer. Une fois les contextes de bearers S5 et S1 créés (ajout d’une nouvelle entrée dans la table de contexte avec un Identifiant de Chargement), le MME répond à la demande d’attachement de l’UE en transmettant via le protocole S1AP le message Initial Context Setup Request à l’intérieur duquel est encapsulé le message ATTACH ACCEPT et la demande d’activation du contexte de bearer par défaut (message ESM Activate Default EPS Bearer Context Request). L’eNb reçoit le message, rajoute l’entrée à sa table de contexte puis transfère le message EMM et ESM vers l’UE via le message RRC Connection Reconfiguration. Dans la description du message, on peut noter que le réseau indique les caractéristiques du bearer (QoS), l’adresse IP affecté au mobile, l’APN et l’adresse IP du PGW.

Table 2 : RRC Connection Reconfiguration : ATTACH ACCEPT et demande d’activation du bearer par défaut

L’UE répond par un message ESM Activate Default EPS Bearer Context Accept du message NAS ATTACH Complete encapsulé dans la réponse RRC Connection Reconfiguration

  • Etablissement d’une session sur le bearer par défaut : Ré-établissement du bearer par défaut

On suppose ici que l’UE est enregistré, les contextes de bearer ont déjà été créés au niveau du PGW et du SGW (via les messages Create Bearer du protocole GTPv2-c indiqués dans le paragraphe précédent). Ainsi, les paramètres de QoS sont déjà appliqués (remarquer le PGW lors de la création du bearer par défaut avait contacté le PCRF consécutivement à la requête CREATE SESSION REQUEST (etape 7 : http://blogs.univ-poitiers.fr/f-launay/2015/05/19/emm-procedure-initial-attach-part-2/). Par contre, suite à une période d’inactivité, la connexion S1 est libérée au niveau de l’eNb et l’UE n’a plus de ressources radios.

La première phase consiste à réaliser une connexion sécurisée entre l’UE et l’eNb  (RRC Connexion Establishment). La procédure RRC Connexion Establishment est la procédure permettant à l’UE d’informer le réseau qu’il souhaite établir une requête afin de passer de l’état RRC-Idle à l’état RRC-connect. Cette procédure RRC Connexion Establishment est constituée de trois messages : Le message RRC Connexion Request (UE vers eNb avec l’identité S-TMSI de l’UE), RRC Connexion Setup (eNb vers UE) suivi du message RRC Connexion Setup Complete (UE vers eNb). La sous-couche EMM de l’UE envoie le message NAS SERVICE REQUEST à la sous-couche RRC laquelle encapsule le message EMM dans le message RRC Connexion Setup Complete pour indiquer le type de session (session data, appel voix, réponse à un paging..). Le message est crypté en utilisant les clés de chiffrement connues depuis l’attachement (contexte de sécurité NAS comprenant les clés de chiffrement et d’intégrité NAS). La procédure d’authentification est optionnelle (pas d’authentification si la vérification d’intégrité du message est valide). L’eNb reçoit la requête NAS déclenchée par le téléphone et doit le re-transmettre vers le MME. Pour cela, l’eNB utilise le protocole S1AP et émet le message Initial UE Message. A ce stade, l’eNb crée une identité nommée eNb_UE_S1AP_ID pour identifier de manière unique l’UE. Il transmet alors cette information dans le message Initial UE Message et encapsule la requête NAS.

Lorsque le MME reçoit le message NAS Service Request (pour rappel ce dernier est déclenché par l’UE, reçue par l’eNB et retransmis par l’eNb), le MME démarre une procédure d’établissement du RAB, ce qui consiste à établir un lien DRB (Data Radio Bearer) et un bearer S1 entre l’eNb et le SGW.

  • MME –> eNb : L’établissement du contexte au niveau de l’eNb (seulement au niveau de l’eNb) est activé par le MME via le message Initial Context Setup Request. Le MME communique à l’eNb le numéro de tunnel TEID du SGW et les clés de chiffrements et les informations sur la QoS (UE-AMBR, GBR, MBR). Le MME encapsule dans ce message le NAS SERVICE ACCEPT à destination de l’UE

Table 3 : Paramètres échangés dans le message Initial Context Setup Request

Figure 3 : Initial Context Setup Request – Source EventHelix.com

  • eNb <-> UE : L’eNb accomplit une procédure de sécurité AS (afin de dériver les clés de chiffrement des données et d’intégrité sur la couche radio RRC) puis établit le bearer radio avec l’UE en 2 étapes grâce aux messages RRC suivants :
    • eNb -> Ue : message RRC Connection Reconfiguration. L’eNB alloue une identité DRB pour identifier le bearer
    • Ue -> eNb : Message RRC Connection Reconfiguration complete. L’UE confirme l’établissement de la connexion radio (SRB2, DRB)

Ces deux étapes (Sécurité AS – SRB et DRB, puis RRC Conn Rec) correspondent à la procédure Radio Bearer Establishment au niveau du call flow. Cela permet de modifier/configurer la connexion RRC.

A partir de ce moment, les données de trafic de l’UE peuvent être transmises vers le réseau (SGW et PGW). Le lien Uplink DATA est établi, mais pas le lien Downlink car le SGW ne connait pas l’identifiant de tunnel TEID de l’eNb. L’eNb attribut donc une identité du bearer S1 eNB TEID afin de transmettre cette identité au SGW.

L’eNb informe le MME de l’identifiant de tunnel crée pour ce flux de données dans le message Initial Context Setup Response (7) (consécutif donc au message Initial Context Setup Request). Le Message Initial Context Setup Response  contient les informations suivantes : Les Eléments d’Information de la couche Radio de l’UE, l’indicateur CSFB et SRVCC. Le MME informe ensuite le SGW de cet identifiant de tunnel via le message Modify Bearer Request (8). Le SGW doit donc répondre au MME pour lui confirmer l’activation du contexte de bearer par le message Modify Bearer Response (12). Les données de l’UE ayant été transmise via le lien Uplink, si l’UE s’est déplacé, le mécanisme de handover pour la partie Data (Plane User) permet la continuité du trafic montant. Par contre, le plan de contrôle doit aussi prendre en compte cette modification. Ainsi, si le type de RAT a changé (localisation du mobile sur la cellule – ECGI ou de TAI), il faut en informer le PGW via le message Modify Bearer Request (9), et si les règles PCC ne sont pas des règles prédéfinies (règles dynamiques), le PGW contacte le PCRF pour définir s’il faut modifier les règles PCC en fonction du nouveau RAT.

Figure 4 : Rétablissement du  bearer par défaut (référence : TS 23.401, chap 5.3.4.1 UE triggered Service Request)

  • Création d’un autre bearer : Bearer par défaut ou bearer dédié ?

Si une application de l’UE nécessite l’accès à un autre PGW alors, un deuxième bearer par défaut doit être construit (sous condition d’avoir les droits  au niveau du PGW). Dans les faits, l’UE lance une demande de connectivité PDN Connectivity Request vers le MME en précisant l’APN et la QoS, si la résolution au niveau du MME conduit au choix d’un autre PGW, la demande de connectivité sera établie vers ce PGW.

Figure 5 : UE requested PDN connectivity procedure

Attention, un même PDN peut être associé à plusieurs APN. Ainsi, si une application avec la même QoS nécessite une APN différente laquelle renvoie vers le même PGW, il n’y aura pas de création d’un nouveau bearer par défaut. Par contre, si les caractéristiques de QCI sont différentes, alors le réseau va créer un bearer dédié (l’UE peut avoir deux bearer par défaut ayant le même QCI mais avec des ARP différents).

Pour résumer, des bearers dédiés devront être établis si l’EPC décide de mettre en œuvre d’autres caractéristiques de bearer (GBR ou nouvelle valeur de QCI, ce qui nécessite la création d’un autre tunnel et par conséquent la sauvegarde de nouveaux contextes de bearer au niveau du PGW, SGW et eNb).

  • Création d’une session avec une QoS spécifique (Création d’un bearer dédié initié par l’UE)

On suppose le cas suivant : L’utilisateur souhaite lancer une session vers le PGW défini lors de la procédure d’attachement mais avec une valeur de QCI différente de celle définie pour le bearer par défaut. Si l’UE est au repos (mode ECM-Idle/RRC Idle), il doit activer la connexion RRC via la procédure RRC Connexion Establishment (pour rappel la procédure RRC Connexion Establishment est la procédure permettant à l’UE d’informer le réseau qu’il souhaite établir une requête c’est-à-dire pour passer de l’état RRC-Idle vers l’état RRC-connecte). La procédure procédure RRC Connexion Establishment est constituée de trois requêtes : Le message RRC Connexion Request (UE vers eNb), RRC Connexion Setup (eNb vers UE) suivi du message RRC Connexion Setup Complete (UE vers eNb). Dans ce dernier message, la couche RRC encapsule le requête EMM NAS Service Request afin d’établir une connexion sécurisée entre l’UE et le MME (procédure EMM).  Puisque l’UE souhaite établir un bearer dédié, il est nécessaire d’établir une connexion ESM, laquelle nécessite l’encapsulation du message NAS ESM Bearer Ressource Allocation Request délivré avec le message RRC Connection Reconfiguration. Nous avons déjà évoqué le message RRC Connection Reconfiguration lors de la procédure d’attachement avec encapsulation d’un message NAS, mais nous avons aussi vu que le message RRC Connection Reconfiguration permet aussi de définir des paramètres sur l’établissement du lien radio (PHR, DRX, …) Ici, l’UE est déjà attaché, par conséquent seule la sous-couche ESM encapsule la demande de création d’un bearer dédié.

Dans cette requête, l’UE envoie le QCI et le GBR, MBR désiré pour le lien UL et DL. Le MME reçoit le message et le transmet au SGW puis au PGW via le protocole GTP-C.

Figure 6 : Création d’un bearer dédié initié par l’UE

le PGW contacte alors le PCRF via Diameter. La requête CC-Request contient l’identifiant IMSI du mobile et la QoS demandée. Le PCRF regarde les détails dans sa table de souscription pour confirmer ou modifier la QoS demandée par le mobile ou contacte le SPR pour avoir le détail de la souscription du mobile.

Le réseau répond à la demande de l’UE par l’activation d’un bearer ou la modification du contexte d’un bearer, éventuellement d’un rejet de la demande.

Figure 7 : Activation d’un bearer dédié

 

  • Modification d’une session avec une QoS spécifique (Modification d’un bearer dédié)

L’UE va émettre le message Request Bearer Ressource Modification vers le MME. Cette requête permet à l’UE de demander une modification du bearer (modification d’un bearer par défaut, demande de création ou libération d’un bearer dédié). Si la demande est acceptée par le MME, ce dernier va mettre en place une procédure d’activation de bearer dédié.

Figure 8 : Modification d’un bearer

L’activation (ou création) du bearer dédié correspond à la mise en place de contexte de routage de bearer au niveau des entités PGW, SGW et eNb. L’étape 5 est présenté sur la figure 8.

 

  • Etablissement d’un bearer dédié en cours d’appel : Création d’un bearer dédié initié par le réseau

On suppose maintenant qu’un flux existe sur un bearer par défaut (ex application sur un serveur IP comme YouTube ou MyGoogle) et l’utilisateur souhaite activer un service supplémentaire (par exemple payer une VoD avec une QoS associée).

Dans ce cas, le serveur VoD va informer le PGW de la présence d’un nouveau flux de trafic nécessitant une QoS spécifique. La fonction PCEF au niveau du PGW va décider la création d’un bearer dédié à partir des règles de PCC indiquées par le PCRF (QCI=1, GBR, ARP=1, …). Le PGW vérifiera le débit entrant du PDN vers l’UE

Le PGW va envoyer une demande de création d’un bearer dédié (via le message Create Bearer Request) vers le SGW puis relayé au MME. Le MME déclenche la procédure d’établissement d’un E-RAB via l’application S1 AP E-RAB Setup Request avec les caractéristiques de QoS définies par le PCRF.

L’eNb, en cas de non saturation, accepte la demande et informe l’UE de la demande d’un bearer radio via le message RRC Connection Reconfiguration, lequel encapsule le message NAS ESM Activate Dedicated EPS bearer.

Table 4 : RRC Connection Reconfiguration

Si le bearer est crée, on acquitte le MME par le message RRC Conn Reconf Complete, et le MME acquitte le PGW par le message Create Bearer Response, et enfin le PGW informe le PCRF.

Figure 9 : Création d’un bearer dédié à partir d’une application utilisant le bearer par défaut (sur une connexion existante)

Application à la VoLTE

Ce paragraphe exploite l’article suivant : https://www.linkedin.com/pulse/dedicated-bearer-setup-lte-impact-volte-precondition-arindam-ghosh

  • Bearer par défaut dans le réseau Home

A l’allumage, le mobile démarre la procédure d’attachement. Si les données de souscriptions permettent d’identifier l’APN IMS comme l’APN pour le bearer par défaut sans autre APN alors le MME connecte l’UE vers l’APN IMS. La particularité de ce bearer est la valeur de QCI=5. Le MME fournit également l’adresse IP du P-CSCF à l’UE.

Si le mobile se connecte sur un APN non IMS au cours de la procédure d’attachement, alors il se connectera ultérieurement à l’APN IMS par une procédure d’établissement de bearer. Dans la procédure de demande de connexion PDN, le mobile informe l’APN IMS et demande l’établissement d’un bearer par défaut pour la signalisation téléphonique SIP. LE MME établit le bearer par défaut (QCI=5) et fournit l’adresse du P-CSCF au mobile.

  • Bearer par défaut dans le réseau Visité

Si le mobile est en roaming, la question est de savoir si le réseau visité supporte l’IMS.

  • Le réseau visité supporte l’IMS

On suppose évidemment que le réseau home supporte l’IMS (sinon la question ne se poserait même pas), alors le MME du réseau visité propose à l’UE de se connecter au PGW du réseau visité pour les appels voix et donc au P-CSCF du réseau visité.

  • Le réseau visité ne supporte pas l’IMS

On suppose évidemment que le réseau home supporte l’IMS (sinon la question ne se poserait même pas), alors le MME du réseau visité propose à l’UE de se connecter au PGW du réseau HOME et donc au P-CSCF du réseau Home mais le MME refuse les appels voix sur IMS. Toutefois, le mobile pourra utiliser le réseau Home IMS pour d’autres services comme par exemple le SMS.

  • Rétablissement du bearer par défaut pour transmettre les messages SIP

L’application VoIP échange des flux SIP vers le réseau IMS afin de joindre le correspondant appelé et de négocier les codecs si celui-ci est joignable.

  • L’appelant utilise le bearer IMS par défaut pour transmettre la signalisation SIP de demande d’invitation d’appel vers l’appelé (figure 1).
  • Le réseau IMS contacte le PGW de l’opérateur de l’appelé (données entrantes) pour transmettre la signalisation SIP vers l’appelé. Le réseau de l’appelé émet une requête de paging (non présenté dans cet article), l’UE appelé demande le rétablissement du bearer par défaut (figure 1).

L’UE appelant envoie dans le message SIP INVITE la liste des codecs compatibles vers l’UE appelé. L’UE appelé reçoit la liste des codecs et n’en retient qu’un. Il informe l’UE appelant du codec choisit.

  • Création du bearer dédié de l’appelant et de l’appelé.

A ce stade, l’appelant connait le type de codec, le réseau peut donc demander la création d’un bearer dédié avec le codec désiré et le réseau créé également un bearer dédié du coté de l’appelé.

  • Appelé : Figure 9 – Création d’un bearer dédié initié par le réseau
  • Appelant : Figure 9 – Création d’un bearer dédié initié par le réseau

Dans ce cas, l’AF (il s’agit du P-CSCF) informe le PCRF d’une modification de la session IP-CAN en indiquant les paramètres du nouveau bearer. Le PCRF envoie une requête IP-CAN session modification vers le PGW, lequel décide contacte le MME via une requête Create Bearer Request. Le MME analyse la demande et si elle accepte la demande, envoie un E-RAB setup request au eNb. Enfin, l’eNb envoie une requête RRC Connection Reconfiguration vers l’UE.

  • Fonction du PCRF

Dans les deux cas précédent, le PGW contacte alors le PCRF via Diameter. La requête CC-Request contient l’identifiant IMSI du mobile et la QoS demandée. Le PCRF regarde les détails dans sa table de souscription pour confirmer ou modifier la QoS demandée par le mobile ou contacte le SPR pour avoir le détail de la souscription du mobile.

Le PCRF peut recevoir des requêtes de la part d’une entité extérieure (AF : Application Function comme par exemple le P-CSCF) ou de la part du mobile afin de mettre en œuvre un service utilisant un bearer dédié (meilleure qualité que le bearer par défaut).

Dans tous les cas, le PCRF définie une règle PCC (préétablie ou établie à la volée) et retourne le QCI/ARP pour établir un bearer dédié. Il transmet aussi les paramètres de taxation au PCEF.

Si le PGW reçoit une valeur de QCI et un ARP tous deux identiques aux paramètres d’une session déjà en cours, alors le PGW demande la modification du bearer actuelle pour insérer ce nouveau flux (augmentation du débit). Le PGW réalise le mapping entre le flux de données (SDF : Service Data Flows) et le bearer correspondant.

Le PCRF assure aussi la fonction de Gating, c’est-à-dire peut bloquer un type de paquet ou tous les paquets (par exemple lors du dépassement de son forfait) au niveau du PGW.

La fonction Gating est une fonction qui détermine si oui on non un paquet peut traverser le PGW.

 

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. On parle de séquencement ou d’ordonnancement : le mobile est en mode connecté et attend des instructions sur l’allocation des ressources radios pour transmettre ou recevoir des données.

Dans le cas ou le mobile est en mode de veille (Idle mode), il scrute les canaux PDCCH pour recevoir des notifications de paging.

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.

Dans le mode RRC Connected, 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.

La station de base indique si elle supporte le mode DRX etendu dans le message de SIB1. Si la valeur DRX est transmises dans le SIB2, la valeur eDRX (si la station de base supporte le mode eDRX) est échangée entre le mobile UE et l’entité MME

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 413 jours (modifié le 20/01/2021 suite à la remarque de Louis Adrien), 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

Pourquoi 413 jours :

Se référer à la Table 10.5.163a/3GPP TS 24.008: GPRS Timer 3 information element. La valeur du Timer est codée sur un octet, 5 bits pour la valeur du timer (0 à 31) et 3 bits pour indiquer le pas temporelle du timer :

  • 000 : 10 mn
  • 001 : 1h
  • 010 : 10 heures
  • 011 : 2 heures
  • 100 : 30 secondes
  • 101 : 1 mn
  • 110 : 320 heures

Donc 31*320 = 413 jours

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

 

 

Attachement au réseau 4G : Différents scénarios

Dans deux articles écrits en mai 2015, j’avais décris la procédure d’attachement au réseau 4G : http://blogs.univ-poitiers.fr/f-launay/2015/05/05/emm-procedure-initial-attach/ et http://blogs.univ-poitiers.fr/f-launay/2015/05/19/emm-procedure-initial-attach-part-2/

Je vais revenir sur ces deux articles afin de mieux expliquer les différents scénarios s’appliquant au mobile lorsque ce dernier fait une demande d’attachement.

La procédure d’attachement nécessite 2 étapes clés:

  • L’identification de l’UE auprès du MME.
  • Authentification de l’UE

L’identification consiste, de la part du mobile, à fournir un identifiant lequel est transmis en clair sur l’interface air jusqu’au MME. Il s’agit donc d’un message NAS. Cet identifiant est transmis en clair, c’est à dire non crypté. (Imaginez en effet que l’UE crypte son identifiant par une clé Kc connu par le MME. Le MME n’ayant pas connaissance de l’UE qui lui a transmis le message devrait tester toutes ses clés Kc pour récupérer l’identifiant).

L’identifiant permettant de connaitre l’UE peut être :

  • L’identifiant IMSI
  • L’identifiant GUTI.

Ces deux identifiants ont été décrits dans l’article suivant : http://blogs.univ-poitiers.fr/f-launay/2015/05/06/imsi-tmsi-gummei-guti/

Le GUTI, Global Unique Temporary Identifier permet d’identifier de manière unique l’UE. Cet identifiant est constitué d’un code unique fourni par le MME, nommé M-TMSI. Le M-TMSI permet donc de connaître l’UE au niveau du MME. En rajoutant le code d’identifiant du MME, du code identifiant le pool MME, l’identifiant du réseau opérateur (MNC) et le code pays (MCC), le GUTI permet donc de connaître le MME sur lequel était enregistré l’UE auparavant.

Ce dernier point est important, lorsque l’UE se détache du réseau 4G (lorsqu’il envoie un message DETACH request), les contextes de commutation de bearer sont supprimés au niveau du PGW et du SGW mais :

  • l’UE conserve son contexte de sécurité NAS, le GUTI et le tracking area
  • le MME conserve le contexte de sécurité NAS associé au GUTI.

L’authentification consiste à vérifier l’identité de l’UE, soit à partir du message d’intégrité NAS soit à partir d’une procédure d’authentification mutuelle nommée AKA. Cette procédure permet au réseau de vérifier l’UE et pour l’UE de valider le réseau. Le choix de la procédure d’authentification est dictée par la manière dont l’UE s’identifie au réseau.

Si l’UE transmet son identifiant IMSI, dans ce cas le réseau applique la procédure d’authentification AKA mais si l’UE transmet son identifiant GUTI, le réseau est alors en mesure de récupérer son contexte de sécurité NAS.

Le contexte de sécurité NAS permet de garantir un échange authentifié entre l’UE et le MME (NAS Message) en chiffrant les données via une clé de chiffrement Knasenc et de valider l’intégrité du message via une clé d’intégrité Knasinc. Ces deux clés ont été générées au cours d’un précédent attachement avec l’identité IMSI.

Détachement

Nous allons maintenant nous intéresser à la spécification 23.401. (version 8 ira très bien).

Nous avons vu précédemment que l’UE pouvait s’identifier selon son IMSI ou son GUTI. Or, pour s’identifier avec le GUTI, le téléphone doit avoir été enregistré. Ainsi, aussi étrange que celà puisse paraître, pour comprendre cette procédure d’attachement, je vais commencer par expliquer la procédure de détachement, c’est à dire lorsque l’UE se désenregistre du réseau.

La procédure de détachement (Detach procedure – section 5.3.8 p70) peut être déclenchée par l’UE ou par le réseau.

L’UE peut faire une demande de détachement lorsque l’utilisateur éteint son téléphone ou bascule en mode avion. Dans ce cas, l’UE émet une requête NAS avec un indicateur « Switch Off » et le MME répond par un Detach Accept. Les contextes de commutation sont supprimés au niveau du SGW et PGW, le MME conserve quant à lui le contexte de l’UE (GUTI et clé de chiffrement/clé d’intégrité lié avec le GUTI).

Le MME peut aussi faire une demande de détachement pour un UE,

  • soit une demande implicite (UE est implicitement détaché) qui a lieu lorsque l’UE n’a pas transmis ou reçu de données depuis un certains temps (implicit Detach Timer = T3423 + 4 mn si l’ISR – Idle Mode Signaling Reduction est activé  )
  • soit une demande explicite par exemple pour réaliser de l’équilibrage de charge sur un autre UE

Jusqu’à présent, le MME a conservé le contexte NAS et le GUTI de l’UE. Au bout d’un certain temps

La fonction Purge (Purge Function cf section 5.3.9.3 p74) permet au MME d’informer le HSS qu’il a supprimé le contexte NAS et le GUTI. Ce dialogue est réalisé par le protocole Diameter via le message PUR/PUA (Purge Request/Answer). Dans le cas de cette procédure, le MME n’a plus de contexte concernant l’UE.

Attachement

Il nous reste plus qu’à étudier les différents scénarios pour la procédure d’attachement. Il y a 5 cas en tout :

1 – L’UE se connecte pour la première fois : Il transmet son identifiant IMSI

2 – L’UE se connecte avec son identifiant GUTI

  1. Sa demande est transférée au MME sur lequel il était précédemment connecté
    1. Le MME a conservé son contexte
    2. Le MME n’a plus son contexte
  2. Sa demande est transférée à un MME différent de son précédent MME
    1. Le MME a conservé son contexte
    2. Le MME n’a plus son contexte

Attachement

Il faut bien se rappeler que quelque soit le scénario, la première étape consiste à s’identifier, donc à transmettre en clair son identifiant. Ensuite, si le mobile transmet son IMSI, la requête NAS de demande d’attachement n’est pas chiffrée.

Par contre, si le mobile transmet son GUTI, la suite du message NAS est chiffrée et une clé d’intégrité est rajoutée.

Voyons les différents cas.

CAS 1 – L’UE se connecte pour la première fois : Il transmet son identifiant IMSI. Dans ce cas, le réseau effectue une authentification AKA. J’invite le lecteur à se référer à l’article http://blogs.univ-poitiers.fr/f-launay/2015/05/05/emm-procedure-initial-attach/

2 – L’UE se connecte avec son GUTI.

CAS 2 : L’eNb analyse le GUTI, ce dernier est connecté au MME via un lien S1-MME, il peut donc relayer la requête NAS de demande d’attachement au MME. Le GUTI est envoyé en clair, la requête NAS est chiffré et une clé d’intégrité est rajouté.

CAS 3 : L’eNb analyse le GUTI, ce dernier n’est pas connecté au précédemment MME. La requête est donc transmise à un nouveau MME, et ce dernier vient interroger l’ancien MME. Le GUTI est envoyé en clair, la requête NAS est chiffré et une clé d’intégrité est rajoutée correspondant à l’ancien MME. Le nouveau MME transférant le tout à l’ancien MME. On suppose que ce MME n’a pas conservé le contexte ou la clé d’intégrité n’est pas correcte, dans ce cas le MME informe le nouveau MME qu’une procédure d’authentification doit être réalisée. Le nouveau MME demande à l’UE de s’identifier à nouveau via son identifiant IMSI

CAS 4 : L’eNb analyse le GUTI, ce dernier est connecté au MME via un lien S1-MME, il peut donc relayer la requête NAS de demande d’attachement au MME. Le GUTI est envoyé en clair, la requête NAS est chiffré et une clé d’intégrité est rajouté. Le MME est capable de déchiffrer le message et la clé d’intégrité est correcte. Dans ce cas, le MME accepte la demande d’attachement.

CAS 5 : L’eNb analyse le GUTI, ce dernier n’est pas connecté au précédemment MME. La requête est donc transmise à un nouveau MME, et ce dernier vient interroger l’ancien MME. Le GUTI est envoyé en clair, la requête NAS est chiffré et une clé d’intégrité est rajouté. L’ancien MME est capable de déchiffrer le message et la clé d’intégrité est correcte. Dans ce cas, l’ancien MME informe le nouveau MME que la demande peut être acceptée.

Attachement1Attachement2Selon les différents cas, la procédure d’authentification AKA n’est pas nécessaire. Voici une dernière figure résumant les 5 cas possibles et le dialogue entre l’UE et le MME

Attachement3