L’IoT – Evolutions R16 et R17

Introduction

Le standard 3GPP a démarré ses travaux de normalisation pour l’IoT à partir de la R.10 pour définir une liste de spécifications pour les terminaux et le cœur de réseau afin d’éviter la congestion (Extended Access Barring), d’avoir moins d’impact sur les smartphones (LAPI), réduire la complexité (Half Duplex, réduction de la puissance, bande plus petite …), avoir une meilleure sensibilité pour une transmission à faible débit (bande plus petite).

Dans la R.11, la 3GPP propose une méthode de réveil de terminaux et une transmission de données par SMS.

Dans la R.12, la 3GPP propose des optimisations pour la réduction de la consommation énergétique (UEPCOP : mode PSM et eDRX) et une méthode de transmission de données de taille réduite (Small Data)

Figure 1 : Le standard 3GPP R10 à R12 pour l’IoT

Dans la R.13, la 3GPP une optimisation du cœur de réseau pour prendre en charge la transmission de données :

  • dans le plan de contrôle Control-Plane CIoT EPS Optimization ;
  • dans le plan de trafic User-Plane CIoT EPS Optimization.

L’optimisation CP CIoT EPS Optimization propose de transmettre des données dans un message NAS entre l’UE et le MME. Sur l’interface radioélectrique, le message NAS est encapsulé dans un message RRC, lorsque le mobile est à l’état RRC_CONNECTED, c’est-à-dire à la suite de la procédure d’accès aléatoire. Dans l’optimisation CP CIoT EPS Optimization , la mise en sécurité AS n’est pas mise en œuvre, c’est-à-dire la connexion RRC n’est ni chiffrée, ni authentifié (intégrité).

L’optimisation UP CIoT EPS Optimization permet de transmettre des données entre l’UE et le MME lorsque le mobile est à l’état RRC_CONNECTED avec la mise en sécurité AS. Cela suppose que le contexte AS soit conservé au niveau du terminal UE et de la station de base. La R.13 propose une procédure de suspension/reprise de la connexion RRC lorsque le mobile passe de l’état RRC_CONNECTED à l’état RRC_IDLE.

Figure 2 : L’optimisation du coeur de réseau

Sur l’interface LTE, l’optimisation CIoT EPS Optimization permet de transporter les données sur la couche RRC. Le MME peut ensuite transférer les données vers le plan de transport SGW ou l’entité SCEF (Service Capability Exposure Function).

La R.14 introduit les spécifications à mettre en oeuvre pour le 5G MTC.

Figure 3 : Les améliorations proposées de la spécification R.10 à la R.14

La transmission EDT

Pour réduire la signalisation, la transmission EDT (Early Data Transmission [1]) propose de transmettre les données dans un message RRC au cours de la procédure d’accès aléatoire (RACH EDT). On distingue la transmission CP-EDT s’appuyant sur l’optimisation du plan de contrôle CP-EDT (sans chiffrement) de l’optimisation du plan utilisateur UP-EDT (avec chiffrement).

L’inconvénient de la procédure EDT est la transmission du message sur le canal de contrôle commun. Celle-ci est donc interférée par les demande d’accès aléatoire pouvant simultanément avoir lieu sur les mêmes bandes de fréquences.

La transmission UP-EDT est :

    • soit à l’initiative du terminal (Mobile Originated MO-EDT) spécifiée dans la R.15
    • soit à destination du terminal (Mobile Terminated MT-EDT) spécifiée dans la R.16.

La transmission EDT a été proposée dans la R.15 pour optimiser la transmission de messages courts lors de la procédure d’accès aléatoire. Au cours de cette procédure, le mobile reste à l’état RRC_IDLE sans contexte AS (CP EDT – Contol Plane EDT) ou en ayant conservé le contexte AS (UP EDT – User Plane EDT). A l’issue de la demande d’accès aléatoire, la transmission EDT étant finalisée, le mobile rester à l’état RRC_IDLE. Si d’autres données doivent être émises ou reçues, le terminal passe à l’état RRC_CONNECTED.

Dans ce cas, le premier paquet est transmis selon la procédure EDT, les autres paquets seront transmis de manière traditionnel.

La transmission PUR (Preconfigured Uplink Resource) consiste à pré-configurer les ressources du lien montant (UL) au cours d’une première connexion radioélectrique (RRC_CONNECTED). Cela signifie que la transmission PUR nécessite qu’en amont le terminal ait été dans l’état RRC_CONNECTED afin de recevoir la pré-configuration désirée.

La transmission PUR est utilisable par le terminal à l’état RRC_IDLE sans nécessité de procédure d’accès aléatoire mais en ayant conservé un contexte AS et l’allocation UL.

Ensuite, lorsque le mobile est en mode de veille, il peut utiliser les ressources qui lui sont réservées pour transmettre ses données sans avoir à mettre en œuvre la procédure d’accès aléatoire

Sur un cœur de réseau 5GC, la 3GPP propose un nouvel état radioélectrique du mobile nommé RRC_INACTIVE dédié aux terminaux IoT.

Le cœur de réseau 5GC pouvant être connecté à l’interface radioélectrique 4G E-UTRA et 5G-NR, l’état RRC_INACTVE s’appliquera à l’UE sur chacune des interfaces.

La transmission SDT (Small Data Transmission) est une procédure permettant de transmettre des petites quantités de données entre un terminal UE et le cœur de réseau 5GC en passant soit par l’accès radioélectrique 4G E-UTRA ou l’accès radioélectrique 5G-NR lorsque le terminal UE reste à l’état RRC_INACTIVE. La transmission SDT peut se faire sur l’interface E-UTRA comme sur l’interface 5G-NR.

La transmission non SDT correspond à la transmission traditionnelle de données entre un UE et le cœur de réseau 5GC via l’établissement de bearers lorsque l’UE est à l’état RRC_CONNECTED.

La transmission SDT sur l’interface 5G-NR a été introduite dans la spécification R.16 sous le nom NR SDT. La spécification R.17 propose deux technologies nommées RA-SDT (RACH SDT) et CG-SDT (Configured Grant SDT) lorsque le mobile est à l’état RRC_INACTIVE.

Figure 4 : Les types de transmissions IoT sur les réseaux 4G et 5G

[1] Andreas Höglund, Dung Pham Van, Tuomas Tirronen, Olof Liberg, Yutao Sui, and Emre A. Yavuz, “3GPP Release 15 Early Data Transmission”, 2018, IEEE Communications Standards Magazine ( Volume: 2, Issue: 2, JUNE 2018), p90-96, https://doi.org/10.1109/MCOMSTD.2018.1800002

Part 1 : Interface Radioélectrique 5G – Trames, numérologies et allocation de ressources

Extrait du livre : NG-RAN et 5G-NR : L’accès radio 5G et l’interface radioélectrique – sortie prévue juillet 2021

A l’instar de la 4G, l’interface radioélectrique 5G-NR utilise la modulation OFDM puisque celle-ci se révèle être la plus efficace dans le cas des transmissions multi-trajets (propagation en champs libre).

La modulation OFDM est une modulation multi-porteuses orthogonales, elle transmet un bloc de données binaires sur un grand nombre de porteuses en même temps. On définit ainsi le domaine fréquentiel de la transmission 5G par la largeur de sa bande de fréquence, c’est-à-dire par le nombre de sous-porteuses utilisées multiplié par l’espacement entre sous-porteuses.

L’orthogonalité se traduit par la durée de la transmission d’un symbole qui est inversement proportionnelle à l’espacement entre sous-porteuses. Ainsi, si les sous-porteuses sont espacées de 15 kHz, la durée de la transmission d’un symbole est de 66,67 µs (1/15 kHz).

Figure 1 : La transmission OFDM

Le bloc de données à transmettre est une suite binaire. La modulation OFDM permet de faire une modulation M-QAM sur chacune des porteuses.

A titre d’exemple, pour une modulation 64-QAM, 6 bits sont modulés par sous-porteuse. Les 6 bits forment un symbole.

Une station de base 5G peut moduler au plus 3300 sous-porteuses. Si les sous-porteuses sont espacées de 30 kHz alors la largeur de bande 5G est de 99 MHz et la durée d’un symbole est de 33,33 µs.

Ainsi, si la station de base transmet le bloc de données sur 3300 sous-porteuses simultanément, alors dans le cas d’une modulation 64-QAM, la station de base gNB pourrait potentiellement transmettre 3300*6 = 19 800 bits pendant la durée d’un symbole de 33,33 µs.

Si le bloc de données à transmettre est supérieur à 19 800 bits, alors la station de base va émettre les bits restants sur le(s) symbole(s) suivant(s) (33,33 µs suivante).

La modulation OFDM est donc une modulation qui exploite le domaine fréquentiel (nombre de sous-porteuses) et le domaine temporelle (durée d’un symbole).

Pour la 5G, on définit :

  • dans le domaine fréquentiel, un bloc de ressource RB (Resource Bloc) qui correspond à 12 sous-porteuses contiguës ;
  • dans le domaine temporel, un slot correspond à 14 symboles consécutifs.

Afin d’organiser la transmission de données, et synchroniser les récepteurs, les transmissions en liaison descendante et montante sont organisées en trames d’une durée de 10 ms, chacune est découpée en dix sous-trames de 1 ms. Chaque trame est divisée en deux demi-trames de taille égale à cinq sous-trames :

  • la demi-trame 0 est composée des sous-trames 0 à 4 ;
  • la demi-trame 1 est composée des sous-trames 5 à 9.

Pour l’interface LTE, la sous-trame est composée de deux intervalles de temps (slot). Attention, la notion de slot en 4G est différente de la notion de slot en 5G : un slot LTE correspond à 7 symboles OFDM consécutifs (trame normale) de durée 0,5 ms. La valeur de l’intervalle de temps de transmission 4G-TTI (Transmission Time Interval) correspond à la durée de la sous-trame et a une valeur fixe égale à 1 ms car l’espacement entre sous-porteuse est de 15 kHz.

Pour l’interface NR, le slot est composé de 14 symboles OFDM consécutifs (trame normale).  La valeur de l’intervalle de temps de transmission 5G-TTI correspond à la durée d’un slot. La valeur 5G-TTI dépend de l’espacement entre les sous-porteuses (tableau 1).

Tableau 1 : La structure de la trame temporelle

L’espacement entre sous-porteuses SCS (SubCarrier Spacing) est défini par la formulation suivante :

SCS=2µ*15 kHz, avec µ la numérologie.

Si µ=0, l’espacement est de 15 kHz, si µ=1 l’espacement est de 30 kHz, … Dans la suite, on parlera de numérologie.

1) La grille de ressources

 

Figure 2 : La grille de ressources

Un élément de ressource RE (Resource Element) constitue la plus petite unité pouvant être attribuée à un signal de référence (figure 1). L’élément de ressource RE correspond à un symbole OFDM dans le domaine temporel, et à une sous-porteuse dans le domaine fréquentiel. Il est ainsi repéré par la paire (k,l), k représentant l’indice de la sous-porteuse et l, l’indice du symbole OFDM dans le domaine temporel par rapport à un point de référence relatif.

Le bloc de ressource RB (Resource Block) correspond à une allocation de N=12 sous-porteuses contiguës (figure 1). A la différence de la 4G, le bloc de ressource RB 5G correspond à une allocation fréquentielle.

La grille de ressources est une allocation de ressources tempo-fréquentielles correspondant aux ressources d’un port d’antenne. Elle est constituée d’un ensemble de symboles par sous-trame (cf. tableau 2) dans l’espace temporel et d’un ensemble de sous-porteuses contiguës dans le domaine fréquentiel. La grille de ressources est composée d’au plus 3300 sous-porteuses et elle est transmise sur chaque sens de transmission et sur chaque port d’antenne.

Table 2 : Numérologie et nombre de symboles par sous-trame

Pour mieux comprendre la table 2, nous allons présenter la numérologie dans le domaine temporel sur la figure 3.

Figure 3 : La trame temporelle 5G-NR

Une trame 5G est définie par une durée de 10 ms. La trame 5G est découpée en 10 sous-trames d’une ms. Chaque sous-trame est composé de slots. Le nombre de slot par sous-trame dépend de l’espacement entre sous-porteuses (table 2 : numérologie).

 

[0] Extrait du livre : NG-RAN et 5G-NR : L’accès radio 5G et l’interface radioélectrique

Cours 2 – Niveau Master (Chap 1- Part 1)

Les Modes de transmission

2.1. Principe Général

Le signal reçu par une antenne est déformé par le canal de propagation, c’est-à-dire par l’environnement qui sépare l’antenne d’émission à l’antenne de réception. D’une part, le canal atténue la puissance du signal émis en fonction de la distance, mais d’autre part, les transmissions sur le canal mobile dans des environnements plutôt urbains (présence de nombreux bâtiments) ou intérieurs (murs, meubles,. . .) provoquent des multi-trajets (équivalent à de l’écho) ce qui génère en réception en évanouissement du signal.

Figure 2.1. Atténuation du signal et évanouissements

On distingue :

  • les évanouissements à moyenne échelle, dont l’origine est la présence de zones d’ombre, influent sur la distribution de la puissance moyenne reçue. Cette puissance est sensible aux paramètres suivants : Hauteur des antennes, fréquence du signal et topologie de l’environnement (immeubles, relief…).
  • les évanouissements à petites échelles provoquent une variation rapide du signal reçu. Cette variation est importante sur des faibles distances (il suffit de déplacer l’UE de quelques centimètres pour gagner ou perdre plusieurs dB), sur des faibles temps (en fonction du temps de cohérence du canal) et sur des faibles bandes de fréquence (en fonction de la fréquence de cohérence du canal). Les principales sources d’évanouissement sont les perturbateurs entre l’émetteur et le récepteur créant différentes interactions sur l’onde comme la réflexion, la réfraction, la diffraction,  la diffusion.

Figure 2.2. Propagation en milieu exterieur (urbain) : Outdoor

Comme le montre la figure 2.1, les multi-trajets provoquent en réception une sommation constructive ou destructive du signal. Pour contrer les effets du canal, le récepteur chercher à estimer le canal, c’est-à-dire à lui donner une représentation mathématique : un multi-trajet est un retard et une atténuation. Si le récepteur est en mesure de représenter le canal de propagation par une fonction mathématique (comme un filtre à réponse impulsionnel fini), il suffit de calculer la fonction inverse du canal pour récupérer le signal émis.

L’estimation du canal est simplifiée par la connaissance d’une séquence d’apprentissage aussi nommée séquence pilote : l’émetteur émet une séquence connue par le récepteur. Ce dernier compare le signal reçu avec le signal connu pour estimer le canal. Le LTE utilise des signaux de références, que nous verrons ultérieurement. Il existe d’autres techniques pour identifier le canal de manière aveugle.

Le modèle du canal n’est cependant pas inversible et de plus, est sujet au bruit. Afin de remettre en forme les signaux modulés qui ont été modifiés par le canal de propagation, on cherche à estimer le modèle inverse du canal. Il s’agit de l’égalisation du canal.

Il existe plusieurs techniques d’égalisation comme la technique de retour à zéro (ZF : Zero Forcing) qui a pour objectif de converger vers 0 l’interférence inter symbole (aux instants de décision) ou la technique MMSE (Minimum Mean Square Error) qui a pour objectif d’estimer le canal pour avoir une puissance d’erreur moyenne la plus faible possible entre les mesures et le modèle.

Les imperfections du canal influent principalement sur deux critères de performances. Les critères de performance se nomment KPI  (Key Parameter Indicator). Le premier indicateur est la capacité qui s’exprime par le débit maximal supporté par le canal (notion de Shannon). Le deuxième indicateur est la probabilité d’erreur (TEB): Il s’agit de prédire la probabilité que le symbole ou le bit émis soit faux. Plus cette probabilité est faible et meilleur est le système.

La technique du MIMO (Multiple Input Multiple Output) permet d’améliorer le KPI. Le MIMO est basé sur plusieurs antennes en émission et plusieurs antennes en réception.

Figure 2.3. Schéma MIMO

On représente le canal de propagation par une matrice H de dimension, chaque coefficient i,j de la matrice représente le gain du canal de l’antenne i vers l’antenne j :

H étant une matrice rectangulaire, la diagonalisation de la matrice H se fait par la méthode de décomposition en valeurs singulières ce qui permet d’écrire H sous la forme suivante :

Avec U , une matrice unitaire de dimension nR x nR., \Sigma la matrice diagonale de dimension nR x nT à coefficients \lambda_k réels positifs ou nul et  V* la matrice adjointe à V, V matrice unitaire de dimension nT x nT. Une matrice unitaire est une matrice telle que UU*=U*U=I, I est la matrice identité.

La matrice \Sigma représente le lien du canal entre l’antenne d’émission i et l’antenne de réception i, on se ramène donc à un système équivalent à n SISO, avec n le rang de la matrice H. Le traitement du signal consiste donc à précoder le signal d’entrée par une matrice V et à coder le signal reçu par les nR antennes par la matrice adjointe de U.

On peut aussi calculer les coefficients de la matrice H \lambda_k à partir de la matrice carrée H.H*. Dans ce cas, la diagonalisation de la matrice carrée H.H* est constitué du carrée des coefficients de la matrice H \lambda_k.

2.1.1 Diversité spatiale : Réduire le TEB

Pour combattre ces fluctuations rapides du signal et réduire le TEB (ce qui revient à dire améliorer la robustesse face au canal), une solution complémentaire à l’égalisation consiste à introduire de la diversité. La diversité est une technique utilisée pour combattre l’évanouissement. Le principe consiste à transmettre plusieurs fois le même signal soit à des instants différents (diversité temporelle), soit sur des bandes de fréquences différentes (diversité fréquentielle), soit avec une polarisation différente (polarisation verticale ou horizontale de l’onde),  soit sur des points d’émission différents (diversité spatiale).

La diversité spatiale nécessite au moins deux antennes à l’émission, on parle alors de système MISO (Multi Input Single Output) pour la diversité de transmission ou deux antennes en réception, on parle alors de système SIMO (Single Input Multiple Output) pour la diversité en réception. Mais on peut aussi apporter de la diversité spatiale en émission et en réception avec un système composé de plusieurs antennes à l’émission et plusieurs antennes à la réception. On parle alors de système MIMO (Multi Input Multiple Output).

A titre d’exemple, pour améliorer le signal reçu par deux antennes en réception, il est possible de combiner le signal reçu de chaque antenne comme le montre la figure 2.4 ou plus simplement de sélectionner l’antenne dont le SNR est le meilleur.

Figure 2.4. Recombinaison du signal reçu par deux antennes : Diversité en réception

Le signal transmis étant unique, la recombinaison au niveau du récepteur ne peut être efficace que si les deux signaux reçus ne sont pas corrélés.

Lorsqu’on utilise plusieurs antennes, que ce soit à l’émission ou à la réception, il est nécessaire de séparer les antennes d’une distance environ égale à une demi-longueur d’onde (de l’ordre de 0.45  à 0.5 de la longueur d’onde). En respectant cette contrainte spatiale, le trajet subi par chacune des ondes est indépendant du trajet des autres ondes.  Ainsi, le signal reçu par l’antenne est affecté par un bruit gaussien et par des évanouissements différents car chaque signal reçu aura subit des trajets multiples différents.

Cependant, transmettre des données simultanément dans la même bande de fréquence génère des interférences en réception. Il est donc nécessaire d’apporter un traitement aux données avant l’émission afin d’orthogonaliser les flux.

A titre d’exemple, pour un système MIMO 2×2, Alamouti propose un système de codage spatio-temporelle : Soit s1, et s2 deux symboles à transmettre pendant une période 2.T. Au lieu de transmettre s1 sur l’antenne 1 et s2 sur l’antenne 2, on transmet :

  • Sur l’antenne 1 : s1 pendant T et -s2* pendant T ( est le complexe conjugé de  s2)
  • Sur l’antenne 2 : s2 pendant T et s1* pendant T

La représentation mathématique est la suivante :

c2 est une matrice orthogonale (en considérant les vecteurs u1 et u2 extraits de chaque ligne ou de chaque colonne, le produit scalaire  est nul).

Le récepteur estime le canal de propagation et recombine les échantillons reçus. Les signaux recombinés y1 et y2 ne dépendent respectivement que de s1 et s2. Le code d’Alamouti découple donc les symboles mais en contrepartie, on ne gagne pas en débit puisqu’on transmet les deux symboles sur un instant 2T. Le code d’Alamouti (nommé aussi STBC : Space-Time Block Code) permet donc de faire de la diversité spatiale en émission.

Tarok a généralisé le code d’Alamouti pour un système de dimension supérieure à 2×2 (nommé OSTBC : Orthogonal STBC) et a proposé un autre type de code prenant en compte la modulation sur les antennes émettrices. Il s’agit des codes spatio-temporels en Treillis ou Space-Time Trellis Code (STTC).

Le synoptique est le suivant :

Figure 2.5. Diversité spatiale par le code d’Alamouti (STBC) : Diversité en émission

2.1.2 Multiplexage spatiale en boucle ouverte : Augmenter la capacité

Au lieu d’exploiter la diversité du signal en transmettant la même information, il est possible de découper l’information en plusieurs flux et de transmettre chaque flux sur une antenne à l’émission vers une antenne en réception. Ainsi, en exploitant les deux réseaux d’antennes à l’émission et à la réception de manière coopérative, il est possible d’augmenter le débit de transmission (la capacité). On parle alors de multiplexage spatial : la largeur de bande est inchangée mais l’efficacité spectrale est augmentée par la dimension des antennes (exemple d’un système MIMO 4×4 : 4 antennes à l’émission et 4 antennes à la réception). Le multiplexage spatial peut être mono-utilisateur, on parle de SU-MIMO (Single User MIMO) ou MU-MIMO (multi-utilisateur). Dans le cas du SU-MIMO, plusieurs flux d’informations sont transmis sur les mêmes ressources en temps et en fréquence vers un seul utilisateur. Dans le cas du MU-MIMO plusieurs flux sont transmis simultanément sur les mêmes ressources en temps et en fréquence mais pour des utilisateurs différents.  On peut aussi faire du MU-MIMO en affectant plusieurs antennes par utilisateurs, par exemple pour deux  2 UE possédant 2 antennes et un eNb qui possède 4 antenne peut transmettre en même temps et sur la même bande de fréquence 2 flux vers l’UE 1 sur deux antennes différentes et 2 flux vers l’UE2 sur les deux antennes restantes.

Le SU-MIMO améliore le débit de l’utilisateur, le MU-MIMO améliore la capacité de l’eNb.

Au niveau du récepteur, le détecteur optimal est basé sur le maximum de vraisemblance (ML) lequel nécessite une charge de calcul élevé lorsque le nombre d’antennes et la taille de la constellation sont grands. Il existe d’autres algorithmes sous-optimaux basés sur le ML et le codeur à retour de décision V-BLAST : le symbole de l’émetteur le plus favorisé (possédant le meilleur TEB suivant le critère considéré) est démodulé en premier. Sa contribution au vecteur reçu r est ensuite annulée, ce qui augmente le SNR sur les autres émetteurs (à chaque bonne décision). Cette étape est répétée jusqu’au dernier émetteur, le moins favorisé.

Le débit théorique maximum est alors défini par la formule suivante :

2.1.3 Connaissance du canal à l’émission : CSI (Channel State Information)

Les deux techniques présentées précédemment s’appuyait sur la connaissance du canal (CSI) au niveau du récepteur uniquement. Nous allons maintenant exploiter la connaissance du canal de transmission au niveau de l’émetteur : le récepteur est en mesure d’estimer le canal à partir d’une séquence d’apprentissage émise par l’émetteur. Si le rapport de mesure est transmis à l’émetteur, ce dernier peut alors combiner différemment les symboles à émettre sur les antennes afin de répartir la puissance selon une stratégie bien précise. Cette combinaison est réalisée par un précodeur linéaire à l’émission.

2.1.3.1 Multiplexage spatial avec connaissance du canal de propagation

On parle dans ce cas de multiplexage spatial en boucle fermée (closed loop spatial multiplexing), pour laquelle l’UE calcule par la méthode de décomposition singulière la matrice de précodage V et la matrice de post-traitement U. La matrice de précodage doit être transmise à l’émetteur (retour d’information). Le récepteur couple le traitement par une méthode d’égalisation ZF ou MMSE.

Ainsi, soit x le signal à émettre, le signal précodé est Vx. Le signal reçu est H.(Vx) soit par décomposition on obtient :

Après traitement au niveau du récepteur, le signal est \Sigma.x


Figure 2.6. Principe multiplexage MIMO

Le nombre de réel positif  non nul \lambda_k correspond au rang de la matrice H.H* appelé RI : Rank Indicator. Ce nombre permet à l’émetteur de connaître le nombre de couche spatiale indépendant pouvant être utilisé pour cet UE.

Afin d’optimiser le débit, la méthode de WaterFilling permet de répartir la puissance totale  vers les différentes antennes en émission. Cela consiste à transmettre plus de puissance aux canaux les plus dégradés afin d’obtenir un rapport signal sur bruit équivalent au niveau du récepteur en résolvant l’équation suivante :

La puissance est répartie sur chaque antenne selon la formule suivante :

avec la contrainte  telle que :

2.1.3.2 Diversité Spatiale avec connaissance du canal de propagation : Réduire les interférences (Beamforming)

La technique de beamforming SDMA (Space Division Multiple Access) correspond à un filtre spatial directif pour favoriser le gain dans une direction souhaitée et atténuer la puissance de l’onde dans les directions non souhaitées. Pour le contrôle et la formation des diagrammes de rayonnement, on applique à chaque antenne une pondération correspondant aux critères fixés comme la maximisation du gain dans une direction donnée, ou la maîtrise du niveau des lobes secondaires.

La pondération consiste à réaliser une multiplication par des coefficients complexes, des signaux à émettre sur chaque élément du réseau d’antennes. Ce calcul est similaire au précodage effectué pour le multiplexage spatial, en remplaçant la matrice de précodage par une matrice de Beamforming nommée B et s’appuie également sur la décomposition en valeur singulière de la matrice , et de la méthode d’égalisation ZF ou SMMSE (Successive Minimum Mean Square Error)

Pour calculer la matrice de pré-codage, le réseau d’antennes en réception va chercher à localiser l’émetteur, selon la technique DoA – Direction of arrivals. Au lieu d’estimer la matrice H de manière fréquentiel, le récepteur est un spectre dont les pics identifient les angles d’arrivés (on mesure la puissance du signal en modifiant l’angle d’orientation, le spectre est donc une fonction de l’angle).

L’algorithme du maximum de vraisemblance peut être utilisé pour améliorer la résolution des angles d’arrivés. Parmi les pré-codeurs, il existe un pré-codeur max SNR aussi appelé précodeur Beamforming dont l’objectif est d’orienter le signal dans une direction donnée (réduire le TEB et les interférences).

2.1.4 Conclusion

Le traitement des données s’alourdit en émission et en réception à cause de  l’augmentation des dimensions mais grâce à l’augmentation de la puissance de calcul embarquée, la miniaturisation des composants, la technologie des antennes …, il est désormais possible de commercialiser des systèmes MIMO 8×8.

Le MIMO pour un utilisateur permet d’augmenter la capacité de transmission mais cette capacité est malgré tout limitée par le nombre d’antenne de l’UE (en général, l’UE à moins d’antenne que l’eNb). Une autre évolution très importante est le MU-MIMO ou l’eNb génère plusieurs flux simultanément à partir de plusieurs d’antennes d’émission vers plusieurs UE. On parle de MU-MIMO

 

 

 

Cours IUT – Chap 1 (Part 2)

L’architecture du réseau de mobiles 4G

Suite de l’article précédent

1.2. L’architecture protocolaire

L’architecture protocolaire du réseau EPS est décrite à la figure 1.7 pour le plan de contrôle et à la figure 1.8 pour le plan utilisateur.

Figure 1.7. L’architecture protocolaire du plan de contrôle (1)

Figure 1.8. L’architecture protocolaire du plan utilisateur (1)

Le RAN (Radio Access Network) est l’interface entre le mobile UE et la station de base eNB. Le RAN fournit un ou plusieurs supports (bearers) radio pour transmettre les données (plan de transport) et des supports radios pour transmettre la signalisation. Les données sont transportées dans des DRB (Data Radio Bearer) et la signalisation dans des SRB (Signaling Radio Bearer).

La norme standardise les interfaces entre chaque entité de façon à pouvoir construire un réseau indépendant des équipementiers.

La signalisation NAS est transmise entre le mobile UE et l’entité MME via la station de base eNB. La signalisation NAS intervient dès que le mobile UE se connecte au réseau dans la procédure d’authentification.

1.2.1 L’interface LTE-Uu

Les couches de protocoles radios situées au niveau de la station de base eNB assument les fonctionnalités suivantes :

  • Couche RRC (Radio Resource Control) est responsable de toute la signalisation entre le mobile UE et la station de base eNB. Cela comprend les messages de configuration de la connexion, les rapports de mesures, les reconfigurations RRC (commande handover). Afin de simplifier les états du mobile, ce dernier est soit en mode de veille (RRC idle) soit en mode connecté au réseau (RRC Connected).
  • Couche PDCP (Packet Data Convergence Protocole) gère la sécurité (chiffrement des données et des commandes et intégrité des commandes), ainsi que la compression d’entête. Le protocole PDCP gère aussi la livraison en séquence des messages RRC et des paquets IP et la reprise des trames PDCP perdues ainsi que la suppression des trames dupliquées lors du HandOver.
  • Couche RLC (Radio Link Protocol) gère la retransmission de trames en cas d’échec sur la couche physique et le séquencement des trames. La fonction de retransmission du RLC est désactivée pour certains services comme la VoLTE pour ne pas retarder la transmission. Dans ce cas, le RLC se limite à ré-ordonner les paquets.

Le protocole RLC opère dans trois modes :

  • le mode avec acquittement AM (Acknowledged Mode) ;
  • le mode sans acquittement UM (Unacknowledged Mode) ;
  • le mode transparent TM (Transparent Mode) pour lequel aucune en-tête n’est rajoutée aux données.

La couche RLC effectue les opérations suivantes :

  • la retransmission en cas d’erreur via le mécanisme ARQ (Automatic Repeat reQuest), uniquement pour le mode avec acquittement ;
  • la concaténation, la segmentation et le réassemblage des trames PDCP, dans le mode avec ou sans acquittement ;
  • la resegmentation éventuelle des trames PDCP, dans le mode avec acquittement, lors d’une retransmission de la trame RLC ;
  • la remise en séquence des données reçues, dans le mode avec ou sans acquittement ;
  • la détection des données dupliquées, dans le mode avec ou sans acquittement.

Le couche MAC (Medium Access Control) couvre les fonctions relatives aux contrôles des transmissions et réceptions discontinues, la gestion du Timing Advance, la gestion d’ordonnancement des paquets et de la retransmission (TTI Bundling), la gestion du buffer du mobile UE et la gestion de la boucle de puissance PHR  (Power Headroom Reporting).

Le couche MAC assure les fonctions suivantes :

  • le multiplexage des canaux logiques provenant de différentes instances RLC dans un bloc de transport ;
  • l’allocation de la ressource via un mécanisme d’ordonnancement ;
  • la gestion de la retransmission en cas d’erreur via le mécanisme HARQ (Hybrid Automatic Repeat request). La méthode HARQ n’est pas applicable pour les transmissions en broadcast;
  • la gestion de la procédure d’accès aléatoire.

Le canal logique est défini par le type d’information à transmettre :

  • BCCH : Broadcast Control Channel transmet les informations systèmes (SI).
  • CCCH : Common Control Channel transmet les informations de contrôles.
  • PCCH : Paging Control Channel permet de notifier l’UE d’une session entrante.
  • DCCH : Dedicated Control Channel transporte les informations de contrôles d’établissement de session.
  • DTCH : Dedicated Transport Channel transporte les données utiles.

D’autres canaux logiques de Multicast et de broadcast existent en complément à liste ci-dessus ainsi que des canaux physiques permettant la synchronisation des mobiles UE :

  • PSS/SSS : Primary/Secondary Synchronization Signal
  • RS : Reference Signal

La couche MAC multiplexe les canaux dans des blocs de transports TB (Transport Bloc). A chaque TTI (Transmission Time Interval), un ou plusieurs TB sont transmis sur l’interface radio LTE-Uu. La couche MAC de la station de base eNB gère l’ordonnancement des TB sur le sens montant et descendant toutes les 1 ms (TTI).

La couche physique de l’interface LTE-Uu met en œuvre les fonctions suivantes : le code de correction et de détection d’erreurs, le multiplexage des canaux physiques, la modulation et l’amplification du signal. Nous détaillerons la structure de la trame radio dans le chapitre 2.

1.2.2. L’architecture protocolaire du cœur du réseau

L’objectif du cœur réseau est de monter un tunnel DATA dont la qualité de service dépend de l’application et du forfait de l’utilisateur. La signalisation 4G correspond au plan de contrôle et gère entre autre la mise en place de support (bearers).

L’établissement ou le ré-établissement du tunnel est prise en charge par le plan de contrôle.

Un tunnel par défaut est établi lorsque le mobile UE s’allume (lors de la procédure d’attachement). L’opérateur authentifie le mobile UE et vérifie ses droits. Cela nécessite un échange de signalisation entre l’entité MME et l’entité HSS. L’interface S6a est le point de référence entre les entités MME et HSS. Cette interface supporte la signalisation DIAMETER. Le protocole DIAMETER permet à l’entité MME de récupérer les données d’authentification et le profil de service du mobile.

Une fois authentifié, le client pourra exploiter le réseau opérateur dans le cadre imposé par son forfait. L’opérateur mesure la volumétrie consommée en temps réel par le client. En cas de dépassement de forfait, l’entité PCRF limite le trafic (fair use) au niveau de la passerelle de sortie PGW. L’interface Gx est le point de référence entre l’entité PCRF et la fonction PCEF de l’entité PGW Cette interface supporte la signalisation DIAMETER. Le protocole DIAMETER permet à l’entité PGW de récupérer les règles à appliquer sur le support et d’informer l’entité PCRF de la terminaison de la session sur le réseau EPS

Lorsque la station de base eNB reçoit une requête pour une session Data de la part du mobile UE, il transmet cette requête à l’entité MME via l’interface S1-MME.  L’interface S1-MME est le point de référence entre les entités MME et eNB pour la signalisation. Cette interface supporte la signalisation S1-AP (Application Part).

L’entité MME traite la demande et transmet l’ordre de création d’un contexte pour gérer le tunnel à l’entité SGW puis à l’entité PGW. L’interface S11 est le point de référence entre les entités MME et SGW. Cette interface supporte la signalisation GTPv2-C (GPRS Tunnel Protocol Control).

Le protocole S1-AP assure les fonctions suivantes : l’établissement du contexte du mobile, l’établissement, la modification et la libération du support E-RAB (EPS Radio Access Bearer) construit entre le mobile et l’entité SGW, la gestion du handover, le paging.

Le protocole GTPv2-C supporte les fonctions suivantes : la gestion du contexte du mobile et du support S1, la notification de données entrantes lorsque le mobile est en veille.

L’interface S1-U est le point de référence entre les entités eNB et SGW. Cette interface supporte la tunnelisation GTP-U (GPRS Tunnel Protocol User) du paquet IP du flux.

L’interface S5 est le point de référence entre les entités SGW et PGW. Cette interface supporte la signalisation GTPv2-C pour le plan de contrôle, et la tunnelisation GTP-U du paquet IP du flux.

L’interface S8 est le point de référence entre l’entité SGW du réseau visité et l’entité PGW du réseau nominal. Cette interface supporte les mêmes protocoles que l’interface S5.

Dans le cas de Handover, d’une cellule vers une autre cellule, le trafic est routé via l’interface X2. L’interface X2 est le point de référence entre deux entités eNB. Elle est activée lorsque les deux entités eNB appartiennent au même groupe.

L’interface X2 supporte la signalisation X2-AP pour le plan de contrôle (figure 1.9), et la tunnelisation GTP-U, pour le paquet IP du flux, lorsque le mobile change de cellule (figure 1.10).

Figure 1.9. L’architecture protocolaire sur l’interface X2: le plan de contrôle (1)

Figure 1.10. L’architecture protocolaire : le plan de trafic
lors d’une mobilité basée sur l’interface X2 (1)

Le tunnel établi entre les deux stations de base eNB est unidirectionnel (eNB source vers eNB cible). Il permet de transférer vers l’entité eNB cible les données de trafic reçu de l’entité SGW. Il est établi temporairement, pendant la durée du handover du mobile.

Si le handover nécessite un changement d’entité MME, la signalisation est transmise de l’entité MME source vers l’entité MME cible via l’interface S10. L’interface S10 est le point de référence entre les entités MME. Cette interface est utilisée lorsque le mobile change de groupe et que l’entité MME doit être relocalisée. Cette interface supporte la signalisation GTPv2-C.

Références

1 : Livre LTE-Advanced Pro

COURS IUT Chapitre 1 (Part 1)

Chapitre 1 : L’architecture du réseau de mobiles 4G

1-1. L’architecture fonctionnelle

Le réseau de mobiles 4G a été défini dans la Release.8 sous le nom EPS (Evolved Packet System).

L’architecture fonctionnelle du réseau EPS est décrite à la figure 1.1. Elle se découpe en deux sous réseaux : un cœur réseau EPC (Evolved Packet Core) et un réseau d’accès radioélectrique E-UTRAN (Evolved Universal Terrestrial Radio Access Network).

Figure 1.1. L’architecture fonctionnelle du réseau EPS (1)

Le réseau d’accès E-UTRAN assure la connexion des mobiles et la réservation des ressources radio entre le mobile UE  (User Equipment) et l’entité eNB (evolved Node Base station) sur une bande de fréquences (LTE) ou sur plusieurs bandes de fréquences (LTE-Advanced).

Le cœur de réseau EPC interconnecte les réseaux d’accès, fournit l’interface au réseau de données PDN (Packet Data Network) et assure l’attachement des mobiles, l’autorisation d’accès au service et l’établissement des supports (bearers).

L’architecture protocolaire s’appuie sur le protocole IP  (Internet Protocol), chaque entité dispose d’une ou plusieurs adresses IP. Les entités sont connectées entre elles par un réseau de transport (backhaul) constitué de routeurs permettant de faire des marquages de QoS (Quality Of Service). Le protocole de routage utilisé est le MPLS (MultiProtocol Label Switching ) et la QoS est gérée par étiquetage d’un champ d’entête IP nommé DSCP (DiffServ Code Point).

Figure 1.2. Le réseau EPS et le backhaul

1.1.1. L’entité eNB

L’entité eNB est la partie visible du réseau de l’opérateur. L’eNB est composé :

  • d’une ou plusieurs antennes : l’antenne est l’élément passif qui transforme un signal électrique en une onde électromagnétique et réciproquement ;
  • d’un ensemble d’émetteurs/récepteurs nommés TRX modulant le signal numérique en signal analogique vers l’antenne et inversement. Les modules TRX gèrent aussi la compensation du signal modulé ;
  • d’amplificateur de puissance. Le signal issu de l’émetteur est amplifié ;
  • d’une unité de traitement en bande de base BBU (Base Band Unit).

Le système actif est généralement situé dans un local technique constitué :

  • d’une alimentation et des batteries de secours (Power Distribution Module)
  • d’un système de ventilation (Fan Control Module) ;
  • d’un contrôleur (Control and Maintenance Module) ;
  • d’élément de transmission (Transceiver Module) ;
  • des connecteurs d’antennes (Combiner Distribution Unit).

Le local technique est soit positionné au pied de l’antenne, soit dans un abri (shelter) sur le toit (rooftop). La figure 1.3 représente la structure matérielle de l’entité eNb dans laquelle se trouvent l’unité BBU, et le système actif.

Figure 1.3. La description matérielle d’une station de base (2)

Depuis quelques années, on voit apparaître un boitier nommé unité RRU (Remote Radio Unit) ou RRH (Remote Radio Head) proche de l’antenne.

L’unité RRU englobe les fonctions permettant de convertir le signal en bande de base vers un signal radio-fréquence (RF) et inversement.

L’unité RRU est donc composée des modules de transmissions TRX et des amplificateurs.

Figure 1.4. Le découpage BBU et RRU

On sépare ainsi la fonction de bande de base effectuée par l’unité BBU de la fonction Radio Fréquence. Sur la figure 1.4, le module RRU est logé près de l’antenne afin de supprimer l’amplificateur faible bruit TMA (Tower Mounted Amplifier).

L’unité BBU gère la couche physique, elle réalise la pré-modulation, le codage, l’allocation de ressource. L’unité BBU est constituée d’une carte contrôleur et d’une carte SDR (Soft Design Radio) dans un châssis. La carte contrôleur se raccorde à l’entité MME et à l’entité SGW (Serving Gateway) et la carte SDR est connectée au module RRU. La carte SDR (radio logicielle) permet de réaliser le traitement logiciel du signal pour la 2G/3G/4G. Ainsi, le même équipement peut gérer les différents accès radios, ce que réalise l’opérateur lorsqu’il fait évoluer (swap) ses équipements.

Le lien entre l’unité BBU et le module RRU s’appelle le réseau de transport fronthaul. En général, le lien est un câble optique standard nommé CPRI (Common Public Radio Interface). La technologie CPRI transporte les flux de données et la synchronisation entre deux entités : l’entité Radio Equipment (RE) qui correspond au module RRU et l’entité Radio Equipment Control (REC) qui correspond à l’unité BBU. Le rôle du RE est de construire la forme d’onde du signal radio, le REC génère le signal radio. Les données de plan de transport sont numérisées (I/Q) sur M

bits pour chaque secteur d’antenne et pour une seule porteuse (connu sous le nom de concept AC Antenna Carrier).

Il est ainsi possible de transférer différents types de signaux via le CPRI et de reconstruire la forme d’onde au niveau du RE (GSM, UMTS, WiMAX, LTE). Le débit du lien CPRI-1 est de 614.4 Mbps, légèrement inférieur au lien STM-4. La distance entre le RE et le REC peut être de 10 kms. Nativement, le CPRI supporte le multiplexage de 2 CPRI-1, nommée CPRI-2 (1228,8 Mbit/s).

Figure 1.5. REC – CPRI – RE

Prenons un exemple : si l’on suppose que le module RRU doit gérer 4 secteurs opérant chacun sur une bande MIMO 2×2 LTE de 20 MHz, alors il est nécessaire de transmettre 4 groupes (un groupe par secteur) de 2 AC (MIMO 2×2). Si la numérisation est sur M=15 bits par voies (I et Q), alors le débit est de  15*2* 8 AC =240 bits par Te, Te étant la période d’échantillonnage. Sachant que pour 20 MHz, la fréquence d’échantillonnage est de fe=30,72MHz alors le débit est de 7372.8Mbps. Une multi-trame est composée d’une trame de synchronisation et de 15 trames de données, le débit réel est donc de 16/15* 7372.8 soit 7864,32 Mbps. Enfin les données sont encodées par un codeur canal 8B/10B, le débit total est donc de 8/10*7864,32=9830,4 Mbps, ce qui correspond à un multiplexage de 8 CPRI-2.

Dans le cas d’une agrégation de porteuses sur 5 canaux (100 MHz) sur 4 secteurs, avec des antennes MIMO 8×8, le débit est alors multiplié par 20.

Il est également possible d’empiler  (stack) plusieurs unités BBU, chacune connectée à différents modules RRU créant ainsi un pool de cartes BBU (BBU centralization ou BBU Hosteling), afin d’améliorer la fiabilité du réseau d’accès radio. Il s’agit du Cloud RAN ou C-RAN. L’unité BBU n’est plus distribuée mais centralisée et connectée aux modules RRU par des modules de transports optiques CPRI.

 

Figure 1.6. La BBU centralisée

Après avoir présenté la partie matérielle, nous allons lister les fonctions de l’entité eNB.

L’entité eNB assure l’établissement du support radioélectrique DRB (Data Radio Bearer) sur lequel est transmis le trafic du mobile dans le sens montant (UL Uplink) et descendant (DL Downlink). Si le nombre de demandes de connexion est trop élevé, l’entité eNB gère la congestion (contrôle l’accès des mobiles UE sur l’entité eNB) en interdisant l’accès à la cellule pour des nouveaux mobiles UE.

L’entité eNB gère les ressources radio et l’attribution des ressources pour chaque utilisateur. Pour cela, l’entité eNB utilise les mesures effectuées par le mobile UE pour décider du déclenchement d’un changement de cellule en cours de session (handover). En plus de gérer la mobilité des utilisateurs en cours de session, les mesures permettent de réaliser un contrôle en puissance et d’assister l’entité eNB à ordonnancer les flux vers les mobiles UE (priorité des flux et gestion des débits entre chaque mobile UE).

Les données sont transmises sur le plan utilisateur (User Plane) et la signalisation est transmise sur le plan de contrôle (Control Plane). L’architecture du protocole radio est présentée dans le chapitre 1.2 (se référer aux figures 1.7 et 1.8).  La signalisation permet d’établir ou de ré-établir un  tunnel entre le mobile UE et le réseau de données PDN et de préparer les ressources (Accès radio, handover, …).

Le point de contrôle du réseau 4G est l’entité MME (Mobility Management Entity). L’entité eNB transfère la signalisation NAS (Non Access Stratum) du mobile UE vers l’entité MME et de l’entité MME vers le mobile UE via l’interface S1-MME. L’entité eNB effectue la sélection de l’entité MME du cœur de réseau à laquelle s’attache le mobile.

En qualité de point d’accès pour le plan de transport, l’entité eNB transfère les données de trafic provenant du mobile vers l’entité SGW (Serving Gateway), et celles provenant de l’entité SGW vers le mobile à travers un tunnel IP. Ce tunnel est défini par un identifiant d’acheminement nommé TEID  (Tunnel End Identifier) et d’un identifiant de la classe de service QCI (QoS Class Identifier). L’identifiant TEID et l’identifiant QCI sont nécessaire pour établir l’acheminement des données et la mise en œuvre du mécanisme d’ordonnancement des données. Ces informations forment un contexte et sont stockées au niveau de l’entité SGW et l’entité PGW (PDN Gateway). L’identifiant QCI permet de marquer les champs DSCP des paquets IP afin de différencier les services proposés par ordre de priorité et de garantir les débits pour certaines applications.

En termes de sécurité, les données entre l’entité eNB et le mobile UE sont chiffrées. La signalisation est également chiffrée et un contrôle d’intégrité permet d’éviter une attaque de type Man In the Middle.

1.1.2. L’entité MME

L’entité MME contrôle le droit d’accès des mobiles UE et les services accessibles pour chaque mobile UE dans le réseau de l’opérateur (PLMN Public Land Mobile Network).

Le droit d’accès au réseau (Home HPLMN ou Visité VPLMN) s’effectue via la procédure d’attachement. Lors de l’attachement, l’entité MME récupère le profil et les données d’authentification du mobile stockés dans l’entité HSS (Home Subscriber Server) et procède à l’authentification du mobile. Cette procédure permet au mobile UE d’authentifier le réseau sur lequel il se connecte et au réseau d’authentifier le mobile UE.

Si la double authentification aboutie, l’entité MME sauvegarde le contexte du mobile UE. Le contexte contient l’abonnement du profil du mobile UE (profil récupéré auprès du HSS) ainsi qu’un ensemble d’informations sur les capacités du mobile UE, la localisation du mobile UE, son identifiant, et les clés de sécurités dérivées.

Les capacités correspondent aux caractéristiques techniques (Information Element) du mobile UE (nombre d’antennes, débit maximum, … ) alors que le profil d’abonnement récupéré au niveau du HSS permet de définir l’accès aux services de l’utilisateur (service voix sur IP, accès Internet, applications objets connectés, …). Le MME récupère également les points d’accès APN (Access Point Name) permettant de déterminer la passerelle permettant d’atteindre le PDN spécifique.

Lors de l’attachement, l’entité MME enregistre l’identité de la zone de localisation TAI (Tracking Area Identity) du mobile et lui attribue l’identité temporaire GUTI (Globally Unique Temporary Identity) qui remplace l’identité privée IMSI (International Mobile Subscriber Identity). Le GUTI devient l’identifiant unique temporaire de l’UE. Le GUTI est composé d’un identifiant du PLMN/MME suivi d’un identifiant unique de l’UE sur le MME. A partir du GUTI, il est donc possible de retrouver le MME qui gère l’UE.

L’entité MME sélectionne l’entité SGW et à partir du point d’accès APN, l’entité MME contacte l’entité PGW. La signalisation émise par l’entité MME permet de créer une entrée supplémentaire à la table de contexte de l’entité SGW et de l’entité PGW. Cette table contient les informations concernant le tunnel par défaut (default bearer) entre le mobile UE et l’entité PGW.

Une fois le mobile UE attaché, l’entité MME contrôle l’établissement et le ré-établissement des tunnels (par défaut ou dédié) pour la transmission des données de trafic pour chaque mobile UE.

Le mobile UE contacte l’entité MME via une station de base eNB. Chaque station de base eNB est connectée à une ou plusieurs entités MME. On parle alors d’un groupe de MME (pool). Afin de gérer l’équilibrage de la charge des entités MME, chaque entité MME transmet une information de facteur de charge à la station de base eNB.  L’équilibrage de charge est donc réalisé par les entités eNB en fonction des informations émises par les entités MME.

En cas de mobilité, l’entité MME gère une liste de zones de localisation allouées aux mobiles, dans lesquelles le mobile, à l’état de veille, peut se déplacer sans contacter l’entité MME pour mettre à jour sa localisation. L’entité MME constitue le point d’ancrage du plan de contrôle à condition que le mobile ne change pas de groupe. Si le mobile UE se déplace vers une station de base eNB non connectée à l’entité MME qui contient le contexte du mobile UE, alors l’entité MME source sélectionne l’entité MME cible pour lui transférer le contexte.

L’entité MME fournit les informations requises pour les interceptions légales, par exemple l’état du mobile (en veille ou connecté), sa localisation TAI si le mobile est en veille ou l’identité de la cellule ECGI (E-UTRAN Cell Global Identifier) si le mobile est en session.

1.1.3. L’entité SGW

L’entité SGW constitue le point d’ancrage du plan utilisateur pour le handover intra-système (mobilité à l’intérieur du réseau 4G) à condition que le mobile ne change pas de groupe. Dans le cas contraire, l’entité PGW assure cette fonction. Les entités SGW sont également organisées en groupes (pools) et afin d’assurer l’équilibrage de la charge des entités SGW, chaque entité eNB d’un groupe doit avoir accès à chaque entité SGW du même groupe.

L’entité SGW constitue également le point d’ancrage lors du handover inter-système en mode PS (Packet-Switched), nécessitant le transfert du trafic du mobile vers un réseau de mobiles de 2ème ou de 3ème génération.

L’entité SGW transfère les données entrantes provenant de l’entité PGW vers la station de base eNB et les données sortantes provenant de la station de base eNB vers l’entité PGW.

L’entité SGW informe l’entité MME pour les données entrantes lorsque le mobile est à l’état de veille, ce qui permet à l’entité MME de déclencher une procédure de notification (paging) à destination de toutes les stations de bases eNB de la zone de localisation TAI.

Lorsque l’entité SGW reçoit des données des entités eNB ou PGW, elle se réfère au contexte afin de connaitre l’identifiant de la classe de service QCI pour la mise en œuvre du mécanisme d’ordonnancement des données et pour le marquage du champ DSCP des paquets IP.

Dans le cas de l’itinérance correspondant à l’architecture Home Routed (le flux est transféré vers le PGW du réseau Home), l’entité SGW du réseau visité dérive le trafic du mobile dans le cadre des interceptions légales.

1.1.4. L’entité PGW

L’entité PGW est le routeur de passerelle assurant la connexion du réseau EPS au réseau de données PDN.

Au cours de la procédure d’attachement, l’UE se voit affecter une adresse IP (IPv4 ou IPv6) attribuée par l’entité PGW. Ainsi, en cas de l’itinérance (roaming) dans le mode HR (Home Routed), le mobile obtient une adresse IP fournie par le HPLMN et est vu comme une entité du réseau Home même si le point d’ancrage du trafic (SGW) appartient au réseau visité. Si l’adresse IPv4 attribuée est une adresse privée, l’entité PGW effectue la fonction NAPT (Network Address and Port Translation) consistant à traduire l’adresse IP et du numéro de port de TCP ou UDP du flux.

Lorsque l’entité PGW reçoit des données de l’entité SGW ou du réseau PDN, elle se réfère à l’identifiant de la classe de service QCI pour la mise en œuvre du mécanisme d’ordonnancement des données et pour le marquage DSCP des paquets IP.

L’entité PGW constitue le point d’ancrage pour la mobilité inter-SGW, lorsque le mobile change de groupe.

L’entité PGW héberge la fonction PCEF (Policy and Charging Enforcement Function) qui applique les règles relatives au trafic du mobile, concernant le filtrage des paquets, la taxation et la qualité de service à appliquer au support à construire.

L’entité PCRF (Policy Charging and Rules Function), extérieure au réseau EPS, fournit à la fonction PCEF de l’entité PGW les règles à appliquer lors de l’établissement du support.

L’entité PGW dérive le trafic du mobile dans le cadre des interceptions légales, pour les cas suivants :

  • le mobile est attaché sur son réseau nominal ;
  • le mobile est attaché sur un réseau visité, pour les deux types d’architecture, HR ou LBO (Local Breakout). Dans le cas de l’architecture LBO, le mobile UE est connecté au PGW du réseau visité alors que pour l’architecture HR, le mobile UE est connecté au PGW du réseau home.

1.1.5. L’entité HSS

L’entité HSS est une base de données assurant le stockage des données propres à chaque abonné. Les principales données stockées comprennent les identités de l’abonné, les paramètres d’authentification et le profil de service.

Lors de la souscription au réseau EPS, le mobile se voit attribuer une identité privée IMSI (International Mobile Subscriber Identity) à laquelle est associée un profil de service et une clé secrète Ki.

Lors de l’attachement, l’entité MME contacte l’entité HSS pour récupérer les valeurs d’authentification calculées au niveau du HSS à partir de la clé secrète Ki. Une fois authentifiée, l’entité HSS transmet le profil de service du mobile au MME et conserve l’adresse du MME sur lequel l’abonné (IMSI) est enregistré.

1.1.6. L’entité PCRF

Les opérateurs proposent différents abonnements pour l’accès aux services du réseau mobile. Afin de contrôler l’accès au réseau pour chaque client, il est nécessaire de contrôler l’usage du réseau et des services. L’entité PCRF permet de contrôler en temps réels l’usage du client par rapport à son abonnement et son forfait restant. Ainsi, en cas  de dépassement de forfait, le PCRF va imposer une règle pour réduire le débit (fair-use). De plus, dans le cadre de la VoLTE (Voix sur LTE),  l’opérateur doit mettre en place de la priorité de service.

La fonction PCC (Policy and Charging Control) définit les fonctions d’autorisation et de blocage des flux IP avec la QoS associée à chaque flux (policy)  et la méthode de taxation des flux IP (charging). L’entité PCRF fournit à la fonction PCEF, intégrée dans l’entité PGW, les informations nécessaires pour le contrôle et la taxation du trafic.

Ces informations sont stockées dans la base de données SPR (Subscription Profile Repository) lors de la création de l’abonnement.

Le contrôle du trafic comprend les opérations suivantes :

  • l’association entre un flux de données de service SDF (Service Data Flow) et un support EPS (EPS bearer) ;
  • le blocage ou l’autorisation des paquets IP ;
  • l’attribution du paramètre QCI au support EPS.

L’entité PCEF exécute les règles fournies par l’entité PCRF, pour le contrôle des flux de trafic et la taxation. En situation d’itinérance (roaming) correspondant à l’architecture LBO, l’entité PCEF localisée dans le réseau visité demande les règles à l’entité V-PCRF (Visited-PCRF), qui les obtient de l’entité H-PCRF (Home-PCRF) du réseau nominal

La fonction PCEF peut rapporter à l’entité PCRF un changement d’état d’un flux de service comme dans le cas d’une perte de couverture radioélectrique du mobile.

L’entité PCRF peut recevoir une requête de session de la part de l’entité AF (Application Function) comme dans le cas de l’établissement d’une communication téléphonique ou visiophonique initialisée au niveau du réseau IMS (IP Multimedia Sub-system).

L’entité PCRF peut fournir à l’entité AF des informations concernant des événements se produisant dans le réseau mobile comme par exemple une perte de couverture radioélectrique du mobile.

 

 

Références

1 : Livre LTE-Advanced Pro

2: Documentation ZTE

 

IoT, Blockchain, IA, machine learning : Des technologies disruptives?

Les évolutions technologiques récentes vont apporter des changements profonds dans les domaines de la santé, de la logistique, le transport, l’énergie, l’agriculture, …

Si le déploiement de l’IoT (Internet of Things) destiné à collecter un ensemble d’informations constitue la première brique de cette évolution, la plus-value de cette transversalité numérique ne peut être obtenue qu’en garantissant la sécurisation des données collectées et le traitement efficace de ces données.

En cela, la technologie Blockchain s’insère dans l’écosystème de l’IoT en apportant un stockage des données, en assurant le transport sécurisé des données échangées et en permettant la traçabilité des données.

Quant aux traitements des données, l’intelligence artificielle (IA) permet de les valoriser et de les traduire en informations exploitables facilitant ainsi l’analyse décisionnelle des systèmes complexes. De surcroît, les méthodes d’apprentissages autonomes (Machine Learning) permettent également de classifier les données et d’apporter des outils de prédictions des pannes.

Les applications IA pourraient être mise en œuvre sur des lames de serveurs au plus proches des données collectées (MEC : Mobile Edge Computing).

Ainsi, les secteurs de la santé (capteurs et IA pour détecter l’évolution des maladies), du transport (véhicules autonomes), des chaînes d’approvisionnement (réparation des chaînes de production avant la cassure des pièces usées, l’approvisionnement en flux tendus), de l’énergie (délestages des sites industriels en assurant un transport de l’énergie au plus proche) seront impactés par la complémentarité de ces technologies disruptives.

Dans ces écosystèmes de plus en plus complexes, la donnée reste l’élément fondamental et le premier maillon d’une nouvelle ère économique. Les cabinets d’analystes estiment une évolution constante du marché des capteurs de l’IoT pour atteindre une centaine de milliards de dollars d’ici 2023 et une croissance du taux actuariel (CAGR – Compound annual growth rate) de 13%.

SigFox est le premier opérateur à s’être positionné sur le marché de la transmission sans fil des données issues des capteurs en déployant le réseau de transmission longue portée à basse consommation (LPWAN : LoW Power WAN).  Ce réseau LPWAN répond à la demande des compteurs intelligents (smart-meters, compteur d’eau, compteur de gaz), à la gestion des villes (smart-city) pour lesquels la communication est à latence élevée.

Aujourd’hui, l’opérateur Télécom SigFox est concurrencé par l’opérateur QoWiSio, l’opérateur Américain Ingénu, et l’alliance LoRaWAN avec le déploiement de LoRa par les opérateurs télécoms historiques.

Le réseau cellulaire 4G se positionne également sur ce secteur en étendant ses fonctionnalités pour répondre à l’émergence du marché de l’Internet des Objets. Ce réseau dédié aux communications Machine à Machine (MTC – Machine Type Communication) est destiné à devenir le premier réseau cellulaire LPWAN (Low Power WAN). Le premier avantage est de pouvoir rapidement apporter une couverture mondiale avec optionnellement une qualité de service.

L’IoT cellulaire (par son réseau d’accès NB-IoT, LTE-M et prochainement 5G NR) devrait connaître la plus forte croissance avec en point de mire, entre 10 000 et 100 000 objets connectés sous la couverture d’une seule station de base. Orange a ouvert son réseau LTE-M en novembre 2018, comme annoncé dans un précédent article traitant du cellular IoT.

Le réseau 5G quant à lui va permettre d’apporter de nouvelles solutions pour les communications M2M à temps réel (missions critiques URLLC : Ultra Reliable Low Latency Communication) pour répondre au besoin du secteur de l’automobile et de l’industrie (IIoT – Industrial IoT).

Le laboratoire LIAS s’intéresse à ces différentes technologies notamment comme application visée (de manière non exhaustive) le smart-grid, le secteur du transport,…

Dans les prochains articles je reviendrai plus particulièrement sur le MTC (réseau 4G).

Il est à rappeler que ces métiers s’adressent aux femmes et aux hommes, je vous invite à consulter le site femmes-numérique.fr

Blockchain, intelligence artificielle, big data, cyber sécurité, objets connectés, cloud…

 

L’initiative

 

Les procédures liées aux supports (bearers) dans l’architecture CUPS

Avant de lire cet article, il est préférable d’avoir lu l’article précédent présentant l’architecture CUPS. Dans cet article nous allons voir les modifications apportées sur les protocoles d’établissement de support suite au découpage des entités SGW et PGW en deux parties (plan de contrôle et plan utilisateur).

I) Protocole de gestion des sessions et de handover

Le protocole de gestion de sessions a pour but d’ajouter, de modifier ou supprimer une entrée des tables de contextes au niveau des entités SGW et PGW  afin de permettre :

  • l’établissement du support par défaut ;
  • l’établissement du support dédié ;
  • la modification des caractéristiques du support
  • la désactivation du support

En cas de handover, sous la direction de l’entité MME, la table de contexte du SGW doit être modifiée afin de gérer le transfert de l’entité eNB source vers l’entité eNB cible.

Pour assurer la compatibilité avec les différentes évolutions du réseau opérateur, les entités fonctionnelles SGW-C et SGW-U doivent assurer les mêmes fonctionnalités.

Ainsi, concernant la gestion des sessions, les sous-fonctionnalités sont réparties de la manière suivante :

  • La gestion des supports (bearer) est sous la responsabilité des entités SGW-C ou SGW-U
  • L’allocation des identifiants de tunnels TEID est obligatoirement sous la responsabilité de l’entité SGW-C et optionnellement, l’entité SGW-C peut léguer cette fonctionnalité à l’entité SGW-U.
  • Le transfert des paquets est géré par l’entité SGW-U
  • Le marquage des paquets est géré par l’entité SGW-U

L’identifiant de tunnel TEID est unique pour chaque entité SGW-U, ce dernier est alloué lors de l’activation d’un support et supprimé lors de la désactivation du support.

En cas de handover de la station de base eNb source vers une station de base eNb cible sans changement d’entité SGW-U, l’entité fonctionnelle  SGW-C (qui est le contrôleur SDN) injecte une modification de règles de transfert à l’entité SGW-U via la requête Sx session modification request supportée par le protocole PFCP. La table de flux au niveau de l’entité SGW-U doit remplacer l’adresse IP de l’eNB source et l’identifiant de tunnel associé au bearer sur l’eNB source par l’adresse IP et le TEID correspondant de l’eNB cible (et ceci pour  tous les tunnels activés lors de la procédure de handover).

En cas de handover d’un eNb source vers un eNb cible avec changement d’entité SGW-U, l’entité fonctionnelle PGW-C (contrôleur SDN) doit en plus injecter une modification de règles (protocole PFCP)à l’entité PWG-U pour commuter le tunnel S5/S8 de l’entité SGW-U  vers l’entité SGW-U cible. Le message Sx session modification request transmis de l’entité PGW-C vers l’entité PGW-U contient l’identifiant du support (bearer ID), l’adresse IP de l’entité SGW-U cible et le nouvel identifiant de support TEID de l’entité SGW-U.

La procédure de handover se déroule en trois étapes :

  • Préparation des ressources radios entre l’entité UE et l’eNB cible
  • Modification de la table de contexte du SGW-U provoquée par l’échange suivant
    • SGW-C vers SGW-U: requête Sx session modification request
    • Après avoir transmis le dernier paquet PDU à l’entité eNB source, le SGW-U confirme la modification de sa table de flux
    • SGW-C U vers SGW-C: requête Sx session modification response
  • Une fois pris en compte le changement de chemin S1 path au niveau du SGW-U, il faut en informer l’entité eNB source :
    • SGW-C transmet au SGW-U un marqueur de fin de paquets (end marker packet)
    • SGW-U transmet à l’entité eNB source le marqueur de fin de paquets (end marker packet)
    • l’entité eNB source peut relâcher les supports radios avec l’entité UE.

Si le handover nécessite un changement de SGW-U, dans ce cas, la gestion du marqueur de fin de paquets (end marker packet) est sous le contrôle du PGW-C.

II) Protocole pour la fonction HLCom

Dans le cas de dispositifs IoT à latence élevée, l’organisme 3GPP a introduit des solutions de buffer étendu afin de conserver les données à transmettre aux dispositifs lorsque ces derniers ne sont plus joignables (EMM Registered mais à l’état dormant). Les données sont bufférisées au niveau du SGW jusqu’à ce que le dispositif soit de nouveau dans l’état idle ou connected.

Avec la séparation de l’entité SGW en plan de contrôle et plan utilisateur, la sauvegarde des données doit obligatoirement être supportée par l’entité fonctionnelle SGW-U et optionnellement par l’entité SGW-C.

Premier Cas :

Dans le cas où l’entité SGW-C support la capacité de sauvegarde des données (buffering capacity), lorsque le dispositif UE est dans l’état ECM_idle pour une durée eDRX ou PSM connue, l’entité SGW-C informe l’entité SGW-U (injection de règles) de ne plus transmettre les données à la station de base eNB mais de commencer à transférer les données vers l’entité SGW-C.

Lorsque l’entité UE passe à l’état ECM-CONNECTED, alors l’entité SGW-C met à jour les tables de flux du SGW-U avec l’identifiant TEID du eNB correspondant. Si des données ont été sauvegardées au niveau de l’entité SGW-C, alors les données sont encapsulées dans l’injection de règles Sx. L’encapsulation GTP-U permet à l’entité SGW-U d’identifier la connexion PDN et l’identité du support.

Deuxième Cas :

L’entité SGW-U conserve les données à destinations des dispositifs UE non joignable mais enregistrés sur le réseau.  Ainsi, lorsque le mobile UE passe à l’état en veille (ECM-IDLE), l’entité SGW-C est informée par le MME et doit à son tour en informer l’entité SGW-U par le message Sx session modification.  Dans ce deuxième cas, l’entité SGW-C décide que la bufferisation des données est à la charge de l’entité SGW-U et informe ce dernier. De plus, l’entité SGW-C demande à l’entité SGW-U d’être notifié ou non lorsque le premier paquet en provenance du PDN et à destination du dispositif UE est transmis à l’entité SGW-U

Ainsi, lorsque le premier paquet à destination du dispositif UE est transmis à l’entité SGW-U, ce dernier doit informer le contrôleur SGW-C par le message Sx reporting message ou non. A la réception de ce message, l’entité SGW-C décide d’informer ou non l’entité MME en transmettant la requête Downlink Data Notification.

Lorsque le dispositif UE passe à l’état ECM-CONNECTED, l’entité MME informe l’entité SGW-C et ce dernier notifie l’entité SGW-U via l’interface Sxa en indiquant l’identifiant de tunnel de l’eNB (ou éventuellement le RNC/SGSN).  Les données sont transmises de l’entité SGW-U à l’eNB (ou RNC ou SGSN) et en cas de la mobilité du dispositif UE sur un autre SGW-U, les données sont transmsises de l’entité SGW-U source (l’entité qui a bufferisé les données) vers l’entité SGW-U cible.

III) Les Procédures Sx Sessions Management

Les procédures Sx Sessions Management permettent de contrôler les fonctionnalités des entités fonctionnelles du plan de transport. Le contrôleur peut créer, mettre à jour, ou supprimer les contextes de sessions Sx, c’est-à-dire les paramètres de contextes concernant une connexion PDN pour le support par défaut et pour le support dédié.

Figure 1 : La procédure d’établissement de contexte

Une fois le contexte crée pour une connexion PDN, il est possible de modifier les caractéristiques du contexte par la procédure Sx Session Modification Procedure.

Pour désactiver le contexte, la procédure se nomme Sx Session termination procedure.

Nous allons illustrer la procédure sur une demande d’attachement d’un mobile UE. On suppose que la demande s’effectue sur le MME défini par l’identité GUTI conservé par le mobile UE mais de par le déplacement du mobile UE, on suppose que le mobile UE est sous la couverture d’une cellule connectée à une entité SGW (nommée nouveau SGW) différente de l’entité SGW (nommée ancien SGW) sur lequel le mobile UE était connecté avant le détachement.

On allume  le mobile, le SGW-U ayant été modifié, alors :

  • Au cours de la procédure d’attachement, la modification du SGW source au SGW cible nécessite de supprimer les tables de flux au niveau des entités SGW-U et PGW-U. Ainsi, les entités old SGW-C et old PGW-C exécutent la procédure Sx Session termination
  • Lors de la requête PDN connectivity, la table de flux au niveau du SGW-U et PGW-U doit être fournie. Ainsi, les contrôleurs SDN SGW-C et PGW-C injectent les règles par la procédure Sx Session Establishment.

Nous allons découper le call flow en deux parties :

Première partie

  • Procédure d’établissement du lien radio
  • Demande d’attachement, authentification et mise en sécurité

Deuxième partie

  • Suppression du contexte sur l’entité Old SGW
  • Création du support avec le nouveau SGW

    Figure 2 : La première partie de demande d’attachement

    Figure 3 : La procédure d’établissement de support

 

Network Functions Virtualisation (NFV) pour le réseau 4G/5G

Objectifs :

Comprendre :

  • l’infrastucture du NFV (NFVI);
  • la gestion et l’orchestration des VM (MANO)
  • la fonction de chainâge de service VNFFG (Virtual Network Function Forwarding Graph). Le VNFFG correspond à la fonction SFC pour le NFV (reprendre l’article précédent pour le SFC)

Introduction

L’approche NFV permet à l’opérateur de déployer des fonctions réseaux en tant qu’instances virtualisées au lieu d’entités matérielles dédiées. L’approche NFV s’appuyant sur la virtualisation informatique permet la création de partition réseau isolée sur une infrastructure réseau partagée permettant ainsi à de multiples réseaux virtuels hétérogènes de co-exister simultanément sur les mêmes équipements matériels.

L’architecture NFV définie par l’ETSI est représentée sur la figure 1. La couche horizontale VNF correspond aux fonctions réseaux virtualisée (VNF : Virtualised Network Function). Il s’agit de machines virtuelles (VM) fonctionnant sur l’infrastructure NFV (NFVI). L’infrastructure NFVI est une infrastructure physique de stockage, de calcul et de réseau. La gestion et l’orchestration des VM est sous la responsabilité de la fonction MANO (Management and orchestration). La fonction MANO doit gérer les ressources de l’infrastructure NFVI (capacité réseau, la puissance de calcul, l’espace mémoire) et la durée de vie des fonctions virtuelles en fonctionnement sur l’infrastructure NFVI (création et allocation des VMs).

Les nœuds de l’infrastructure NFV (NFVI nodes) sont déployés sur les points de présence POP de l’opérateur afin de répondre aux exigences de latence selon les cas d’usages client. Les fonctions réseaux virtualisés (VNF) peuvent ainsi être déployées dynamiquement sur les infrastructures NFVI à la demande d’un orchestrateur et sous réserve de la limite de capacités des nœuds NFI (POP).

Figure 1 : Architecture NFV

La virtualisation élimine la dépendance entre les fonctions réseaux (NF : Network Function) et le matériel. Dans le cas du réseau de mobiles, les entités pouvant être virtualisées sont :

  • dans le cœur réseau EPC : l’entité MME, le SGW, le PGW
  • dans le cœur réseau IMS : P/I/S-CSCF

Une fois que les entités sont virtualisées (on parle alors de VNF), il est nécessaire de chaîner le trafic à travers les VNF dans un graphe ordonné pour appliquer les services réseaux. Dans le cas du NFV, le chaînage s’appelle le graphe d’acheminement des fonctions réseaux virtualisées (VNFFG – VNF  Forwarding Graph) et non le chaînage de fonctions service SFC (Service Function Chain) pour prendre en compte la virtualisation sur un réseau Overlay.

Le graphe d’acheminement des fonctions réseaux virtualisées VNF-FG fourni un niveau d’abstraction afin que l’opérateur puisse en temps réel composer les services réseaux.

Figure 2 : Exemple de graphe d’acheminement des fonctions réseaux virtualisées

Figure extrait de l’article Network Functions Virtualisation  -Update White Paper (https://portal.etsi.org/nfv/nfv_white_paper2.pdf)

II) L’architecture NFV définie par l’ETSI

L’architecture NFV est constituée de :

  • l’insfrastructure NFV : NFVI (Network Function Virtualisation Infrastructure) fournit les ressources matérielles (serveurs, COTS – Commercial Off The Sheld, cartes électroniques, …) et le logiciel de virtualisation. Le NFVI se compose donc :
    • d’une interface matérielle (stockage, réseau, calcul)
    • d’une interface virtuelle (stockage, réseau, calcul)
    • d’une couche de virtualisation entre le matériel et le logiciel
  • Le VNF (Virtualised Network Function) correspond aux fonctions réseaux virtualisées pouvant être exécutées sur les équipements du NFVI
  • NFV M&O (Management and Orchestration) permettant de gérer les services réseaux de bout en bout est composé de trois blocs
    • L’orchestrateur (NFV Orchestrator) : L’entité d’orchestration est responsable du cycle de vie des services réseau tant au niveau logiciel que matériel sur plusieurs domaines en contrôlant les VIM de chaque domaine;
    • un  gestionnaire (VNFM) en charge du cycle de vie des VNFs ;
    • un gestionnaire (VIM) en charge de la gestion des ressources du NFVI à l’intérieur d’un domaine.

Les services OSS/BSS doivent pouvoir transmettre au bloc NFV M&O des informations sur le profil des utilisateurs, la facturation, les politiques de qualités, les accords entre domaine, …

Couplé à un portail de supervision, cette architecture permet aussi de déployer des services réseaux à la demande pour les entreprises (exemple Network as a service  de la solution  Easy Go Network).

L’infrastructure NFV (NFVI) est donc répartie sur des points de présence de l’opérateur (POP) afin de réduire la latence du réseau pour ses clients : les services réseaux sont déployés sur les nœuds d’infrastructure (NFVI Node) au plus proche des clients.

Les fonctions réseaux virtualisées (VNF) peuvent ainsi être déployées dynamiquement à la demande dans la limite des capacités des nœuds NFVI.

II-1) L’infrastructure NFV (NFVI)

L’infrastructure NFV se découpe en trois domaines :

  • domaine de calcul virtualisé (processeurs, accélérateurs, …) ;
  • domaine de l’hyperviseur : système d’exploitation supportant la virtualisation (machines virtuelles) et/ou des containeurs pour faire fonctionner les VNF, ainsi que les capacités de commutateurs virtuels (vSwitch).
  • domaine réseau de l’infrastructure

En général, l’infrastructure NFV s’appuie sur la paravirtualisation et non la virtualisation : les systèmes d’exploitation des machines virtualisés n’évoluent pas dans un environnement physique virtuel mais dialogue avec l’hyperviseur via des API. La para-virtualisation réduit la consommation de ressources processeur de la virtualisation afin d’améliorer les performances en modifiant le noyau du système d’exploitation invité. Une couche de virtualisation est insérée entre le matériel et le système d’exploitation.

Le coeur de la paravirtualisation est un hyperviseur fonctionnant au plus près du matériel, et fournissant une interface qui permet à plusieurs systèmes hôtes d’accéder de manière concurrente aux ressources. Les systèmes d’exploitation hôte et invités sont modifiés pour fonctionner sur la couche de virtualisation

Figure 3 : L’infrastructure et la para-virtualisation

Les fonctions réseaux virtualisées seront déployées dans des conteneurs au-dessus de la couche de virtualisation. Un conteneur est une instance complète de système d’exploitation, avec son système de fichiers, ses comptes utilisateurs, ses processus, etc. Ainsi, les conteneurs logiciels sont considérés comme des applications pour le serveur. Sur cette application (système d’exploitation), il est possible de faire tourner des fonctions réseaux virtuels, nommés VNF

Enfin, les VNF sont interconnectées entre elles pour constituer un service réseau (NS).

Figure 4 : Le chainage de service réseaux virtuels

II-2) La gestion et l’orchestration NVF (NFV MANO – Management and Orchestration)

La couche de virtualisation permet de découpler l’implémentation logicielle des fonctions réseaux aux ressources matérielles (calcul, accélérateur et ressources réseaux). Ce découplage nécessite de nouvelles fonctions de gestion et d’orchestration et créé de nouvelles dépendances entre les ressources matérielles et les solutions logicielles virtualisées.

Une des premières motivations du NFV est l’agilité à déployer des nouvelles fonctions réseaux et d’accroitre les capacités de ces fonctions à la demande (exemple : une entreprise qui souhaite une bande passante plus importante une heure particulière dans la semaine, cf : https://www.youtube.com/watch?v=niHSqvKz4U0).

Afin de pouvoir profiter de cette agilité, un niveau d’automatisation de haut niveau est nécessaire pour provisionner, configurer et tester les performances des fonctions réseaux virtualisées.

La gestion et l’orchestration NFV (MANO) automatise le déploiement de fonctions réseaux virtualisées (VNF). Pour cela, il faut superviser :

  • L’infrastructure pour la gestion du matériel (capacité, réseau, calcul, …)
  • Le déploiement de fonctions réseaux (VNF)
  • Le chaînage de fonctions réseaux pour réaliser des services réseaux

Ainsi, l’entité MANO est constituée de trois fonctions :

  • Gestion des ressources
  • Gestions des VNF
  • Gestion des NS

Figure 5 : L’orchestration et la gestion des services et des ressources

L’objectif est de pouvoir mettre en œuvre des fonctions pour fournir des fonctions réseaux virtualisés et des services réseaux avec les ressources nécessaires pour s’exécuter correctement : les types d’instances à déployer, adapter la taille de l’instance en fonction de la demande (scaling) , mettre à jour une fonction réseau virtualisée (VNF), ou éteindre l’instance.

Au niveau réseau, les opérations de déploiement de service réseaux s’appuient des descripteurs décrivant les ressources et les opérations nécessaires. Les différents types de descripteurs sont :

  • Descripteurs VNF (VNFD) sont des gabarits permettant de définir les instances à mettre en œuvre et les besoins en ressource de chaque instance (CPU, mémoire, interface et réseau). Le descripteur défini également les types d’interfaces avec l’infrastructure NFVI et les KPI attendues.
  • Descripteur NS (NSD) : Le descripteur NSD contient les attributs pour un groupe de fonctions réseaux qui constituent ensemble un service réseau. Ces attribues contiennent aussi les exigences pour chaîner les VNF ensemble et fournir le service réseau.
  • Descripteur VNFFG (VNFFGD) contient des metadata concernant le graphe d’acheminement des fonctions réseaux virtualisées VNF, ainsi que les références aux conteneurs de l’infrastructure, aux instances VNFs et au lien entre les VNFs. Les métadonnées contiennent de plus des règles de politiques pour les fonctions d’acheminement (règle de routage et de commutation).

De plus, il est nécessaire :

  • d’automatiser les fonctions de supervisions en collectant les métriques de performances sur des instances et du matériel à des niveaux différents
  • de corréler les mesures effectuées afin d’apporter une solution sur les fautes détectées pour que le service fonctionne de manière fiable sur des équipements distribués.
  • de définir des performances KPI (Key Performance Indicator) au niveau des services réseaux (NS)

Comme évoqué précédemement, le bloc NFV M&O (Management and Orchestration) permet de gérer les services réseaux de bout en bout est composé de trois blocs

  • L’orchestrateur (NFV Orchestrator) : L’entité d’orchestration est responsable du cycle de vie des services réseau tant au niveau logicielle que matérielle sur plusieurs domaines en contrôlant les VIM de chaque domaine;
  • un  gestionnaire (VNFM) en charge du cycle de vie des instances VNFs en fonction des données contenues dans le descripteur. Il démarre les instances VNF, les gères, les adapte et récupère des indicateurs de supervision. Le gestionnaire VNFM utilise donc le descripteur VNFD durant la procédure d’instanciation de la fonction réseau virtualisée VNF et pendant toute la durée de vie de la VNF ;
  • un gestionnaire (VIM) en charge de la gestion des ressources du NFVI à l’intérieur d’un domaine.

Le gestionnaire VIM est une abstraction matérielle qui fourni une interface nord pour le VNFM et l’orchestrateur NFV. L’interface sud supporte les interfaces Nf-Vi pour piloter les instances sur l’infrastructure NFVI.

 

La figure ci-dessous présente un schéma de déploiement au sein d’Orange avec l’appui de Juniper et d’un controleur sous Openstack.

 

Virtualisation du réseau EPC : Concept NFV/SDN

La virtualisation du réseau permet  la montée rapide en charge de travail en mettant en route plusieurs machines virtuelles (VM) et les services réseaux associés (commutation logique, routage logique, pare-feu logique, équilibrage de charge logique, VPN logique, accélération WAN, compression d’entête, …) pour chaque charge de travail.

Les avantages de la virtualisation sont les suivants :

  • amélioration de l’efficacité des serveurs ;
  • gestion des charges de travail grâce au déploiement de VM et des services réseaux;
  • gain des performances du réseau et flexibilité;
    • déplacement de VM
    • équilibrage de charge
    • agilité de l’infrastructure réseau
    • Réduction du temps de déploiement : Time To Market
    • Chaînage de service en déployant les VMs  par application

I – La virtualisation du réseau

La virtualisation consiste à déployer plusieurs machines virtuelles sur un serveur physique. Afin de pouvoir partager les ressources matérielles (CPU, cartes réseaux, ….), il est nécessaire d’installer un logiciel de virtualisation appelé hyperviseur. Chaque machine virtuelle dispose de son propre système d’exploitation. Les pilotes et les périphériques sont stockés dans un domaine de l’hyperviseur accessible à chaque VM, les VMs utilisent des périphériques virtuels.

Un hyperviseur de type paravirtualisation nommé bare-metal ou type 1 s’exécute directement sur le serveur physique.

La gestion des VM et la sécurité est un point critique : les règles de pare-feu doivent être modifiées (rajoutées ou supprimées) à chaque fois qu’une nouvelle VM est rajoutée ou supprimée. Les premières solutions déployées pour les Datacenters permettent l’automatisation du provisionnement (provisionning) en fonction de l’ajout, la suppression ou la modification de VM.

Ainsi, lorsque le client exprime un besoin, par exemple mettre à jour des données sur son site web hébergé au niveau d’un Datacenter, cette charge de travail peut nécessiter la collecte et la fusion de données, des calculs, un stockage et une mise en forme spécifique des résultats à travers un tableur. L’hébergeur peut ainsi activer plusieurs VM (ou container) sur un seul serveur ou sur plusieurs serveurs. Dans ce cas il est nécessaire que les serveurs communiquent les uns avec les autres, on parle de communication est/ouest afin de répondre à la requête du client (communication nord/sud).

Au niveau du serveur physique, les VM sont isolées les unes des autres. L’isolation de VM non chaînées garantie qu’aucun échange ne peut s’effectuer entre les deux VM.  Cependant, l’échange de données entre les VMs est possible via un routage mais cela nécessite l’établissement de règles de sécurité : les règles du pare-feu entre chaque VM doivent être définies par rapport aux applications hébergées sur la VM. La micro-segmentation qui consiste à mettre en réseau plusieurs VM pour une charge de travail donnée peut être sécurisée par des pare-feux virtuels.

Dans le cas d’architecture réseau traditionnel, le trafic des charges de travail doit passer par un point de contrôle unique comme par exemple un pare-feu physique avec des règles établies pour tous les types d’application. Cette architecture, nommée hairpinning, créée un goulot d’étranglement ce qui rend donc cette architecture inefficace lorsque les charges de travail ne nécessitent pas les mêmes traitements. Son avantage est la stabilité du réseau et son prix.

Grace au déploiement du réseau virtuel :

  • la charge de travail est indépendante du réseau physique, c’est-à-dire de la configuration de VLAN, de la liste de contrôle d’accès, des règles de pare-feu. La micro-segmentation permet le transfert de données entre VMs isolées via un routage logiciel et un pare-feu logiciel ;
  • plusieurs charges de travail peuvent co-exister sur le même réseau physique et sur les mêmes entités, permet ainsi de partitionner virtuellement plusieurs services (slicing network).

L’automatisation permet de mettre en route ou d’éteindre l’ensemble des VM concernés et de provisionner les politiques adéquates des pare-feux pour chaque charge de travail.

L’orchestration permet de configurer toutes les charges de travail sur les serveurs physiques (planification des VMs en fonction des serveurs physiques existants et gestion des réseaux virtuels en fonction des capacités physiques réelles de la couche de transport).

II – Network Functions Virtualization

Jusqu’à présent, nous avons vu que la virtualisation permettaient de déplacer vers des serveurs banalisés :

  • les équipements de traitement de réseau (pare-feu, dpi, accélérateur WAN, équilibrage de charge, …)
  • les équipements de fonction réseau (commutateur, routeur)
  • les serveurs de stockage et serveur cache

Figure 1 : Virtualisation de fonctions réseaux

D’autres fonctions réseaux sont également virtualisables :

  • les entités du réseau mobiles : HSS, HLR, MME, SGW, PGW, SGSN, GGSN
  • les réseaux d’accès : BTS, BSC, NB, RNC, eNB

L’approche NFV a été initiée par l’organisme ETSI dans l’objectif de virtualiser les services et fonctions du réseau et de gérer les VMs en fonction des demandes des utilisateurs. Nous définirons l’architecture NFV dans un prochain article.

III – NFV/SDN

On distingue :

  • la virtualisation du réseau consistant à virtualiser sur des pools de ressources des applications (calcul, stockage et service réseau –DHCP – DNS – Parefeu logiciel – équilibrage de charge) et à gérer au niveau de l’hyperviseur les fonctions réseaux logiciel et la sécurité logicielle;
  • le NFV qui exploite les fonctions de la virtualisation en gérant et orchestrant les fonctions de virtualisation par un contrôleur. Le NFV est une architecture de virtualisation s’appuyant sur l’infrastructure physique (NFVI) sur laquelle tourne plusieurs VM. La gestion des ressources physiques du serveur (CPU, RAM, accès réseau, disques virtuels, switchs/routeurs virtuels, …), et la durée de vie des VMs sont contrôlés par une couche de gestion et d’orchestration NFV nommé MANO (Management and Orchestration) et qui est piloté par le système BSS/OSS de l’opérateur
  • le SDN consistant à séparer le plan de contrôle et le plan de données en centralisant au niveau d’un contrôleur l’intelligence de l’infrastructure matérielle. L’objectif est de provisionner automatiquement les fonctions du réseau de transport

 

Le concept de SDN (Software Defined Networking) repose sur un découplage entre le plan de commutation local aux équipements réseaux et le plan de contrôle. Le NFV peut s’appuyer sur le SDN en autorisant une gestion centralisée du réseau. La conséquence majeure est que le réseau devient programmable et peut être couplé aux applications métiers des usagers.

L’approche NFV propose d’extraire les fonctions réseaux des équipements dédiés et de les faire fonctionner dans un environnement virtualisé. Pour les opérateurs réseau, l’approche NFV constitue une opportunité de proposer des services de manière plus agile, capable de fonctionner à des échelles extrêmement importantes, mais surtout de manière plus rapide en exploitant les propriétés intrinsèques à la virtualisation. Ainsi, la virtualisation du réseau et de la sécurité permet de gérer des commutateurs virtuels et routeurs virtuels à la charge de l’hyperviseur, ainsi que la sécurité (pare-feu logique, VPN logique et équilibrage de charge logique).  On parle de réseau Overlay car les VMs et les services exploitent le réseau physique sous-jacent (cf.http://blogs.univ-poitiers.fr/f-launay/2018/01/15/principe-du-sdn-dans-une-architecture-reseau-classique/ ).

Ainsi, le contrôleur SDN est utilisé

  • pour programmer l’infrastructure réseau virtuel afin de définir les règles de routages et de sous-réseaux pouvant être utilisées pour interconnecter des fonctions réseaux virtualisés (VNF) : SDN Overlay ;
  • par une fonction réseau virtualisée afin de traduire la fonctionnalité réseau virtualisée attendue à la configuration physique du réseau. Le contrôleur SDN est donc une fonction VNF dans l’infrastructure NFV.

A titre d’exemple, l’un des avantages du SDN/NFV est le chaînage de service dynamique virtuel (traffic steering and chaining service) défini par une politique de flux. Lorsque l’utilisateur souhaite accéder à un service, le contrôleur SDN défini un ensemble de fonction réseaux à déployer. Le rôle du NFV est alors de gérer les VMs à mettre en œuvre et le contrôleur SDN gère le routage des flux.

Nous étudierons le SFC – Service Function Chaining dans le prochain article

Les deux technologies SDN/NFV réduisent ainsi l’OPEX (un seul environnement, automatisation des taches, …) et le CAPEX (remplacement du matériel devient une mise à jour logicielle).

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