Principe du SDN dans une architecture réseau classique

I – Généralités sur le réseau IP

I-1) Les équipements de routage et de commutation

Le réseau IP est constitué d’équipements de routage et d’équipements de commutation afin de mettre en relation une machine et un serveur.

Le rôle du routeur est d’acheminer chaque paquet IP au nœud suivant afin que le paquet puisse être transporté de bout en bout, de la machine IP au serveur et inversement. Avant d’être déployés sur le réseau, les routeurs sont  configurés afin d’une part de définir les adresses des interfaces physiques et virtuelles du routeur et d’autres part d’informer le routeur des protocoles de routage à appliquer pour acheminer les paquets IP. Les protocoles de routage permettent à chaque routeur de récupérer des informations des routeurs voisins afin de constituer localement sa propre table de routage. Ainsi, la table de routage est actualisée en temps réel pour prendre en compte l’état de chaque nœud (saturé, hors ligne, …) de manière dynamique : Les routeurs échangent entre eux des informations sur leur table de routage en fonction du protocole de routage choisi. La table de routage permet de définir le réseau de destination pour chaque paquet IP selon un critère de  coût (nombre de saut, débit, délai, …). L’avantage du routage dynamique est l’adaptation  aux évolutions du réseau (nouvelles routes, routeur saturé ou lien défaillant) en temps réels.

Les informations de routages transmises entre routeurs dépendent du protocole de routage choisi :

  • états de lien, chaque routeur s’appuie sur la qualité et les performances du lien et de la bande passante qui les relie les uns aux autres. Cet échange permet de définir une cartographie complète du réseau au niveau de chaque routeur. Ce protocole de routage s’appelle OSPF (Open Shortest Path First) et il est également utilisé par le réseau MPLS ;
  • vecteur de distance se base sur le principe que chaque routeur dispose d’une table de routage indiquant, pour chaque réseau de destination, l’interface locale permettant de l’atteindre et la meilleure distance qui lui est associée (exemple de protocole RIP, EIGRP) ;
  • label, les routeurs échangent des informations de label dans le contexte MPLS (LDP : Label Distribution Protocol) ;
  • bordure, en bordure de deux réseaux différents, les routeurs échangent des informations de routage et d’accessibilité : BGP (Border Gateway Protocol).

Deux grandes familles de protocole sont définies : Le protocole interne domaine (OSPF, RIP, MPLS) et le protocole d’interconnexion inter domaine  (BGP, EGP – Exterieur Gateway Protocol, …).

I-2) Le réseau opérateur 4G

Si on s’intéresse plus particulièrement au réseau opérateur, le réseau de transport de l’opérateur PLMN permet de fournir une interconnexion entre les différentes entités du réseau mobiles 4G. Cette interconnexion s’appuie sur deux types de réseaux principaux :

  • le réseau MPLS-VPN (Multi-Protocol Label Switching – Virtual Private Network) constituant le réseau de transport du réseau EPC
  • le réseau VPLS (Virtual Private Lan Service) assurant l’interconnexion de niveau 2 entre les eNB et le cœur réseau (MME, SGW)

Afin d’assurer le trafic des flux IP, le réseau MPLS utilise deux types de routeurs :

  • les routeurs EDGE LSR (Label Switch Router) sont les routeurs de passerelle vers un autre réseau
  • les routeurs Core LSR constituent le domaine réseau MPLS. Ils réalisent le routage et l’étiquetage des premiers paquets et ensuite de la commutation de label.

Figure 1 : L’architecture du réseau MPLS

Le réseau VPLS est un réseau virtuel de niveau 2 qui s’appuie sur les trames Ethernet pour réaliser de la commutation Ethernet et de la commutation de label. Les tables de labels sont échangées via le protocole LDP (Label Distribution Protocol) entre les équipements du réseau VPLS.

II – Compréhension du protocole de routage

La représentation simplifiée d’un routeur est décrite sur la figure 2 par un plan de contrôle qui décide de la route et d’un plan de donnée pour prendre en charge le trafic. Pour les équipements de réseau traditionnels, les plans de contrôles et le plan de données sont colocalisés dans le même équipement.

 

 

Figure  2 : La configuration simplifiée d’un routeur

La souplesse apportée par les algorithmes de routages permet d’allouer dynamiquement les routes optimales en fonction de l’évolution de charge du trafic. Cependant, cette solution souffre de deux défauts majeurs.

Le premier défaut est l’adaptabilité du réseau de transport en fonction de la charge de trafic. En effet, les équipements du réseau de transport (commutateurs et routeurs) sont déployés en fonction du trafic estimé. Le réseau de transport est donc surdimensionné par rapport au besoin moyen des clients mais au vu des prévisions de charge pour les années à venir, l’opérateur devra déployer d’autres équipements de routage et de commutation.

Le deuxième défaut est le manque de flexibilité du réseau vis-à-vis de l’installation de nouvelles fonctions réseaux comme l’équilibrage de charge, des parefeux, ou le déploiement de nouveaux serveurs. De telle modification nécessite soit la reconfiguration du réseau et le déplacement éventuel d’équipements actifs soit la contrainte de respecter la topologie actuelle du réseau pour rajouter de nouveaux services.

Afin d’apporter de la souplesse au déploiement de services réseaux sur le réseau de transport, le SDN (Software Designed Networking) repose sur :

  • l’idée de séparer le plan d’acheminement des flux IP et le plan de contrôle de ces flux des entités réseau
  • de paramétrer les fonctions réseaux à partir des applications souhaités.

Il existe deux modèles SDN :

  • Programmabilité via un contrôleur.

Dans ce modèle, une application donne un ordre abstrait et global à un contrôleur, qui à son tour traduit cette requête en une suite d’ordres auprès des équipements du réseau concerné.

  • SDN Overlay: Création d’un réseau virtuel au dessus du réseau physique. Dans ce modèle, les applications créent leur propre réseau « overlay », s’affranchissant des contraintes du réseau physique sous jacent. Ce dernier n’a pour mission que la simple connectivité entre les noeuds d’extrémité des tunnels, et le réseau d’overlay assure l’intégralité des services.

Programmabilité via un contrôleur

Le positionnement du SDN est donc de remplacer les routeurs et commutateurs de niveau 1 à 4 par une machine physique universelle dont le traitement des flux IP est modifié en temps réels par une couche de contrôle, appelé contrôleur SDN et de piloter le contrôleur SDN à partir des applications souhaités.

La couche de contrôle a pour rôle d’implémenter des règles  sur le commutateur SDN. Les règles peuvent concerner des affectations de VLANs (port d’accès), du routage et des traitements spécifiques de services réseaux (équilibrage de charge, haute disponibilité, QoS,…)

Ainsi, le plan de transport SDN est basé sur l’évolution de l’architecture suivante (figure 3):

Figure 3 : Architecture SDN

Le protocole d’injection de règle SDN le plus connu est OpenFlow (version 1.0 à 1.5)

Le contrôleur est, quant à lui, piloté par le besoin des applications. On dit que le contrôleur fournit une abstraction du plan de transport aux applications. La notion d’abstraction signifie que le contrôleur offre des interfaces programmables aux applications réseaux (les interfaces sont nommées API) et le contrôleur se charge de piloter le plan de données en injectant des règles d’acheminement spécifiques répondant aux besoins des applications sans que les applications connaissent ces règles.

Ainsi, comme le montre la figure 4, la couche d’abstraction du contrôleur comporte une interface de programmation (interface Nord) qui fournit des fonctions génériques et banalisées de manipulation du réseau de transport en cachant les détails techniques des entités du réseau.  Ceci permet à une application d’informer le contrôleur des besoins de traitement de flux de manière générale en faisant abstraction des détails technique du matériel.

Figure 4 : Le principe du SDN

Le contrôleur dispose d’une interface nord appelé Northbound API afin de proposer des API de haut niveau aux applications SDN. Les applications SDN peuvent être une demande de gestion du réseau, un contrôle d’accès, une priorité de service à mettre en œuvre, …

Le plan de contrôle va orchestrer la demande des applications en transmettant via l’interface sud les tables d’acheminements correspondantes. Les protocoles utilisés sur l’interface sud peut être le protocole CLI (Command Line Interface), le protocole OpenFlow, ou d’autres protocoles (NETCONF/YANG, …)

Le terme d’orchestration désigne le processus qui ordonne au contrôleur de satisfaire les demandes de service d’un client ou d’un profil de client selon une politique d’optimisation.

Le plan de données ou plan usager est chargé de l’acheminement (forwarding) du trafic des utilisateurs et à l’application de politique de trafic (parefeu, VLAN, …) dont les règles ont été transmises par le contrôleur. La politique réseau étant définie par les applications.

 

SDN Overlay

Principe de Overlay

Le réseau overlay est une solution initialement dédiée aux hébergeurs de Cloud Center afin que deux serveurs de l’hébergeur, physiquement éloignés, puissent communiquer entre eux via  un réseau de transport opérateur (réseau d’interconnexion externe aux hébergeurs donc non modifiable).

Les réseaux Overlay (over-layer) signifie construire un réseau virtuel de couche 2 au-dessus d’un réseau de couche 3 : Les paquets du réseau sont encapsulés puis routés à travers l’infrastructure existante. Un des protocoles proposé est le VXLAN (Virtual eXtensible LAN) proposé dans le RFC 7348. Il encapsule les trames Ethernet dans un datagramme UDP.

A l’origine, cette solution a été proposée pour faciliter l’interconnexion des serveurs de cloud qui sont basés sur le principe de virtualisation : un hébergeur dispose de plusieurs salles de serveurs. Chaque serveur est une machine physique pouvant recevoir plusieurs machines virtuelles (VM). Afin de partager les ressources physiques (RAM, CPU, cartes réseau, …), il est nécessaire d’installer sur le serveur un logiciel nommé hyperviseur. Un hyperviseur (VMM : Virtual Machine Monitor) est un moniteur de machines virtuelles installé directement sur la machine physique (hyperviseur bare metal) ou sur un système d’exploitation. Son rôle est de contrôler l’accès au matériel et de partager les ressources physiques entre toutes les machines virtuelles (VM : Virtual Machine).

L’hyperviseur virtualise l’interface de réseau physique et la partage entre toutes les machines virtuelles. Chaque VM dispose de sa propre adresse MAC et adresse IP. Les VMs sont configurées en mode pont, NAT ou sont isolés des autres VMs (Host Only ou réseau privée).

La virtualisation du réseau coordonne par conséquent les commutateurs virtuels dans les hyperviseurs du serveur et les services réseaux pour les VM connectées.

L’hyperviseur réalise ainsi un commutateur virtuel permettant de connecter les VM les unes aux autres. Le commutateur virtuel supporte le VLAN, mais le protocole 802.1Q limite à 4096 le nombre de VLAN. Lorsque l’hébergeur de solution cloud souhaite exploiter le réseau IP opérateur pour transmettre des paquets IP entre deux serveurs situés sur le même réseau virtuel, il est nécessaire d’encapsuler les trames dans une couche supérieure.

Les hébergeurs exploitent le protocole VXLAN, chaque VM sur une machine physique est identifiée par un identifiant réseau VXLAN sur 24 bits, nommé VNI. L’hyperviseur de chaque serveur gère l’encapsulation et la désencapsulation des trames contenues dans les VXLANs (VTEP : VXLAN Tunnel EndPoint).

Supposons qu’une machine virtuelle située sur un réseau virtuel (VXLAN) dans un serveur physique souhaite transmettre des données vers une machine virtuelle situé dans un autre serveur physique (VXLAN). La machine virtuelle source construit sa trame Ethernet avec les champs suivants :

Figure 5 : L’architecture réseau entre deux serveurs interconnecté par le réseau IP opérateur

La figure 6 représente l’encapsulation et les entêtes associées :

Trame Ethernet VM: VXLAN ID/Mac Dest/Mac Src VM/ IP Src VM/ Ip Dest VM/ TCP ou UDP Data

L’hyperviseur de la machine virtuelle encapsule la trame Ethernet dans la couche UDP :

MAC VTEP Dest ou MAC GW/ MAC VTEP Source/IP VTEP source/IP VTEP Destination/ UDP/Data contenant laTrame Ethernet VM.

Figure 6 : L’encapsulation VXLAN

Nous venons de voir l’overlay, mais pas encore le SDN.

SDN Overlay ou Overlay réseau programmable

Nous savons que le principe du SDN réside dans la séparation du plan de contrôle et du plan utilisateur. Dans le cas du SDN overlay, le réseau opérateur ne peut pas être contrôlé, le SDN s’applique donc au reseau overlay.

Les datacenters doivent aussi être flexibles et gérer au mieux les flux de réseaux. La programmabilité s’exprime surtout ici avec l’orchestration des ressources : comment coordonner intelligemment le processus de mise à disposition d’infrastructure en entreprise. Ainsi, la virtualisation permet à l’intelligence de l’infrastructure des hébergeurs Cloud de contrôler et de déployer automatiques les serveurs. Les éléments de l’infrastructure (stockage, calcul, mis en réseau) sont virtualisés et regroupés en pools de ressource. De plus les applications doivent être mobiles et répliquées sur un Cloud distant afin de permettre une reprise après sinistre.

L’utilisation d’une plate-forme de gestion du Cloud (CMP – Cloud Management Platform) permet de provisioner des réseaux virtuels en activant les services réseaux et les services de sécurité virtuels en fonction des charges de travail. Le CMP est donc un contrôleur qui d

Il existe plusieurs solutions virtuelles ( VMware NSXMidokura MidoNet et Nuage Networks) afin de controler dynamiquement les routeurs virtuels, les commutateurs virtuels grace à un controleur de service virtualisé qui permet également de déplacer, créer ou détruire un VM afin de répondre au mieux au besoin du client

Le rôle du SDN est donc d’orchestrer les VMs afin d’adapter les ressources de l’hébergeur cloud (Amazon SE3, …) au besoin du client en assurant la fiabilité de l’interconnexion, l’accès rapide au données, ….

 

Merci à Sébastien Couderc d’avoir accepté de relire cet article

Dual Connectivity : La Double Connectivité

I) Introduction

La double connectivité (DC : dual connectivity) est une évolution fondamentale de la norme 4G. Celle-ci est définie dans la release R.12 et elle doit être comprise pour deux raisons principales :

  • le fonctionnement du mécanisme DC est exploité par les mécanismes LWIP et LWA ;
  • la double connectivité sera mise en œuvre pour le déploiement de la 5G en mode non autonome (NSA : non standalone). La double connectivité fait donc parti des mécanismes transitoires vers la 5G.

La double connectivité signifie que le mobile UE va établir simultanément deux supports radios (RAB : Radio Access Bearer) avec deux stations de bases. Ces stations de bases peuvent être des entités eNB pour la 4G et à terme, on parle de double connectivité entre une station de base eNB (ou ng eNB) et une station de base gNB (station de base 5G). La station de base ng eNB est une station de base 4G évoluée qui communique avec le cœur réseau 5G (le cœur réseau 5G se nomme 5GC).

II Explication de la double connectivité

La double connectivité différencie le plan de contrôle (control plane) et le plan de transport des données, c’est-à-dire le plan utilisateur (user plane). Lorsque le mobile UE veut établir un support EPS (EPS bearer) il commence par demander l’établissement d’un support de signalisation radio (SRB : Signalling Radio Bearer) avec une station de base eNB. Cette station de base eNB sera nommée par la suite entité MeNB (Master eNb). L’échange de signalisation (couche RRC) s’effectuera entre le mobile UE et la station de base MeNB.

Figure 1 : Le plan de contrôle pour la double connectivité

 

La double connectivité suppose l’établissement de deux supports radios (RAB) : un support radio avec l’entité MeNB et un support radio avec une deuxième station de base eNB nommée SeNB. Les deux stations de bases MeNB et SeNB impliquées dans la double connectivité doivent impérativement avoir une interface X2.

Les fonctions du MeNB sont les suivantes :

  • établir un support data radio entre la station de base MeNB et le mobile UE ;
  • échanger des informations de contrôle avec une station de base SeNB (Secondary eNB) ;
  • établir un support data radio entre la station de base SeNB et le mobile UE ;
  • récupérer les mesures radios de l’UE correspondant à la station de base MeNB et la station de base SeNB (dans le cas de la station de base SeNB les mesures sont transmises via l’interface X2 entre le SeNB et le MeNB) ;
  • échanger des informations de contrôle avec le MME ;
  • demander l’établissement, via le MME, d’un support S1 entre le MeNB et le SGW sur l’interface S1-U U entre la station de base MeNB et l’entité SGW;
  • éventuellement, demander l’établissement via le MME, d’un support S1 entre le SeNB et le SGW sur l’interface S1-U entre la station de base SeNB et l’entité SGW;
  • contrôler le handover entre le mobile UE et la station de base SeNB
  • contrôler le handover entre le mobile UE et la station de base MeNB, et dans ce cas, libérer le RAB avec le SeNB

Concernant le plan de transport, il existe sept architectures DC différentes reposant sur le principe d’ancrage du support soit au niveau de la station de base MeNB, soit au niveau de l’entité SGW : Deux supports radios sont établis entre le mobile UE et avec chacune des stations de base (MeNB et SeNB) et un support S1-U est établi entre la station de base MeNB et l’entité SGW. Un deuxième support S1-U peut être établi entre la station de base SeNB et l’entité SGW.

Chaque station de base eNB (MeNB et le SeNB) gère le trafic de manière autonome sur les sous-couches MAC et RLC de la couche 2 et chacun station de base eNb gère sa couche physique.

Ainsi, une fois la signalisation échangée entre le mobile UE et la station de base MeNB (couche RRC) et une fois l’établissement des supports radios, les 7 architectures sont les suivantes :

  • Architecture 1A : un support S1-U est établi entre la station de base MeNB et l’entité SGW et un support S1-U est également établi entre la station de base SeNB et l’entité SGW. Au niveau du SeNB, le flux est géré par la couche PDCP du SeNB indépendamment du MeNB
  • Architecture 2 : Au moins deux supports S1-U sont établis entre l’entité SGW la station de base MeNB. L’un des supports sera associé au support radio du MeNB, le deuxième support sera associé au SeNB. Aucun support S1-U n’est établi entre l’entité SGW et la station de base SeNB. La séparation des supports est à la charge du SGW et le MeNB va gérer la redirection du trafic vers le SeNB :
    • Architecture 2A : La redirection du flux est routée du MeNB vers le SeNB. Le flux est donc pris en charge par la sous-couche PDCP de la station de base SeNB.
    • architecture 2B : La redirection du flux est gérée par la couche PDCP de la station de base MeNB et envoyé à la sous-couche RLC de la station de base SeNB. C’est donc le MeNB qui gère le chiffrement des données;
    • architecture 2C : La redirection du flux est gérée par la couche RLC de la station de base MeNB vers la sous-couche RLC du SeNB. La sous-couche RLC de la station de base est configuré en mode transparent, le contrôle et l’acquittement des trames est effectuée au niveau de la station de base SeNB.
  • Architectures 3A/3B/3C se differencient des architectures 2A/2B/3C par le fait que la commutation des supports est à la charge de la station de base MeNB. Le SGW établi au moins un bearer radio S1-U avec le MeNB. Le ou les supports S1-U sont séparés au niveau de la station de base MeNB
    • Architecture 3A : une partie des paquets est transmis vers la sous-couche PDCP de la station de base MeNB, l’autre partie vers la sous-couche PDCP de la station de base SeNB
    • Architecture 3B : L’ensemble des paquets est traité par la sous-couche PDCP de la station de base MeNB, une partie des paquets est ensuite transmise vers la sous-couche RLC de la station de base MeNB, l’autre partie vers la sous-couche RLC de la station de base SeNB
    • Architecture 3C : L’ensemble des paquets est traité par la sous-couche PDCP de la station de base MeNB et transféré à la sous-couche RLC de la station de base MeNB. Une partie des paquets est dirigé vers la sous-couche RLC de la station de base secondaire SeNB, la sous-couche RLC de la station de base SeNB fonctionne en mode transparent .

Les architectures 2 et 3 ont l’avantage d’être transparentes pour le cœur réseau CN, la gestion de la mobilité est donc réalisée uniquement au niveau de la station de base MeNB, ce qui simplifie la signalisation avec le cœur réseau, surtout si on considère les stations de base secondaire SeNB comme des petites ou micro stations de base.

L’architecture 3C présente l’avantage de laisser la station de base MeNB gérer la séparation des supports S1-U. Cette fonction dévolue à la station de base MeNB lui permet, à partir de la connaissance de la qualité du lien radio (CQI : Channel Quality Indicator)  du support RAB entre le mobile UE et la station de base MeNB, ainsi que le CQI entre le mobile UE et la station de base secondaire SeNB d’ordonnancer de manière optimale les flux IP ce qui permet d’améliorer le débit au niveau du mobile UE.

L’architecture 1A a l’avantage de ne pas surcharger le réseau de transport backhaul contrairement aux architectures 2 et 3. L’opérateur doit en effet sur-dimensionner son réseau de transport par un facteur 3 lorsqu’il choisit de déployer les architectures 2 ou 3.

Au final, seules les architectures 1A et 3C ont été retenues pour la double connectivité. L’architecture 3C est plus fexible pour gérer la mobilité et le handover par rapport aux architectures 3A et 3B.

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

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.

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