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

Panne chez SFR – Rappel d’une autre panne en 2012

Le 6 juillet 2012, Orange était affecté par une panne nationale, l’équioement en défaut avait été identifié : le HLR/HSS  lors de la mise à jour de ce dernier via Alcatel Lucent. Se référer à l’article : http://4glte.over-blog.com/article-panne-chez-orange-107869233.htm

Dans cet article, un ensemble d’hypothèse avait été faite pour lancer des pistes sur les pannes possible.

Aujourd’hui, jeudi 24 juillet, SFR fait façe à une panne nationale, les résultats de l’enquète incrime à nouveau la mise à jour du (d’un?) HLR par Alcatel Lucent,.

On peut alors se poser la question sur les procédures de mises à jour du HLR et pourquoi l’équipe Alcatel-Lucent est prise à défaut 2 ans près sur la mise à jour du HLR, d’autant plus  que chaque HLR dispose d’un système de backup comme solution de secours. C’est ce qui avait d’ailleurs été fait en 2012 par Orange : Le logiciel NG HLR (Lew Generation HLR) avait été mis à jour la veille. Vers 17h30, le réseau a rebasculer sur des bases non mises à jour mais sans effet et pourtant, il s’agissait bien de l’équipement défectueux. Le NG-HLR contient une base de données définissant le type d’abonnement de tous les clients de l’opérateur et qui contient aussi la localisation des abonnés. Ces éléments sont stockés dans la partie Back End du NG-HLR et mise à jour chaque fois qu’un client se déplace dans une nouvelle zone de localisation (LAC). La mémoire de cette base de données était saturée. Pour résoudre ce problème, il a néanmoins fallu d’un grande concertation entre Orange et Alcatal Lucentet un travail remarquable de toutes les équipes.

Malgré l’analogie entre ces deux pannes, est ce la même panne?

Orange avait publié une vidéo didactique présentant la panne : http://www.dailymotion.com/video/xs4bs8_resolution-de-l-incident-reseau-le-deroule-en-details_tech

A priori il y a deux ans la panne touchait tous les abonnés, hors l’opérateur possède plusieurs HLR. Pour SFR, un ensemble de clients sont affectés (les nouveaux clients 3G et 4G). Un HLR peut on être incriminé par contre en 2012, un seul HLR ne pouvait pas être responsable de la panne des 26 millions de clients. Une autre hypothèse était de supposer que le HLR en question était le V-HLR, un HLR virtualisé jouant le rôle d’administration et d’interconnexion des HLR. Mais, cela n’a pas été évoqué ni par Orange, ni par Alcatel.

Pour anecdote, le site Presse-citron terminait l’article en relatant la vidéo par cette conclusion « Reste à savoir si Orange et ses concurrents sauront tirer toutes les conséquences de ce dysfonctionnement pour faire en sorte que cela n’arrive plus. »

 

LTE-Advanced (4G+) sera prochainement commercialisé

LTE-Advanced

Le LTE-Advanced, dénommé aussi LTE-A, a été défini dans la R10 (démarré en octobre 2009) et prévoyait une augmentation du débit en utilisant plusieurs porteuses (agrégation de porteuses). En 2013, les équipementiers expérimentaient les premiers smartphones (cf article S4-LTE-A) et depuis quelques mois les opérateurs Français (notamment Bouygues, Orange et Free) expérimente le LTE-A.

L’idée à déjà été exploitée en 3G avec la dénomination Dual Carrier et s’appuie sur le fait que le débit dépend de la bande de fréquence utilisée : Plus la bande est importante, plus le débit est élevé.

Concernant le LTE, celui-ci exploite une bande de 20 MHz au maximum ce qui permet d’avoir un débit de 150 Mbit/s. En agrégeant 5 porteuses, la bande totale atteint 100 MHz, le débit peut donc être 5 fois plus élevé. En augmentant le nombre d’antennes (MIMO) au niveau de l’émetteur et du récepteur et en améliorant la modulation radio (jusqu’à 256 QAM) lorsque les conditions radios sont excellentes (smartphone proche de l’antenne), le débit peut dépasser le Gbps.

Le LTE-A est défini pour atteindre des débits descendants de 1 Gbps. Son successeur, Le LTE-B, selon Huawei pourrait atteindre plusieurs dizaines de Gbps.

Figure 1

Expérimentation en France de la 4G+

En février, Bouygues dégainait en annonçant le réseau 4G sur Bordeaux et Lyon à partir de Juin 2014 en profitant du re-farming pour avoir la bande suffisante. Orange répliquait en annonçant l’expérimentation du LTE-A sur Bordeaux (pour un débit de 300 Mbps et une bande de 2*20 MHz).

Pour profiter du LTE-A, il faudra un nouvel abonnement (en augmentant la volumétrie de votre abonnement) mais également un smartphone compatible (évolution logicielle)

Free a utilisé un drone pour expérimenter la couverture en 4G+. Cela rappelle l’expérimentation Globalstar et Iridium avec des satellites en basses altitudes (LEO), enfin lisez bien la note du bas d’article (et regardez la date de publication).

Image

Après ce coup de buzz de ZDnet (qui publie de très bons articles), retenez l’arrivée de la 4G+ pour Bouygues et Orange en Juin 2014, et SFR à partir de septembre.