Les explications techniques du réseau de liaison terrestre et d’accès intégrés ont été partiellement présentées dans les trois articles précédents.
Cette article reprend l’illustration de SAMSUNG : Différentes zones urbaines sont couvertes par le mécanisme de relais IAB.
Cet article est le troisième et dernier traitant de l’IAB. Si besoin, n’hésitez pas à relire le premier article et le second.
III) Les mécanismes de routage IAB
III-1) Les entités BAP de la fonction DU et de la fonction MT
Le réseau d’accès IAB est constitué d’un ensemble de nœud IAB IAB-node, et d’une topologie de routage définie par un graphe orienté acyclique (DAG : Directed Acyclic Graph). Ainsi, plusieurs routes peuvent exister entre deux nœuds. La topologie peut ainsi être exploitée pour fiabiliser le routage (en cas de d’échec de lien – backhaul link failure) ou pour équilibrer la charge.
La sélection de la route et l’optimisation doit s’effectuer à chaque fois qu’un nouveau nœud IAB se connecte ou lorsque la topologie du réseau change.
Lorsqu’un nouveau nœud IAB intègre le réseau, l’unité Donor-CU attribue une adresse L2 unique (BAP Address).
Figure 9 : Configuration des instances de routage (Ericsson (1))
Au niveau du donneur IAB, la sous-couche BAP ne contient qu’une seule entité BAP.
Au niveau du nœud IAB, la sous-couche BAP contient une entité BAP sur la fonction MT et une entité BAP co-localisée sur la fonction DU.
La partie émettrice de l’entité BAP communique avec l’entité réceptrice de l’entité BAP.
L’entité réceptrice peut être située :
Lorsqu’il est situé sur un autre nœud, la communication s’effectue à travers le lien backhaul.
Ainsi, la partie émettrice de l’entité BAP (Transmitting part) peut recevoir des unités de sessions de données SDU (Session Data Unit) des couches supérieures ou des données BAP PDU délivrées par l’entité BAP réceptrice co-localisée.
Figure 10 : Les fonctions de l’entité BAP (3GPP TS38.240)
L’entité BAP de réception supprime l’en-tête BAP du SDU et l’entité BAP de transmission rajoute l’en-tête BAP avec le même identifiant de routage BAP ID porté par l’en-tête du PDU avant d’être supprimée.
Au niveau de la fonction MT, la partie émettrice de l’entité BAP peut recevoir des BAP SDU des couches supérieures ou des paquets provenant de (et reçu par) l’entité BAP de la fonction DU du même nœud IAB ce qui lui permet de construire le paquet BAP PDU.
Au niveau de la fonction DU :
La partie émettrice de l’entité BAP doit :
3.2) Les mécanismes de routage
Dans le cas ou plusieurs chemins permettent de transmettre un paquet IP entre le nœud IAB de terminaison et le nœud donneur IAB, des Identifiants de route ID sont associés. L’unité donneur Donor-CU configure alors une table de routage indiquant le prochain saut pour chaque direction UL/DL en fonction de l’identifiant de route. La table de routage sépare la direction DL et UL, la table DL est utilisée par le module DU et la table UL est utilisée par le module MT.
Lorsqu’un paquet IP doit être transmis, le nœud à l’origine (le nœud donneur IAB IAB-donor pour le sens descendant ou le nœud IAB pour le sens montant) rajoute un en-tête BAP comprenant l’adresse L2 du nœud d’origine, l’adresse L2 du nœud de destination et optionnellement (si plusieurs chemins existent) l’identifiant du chemin.
Lorsque l’entité RLC du nœud IAB reçoit plusieurs trames en direction d’un même nœud, l’entité RLC peut multiplexer l’ensemble des trames (correspondance N :1) ou transmettre les trames 1 à 1. La correspondance N :1 est un multiplexage de plusieurs bearer radio dans un seul canal RLC à condition que tous les bearers radio aient les mêmes profils de QoS. La correspondance N :1 permet de transmettre moins de canaux RLC et réduit les en-têtes à rajouter.
La correspondance 1 :1 permet de transmettre des bearers radio dans des canaux RLC spécifique afin de prendre en charge la QoS à appliquer pour chaque bearer.
Figure 11a: La correspondance 1 :1
Figure 11b: La correspondance N :1
IV) Conclusion
La solution IAB a pour objectif de réduire le coût de déploiement de nouvelles stations de base principalement pour les antennes relais dans les bandes millimétriques dans les zones très denses. Toutefois, la solution IAB permet également de densifier le déploiement de nœuds radioélectrique dans le cadre des services V2X (exemple le long des routes/autoroutes).
Figure 12 : Un exemple de déploiement le long d’une autoroute
Enfin, le nœud IAB peut également être mobile (camion) pour mettre en place une infrastructure évènementielle.
Références
Cet article est la suite de l’article :
Le Réseau de liaison terreste et d’accès intégré
II) L’Architecture IAB (Integrated Access Backhaul)
L’architecture IAB (figure 5) permet la connexion entre le mobile UE et le nœud radioélectrique par une connexion radioélectrique 5G multi-sauts entre les nœuds IAB.
On appelle IAB-donor la station de base connectée au cœur de réseau (en général une macro-cell) et le nœud-IAB, une station de base permettant le relai entre le mobile et l’IAB-donor.
On distingue deux types de lien, le lien d’accès et le lien backhaul (Integrated Access and Backhaul) :
Le nœud IAB parent est responsable du séquencement du trafic DL/UL s’établissant à la fois sur le lien d’accès et sur le lien backhaul.
Le nœud IAB fils en tant que dernier maillon de la chaine de transmission est responsable du séquencement de trafic DL/UL entre le nœud IAB et le mobile UE.
Les fonctionnalités de l’IAB sont gérées par deux nouvelles entités réseaux : nœud donneur IAB (IAB-Donor) et un nœud IAB (IAB-node). Chaque nœud IAB a une adresse IP qui est routable par la station de nœud donneur IAB-donor.
Figure 5 : Architecture IAB
Chaque nœud IAB gère deux modules de transmission (figure 6) : un module MT (Mobile Termination) et un module DU.
Le nœud donneur IAB-donor est un gNB, il gère les deux unités CU et DU. Il fournit l’accès au cœur de réseau via le réseau backhaul et le réseau d’accès radioélectrique.
Comme tout gNB, le noeud IAB-donor est constitué d’un seul IAB-donor-CU et d’un ou plusieurs IAB-donor-DU, connecté l’un et l’autre via l’interface F1.
Le noeud IAB-donor est connecté au nœud IAB-node par l’interface NR.
Figure 6 : Architecture CU/DU de la solution IAB
Le nœud IAB-node se connecte en amont à un nœud IAB-node ou à un nœud IAB-donor en exploitant les fonctionnalités UE. Ainsi, le nœud IAB-node :
Le nœud IAB-Donor :
Toutes les fonctions spécifiées pour un gNB-DU sont également appliquées pour un IAB-node-DU et toutes les fonctions spécifiées pour le contexte UE sont également utilisées dans la gestion du contexte de l’IAB-MT.
Le nœud IAB-Node doit avoir une adresse IP pour le plan de contrôle (F1-C) et pour le plan de trafic (F1-U).
La pile protocolaire est similaire à celle de la station de base gNB avec l’ajout d’une sous-couche d’adaptation BAP (Backhaul Adaptation Protocol) située au-dessus de la couche RLC.
Sur l’IAB-donneur-DU, la sous-couche BAP contient une seule entité BAP.
Sur le nœud IAB, la sous-couche BAP contient une entité BAP au niveau de la fonction MT et une entité BAP colocalisée distincte à la fonction DU.
Chaque entité BAP a une partie émettrice et une partie réceptrice. L’entité BAP a pour rôle d’apporter les informations de routage de flux et d’autoriser la transmission multi-sauts. La table de routage est fournie par l’entité gNB-CU via le message BH Routing Configuration.
Les fonctions de la couche d’adaptation BAP permettent :
Figure 7 : L’architecture protocolaire IAB
Le nombre de saut n’est pas limité, il est néanmoins nécessaire de s’assurer du respect des contraintes de latence.
Le donneur IAB-donor assigne une adresse de niveau 2 (adresse BAP) à chaque nœud IAB qu’il contrôle. En cas de plusieurs chemins, plusieurs identifiant de route peuvent être associés à chaque entité BAP. L’entité BAP du nœud d’origine (IAB-donor DU pour le trafic DL, et le nœud d’accès IAB pour l’UL) ajoutera un en-tête BAP aux paquets que chacun transfère. Cet en-tête comprend un identifiant ID de routage BAP (par exemple, l’adresse BAP du nœud IAB de destination / source et un ID de chemin facultatif).
Chaque nœud IAB met en place une table de routage qui est configurée par l’unité CU du donneur IAB (message BH Routing Configuration). Cette table contient l’identificateur de saut suivant pour chaque ID de routage BAP.
Figure 8 : Le transfert IAB
Introduction
Le réseau d’accès radioélectrique NG-RAN est composé de nœuds radioélectriques permettant la transmission de flux à très haut débit. Selon la spécification TS 38.300, le nœud NG-RAN peut être une station de base gNB (avec une interface radioélectrique 5G-NR) ou une station de base ng-eNB (avec une interface radioélectrique 4G-LTE).
Pour apporter plus de flexibilité et optimiser le transport de données à très haut débit, la spécification 3GPP TS 38.804 propose une division fonctionnelle des éléments de la BBU en deux unités CU et DU.
Un nœud gNB (ng-eNb) est composé d’une unité centrale (CU, Central Unit), et d’un ensemble d’unités distribuées (DU, Distributed Unit) et d’unité radio RU (Remote Unit) ou AAU (Activa Antenna Unit). Certaines fonctions de la couche physique de bas niveau peuvent être détachées du DU et implémentées dans une unité radio distante (RU, Remote Unit).
L’interconnexion entre les différentes entités (coeur de réseau, CU, DU et tête radioélectriques) sont assurées par des liens en fibre optique.
Le réseau de transport 5G est constitué de 3 segments :
Dans les zones denses, pour éviter la saturation des stations de base, l’opérateur doit rajouter des points de transmission. La multiplication des unités radio distante nécessite le déploiement d’une infrastructure en fibre optique (RoF : Radio Over Fiber). Pour simplifier le déploiement de nouveaux points de transmission, la 3GPP propose la solution de relais radioélectrique IAB (Integrated Access Backhaul).
Dans cet article, nous allons détailler le déploiement de relais par la mise en place d’une lien radioélectrique backhaul entre la station de base initiale et les relais.
Le nœud NG-RAN est constitué de deux unités : une unité centralisée CU (Centralized Unit) et une unité distribuée DU (Distributed Unit). L’une et l’autre communiquent par une interface F1.
L’unité gNB-CU contrôle plusieurs unités DU et une unité DU n’est contrôlée que par une seule unité CU.
De par la décomposition fonctionnelle entre les données de signalisation (control plane) et les données de trafic (user plane), une station de base peut être constituée :
Figure 1 : Architecture d’un nœud NG-RAN
L’organisme de normalisation 3GPP propose plusieurs découpages fonctionnels entre les entités gérées au niveau de l’unité CU et celles gérées au niveau de l’unité DU. La figure 1 correspond à l’option 2. La figure 2 présente les 8 découpages possibles.
Figure 2 : Les options de découpage CU/DU
Cette décomposition apporte un nouveau lien entre l’unité CU et l’unité DU. Ce lien est nommé midhaul.
L’organisme de normalisation 3GPP a retenu dans un premier temps (R.15) l’option 2 avec l’introduction de l’interface F1 sur le lien midhaul entre les unités DU et CU.
Figure 3 : Le découpage fonctionnel de la station de base (Nokia)
Le lien fronthaul est la connexion entre l’unité de bande de base (BBU) et la tête radioélectrique déportée (RRH). Ce lien s’appuie sur une connexion en fibre optique. Différents protocoles d’interfaces de réseau fronthaul ont été spécifiés comme le protocole OBSAI et le protocole CPRI. Le protocole CPRI est apparu en 2003 pour connecter les stations de bases BBU aux têtes radioélectriques déportées RRH. Le lien CPRI est mis en œuvre pour l’interconnexion entre le RRU et le BBU 4G et 5G-NSA. Il s’agit de l’option 8.
L’arrivée de nouvelles technologies antennaires comme le massive MIMO permet d’augmenter considérablement les capacités de transport sur l’interface CPRI. Pour réduire cette forte augmentation en débit, le protocole eCPRI, défini en 2017, réduit cette tension en débit de transmission grâce à une décomposition fonctionnelle plus flexible de la partie BBU. Le protocole eCPRI identifie trois plans nécessaires à l’interaction entre l’équipement radioélectrique eRE et l’équipement de contrôle eREC. Ces trois plans sont les suivants : le plan utilisateur, le plan de synchronisation, et le plan de contrôle et gestion. La synchronisation est essentielle pour le mode de duplexage temporel.
La flexibilité est aussi apportée par les fonctions de virtualisation réseau NFV. Les 8 options peuvent facilement se déployer par la virtualisation de l’accès radioélectrique (V-RAN) : Les entités fonctionnelles de l’unité DU et/ou de l’unité CU peuvent être intégrées à l’entité physique RU, l’entité physique DU peut être combinée à l’entité physique CU, ou bien chaque entité matérielle peut fonctionner de manière indépendante à des emplacements séparés. Dans chacun de ces cas, le backhaul fournit toujours le lien établissant la connexion au backbone.
Le terme crosshaul (ou x-haul, ou xhaul) désigne indépendamment lien fronthaul, midhaul ou backhaul.
Figure 4 : Différentes options du découpage fonctionnel de la station de base
En Juin 2018, l’alliance O-RAN a été créée pour standardiser l’interconnexion des différentes interfaces en fonction des 8 découpages proposés. Le but est de permettre la migration des entités du réseau d’accès radioélectrique indépendamment du ou des fournisseurs.
Si la fibre optique est le média de transport favorisé, la densification des stations de base consécutive à l’exploitation des bandes millimétrique pose le problème de connectivité entre les nouvelles antennes et le cœur de réseau.
Pour résoudre ce problème et pour réduire les couts de déploiement (CAPEX), le standard 3GPP propose (dans la spécification R.16) la mise en place d’une solution de connectivité IAB (Integrated Access Backhaul), se substituant ainsi à la solution sur Fibre Optique pour le réseau d’accès.
L’Internet Des Objets
Selon l’étude de marché menée par Statista en 2018 [1], plus de 75 milliards d’objets seront connectés à Internet en 2025, soit deux fois plus qu’en 2021 (35 milliards d’objets connectés).
Un grand nombre d’objets seront connectés via un réseau bas débit et faible coût, comme LoRaWAN, SIGFOX, ou à travers les réseaux cellulaires (LTE-M/NB-IoT).
En 2009, Christophe Fortet et Ludovic Le Moan ont créé la société SIGFOX pour le marché M2M.
Dans le secteur des objets connectés, SIGFOX est le premier à s’être positionné comme Opérateur IoT en déployant son propre réseau sur plusieurs continents (déploiement de l’accès radio-électrique et du cœur de réseau).
A la même année (2009) Nicolas Sornin et Olivier Seller travaillaient sur un module de transmission longue portée pour des télé-relevées (comptage eau-électricité). L’entreprise Cycleo fut rachetée par SEMTECH en 2012. Les puces SX1272 et SX1276 pour les modules LoRa et SX1301 pour la passerelle ont été produites en 2012.
En 2015, LoRaWAN est une alliance entre opérateurs (Orange, Bouygues …), équipementiers (SEMTECH, ST, …), des sociétés qui déploient des solutions de connectivités (modules radio, cœur de réseau comme Actility, Sagemcom, Birdz, Cisco).
LTE-M et NB-IoT s’appuient sur les réseaux de mobiles 4G/5G permettant ainsi d’apporter rapidement une connectivité mondiale.
Les premiers marchés nécessitant des solutions de connectivités longue portée, faible cout et consommant peu d’énergie (LPWAN : Low Power WAN) ont été la collecte de données pour la gestion d’eau et d’Energie. A ce titre, VEOLIA a racheté l’activité Energie de la start-up Actility, complétant ainsi son activité de télé-relevé (Smart-City et environnement urbain) qu’elle réalise avec la société Birdz (exemple pour la gestion des déchets).
En 2020, l’IoT s’est positionné sur le marché de suivi de marchandise (tracker) afin d’améliorer les process logistique et afin de réduire la durée d’approvisionnement.
Ainsi, dans le cadre du suivi de la préservation des vaccins Covid réalisé par Pfizer et Moderna, nécessitant une congelation à -70°C pour Pfizer et -20°C pour Moderna, les laboratoires ont mis en place une procédure de suivi des vaccins pour suivre l’acheminement (GPS/NFC) avec un suivi de la température. Les solutions LoRaWAN et 5G ont été écartées (difficulté de roaming) pour retenir la solution NB-IoT.
L’Internet des Objets Industriel (IIoT), qui est la base de l’Industrie 4.0 (Smart Factory) fournit également une connectivité pour les usines intelligentes, aux machines, aux systèmes de gestion, et à la logistique/approvisionnement.
Ce blog étant consacré aux réseaux cellulaires, je n’aborderai que les solutions portées par les réseaux cellulaires. Néanmoins, pour ceux(celles) qui sont intéressé(e)s par le fonctionnement de LoRa et LoRaWAN, contactez moi
[1] https://www.statista.com/statistics/471264/iot-number-of-connected-devices-worldwide/
Les opérateurs proposent la 5G sur la bande de 3,5 GHz et sur la bande 2,1 GHz.
A partir de 2022, la bande de 26 GHz devrait également être utilisée.
La bande 3,5 GHz est déployée pour répondre à la croissance du trafic de données (ARPU 50 % par an) ce qui à terme va générer des congestions au niveau des stations de base dans les zones urbaines denses. Les opérateurs interrogés évoquent un manque de ressources attendu vers 2022 en France, avec un risque de baisse de la qualité de service pour l’utilisateur.
La bande de 2,1 GHz permet d’avoir une meilleure couverture par rapport à la bande de 3,5 GHz.
La bande 26 GHz, caractérisée par une faible propagation et une mauvaise pénétration à l’intérieur des locaux, sera déployée dans un second temps pour couvrir des zones limitées à fort trafic (hot spot)
probablement majoritairement pour les entreprises (usines 4.0, …) et marginalement pour le grand public (par exemple stades ou terminaux de transport).
Carte de déploiement de la 5G
SFR est le premier opérateur à avoir commercialisé son réseau 5G avec plus de 120 communes couvertes dont la liste est communiquée par communiqué de presse.
La couverture de SFR en temps réel est affiché sur son site.
Le 3 décembre 2020, Orange a lancé son réseau 5G dans une quinzaine d’agglomérations regroupant plus de 160 communes. La liste des villes est accessible sur le lien d’Orange.
Le 10 décembre 2020, Bouygues Telecom annonçait plus de 1000 communes couvertes dont 67 villes de plus de 50 000 habitants. L’opérateur propose une carte du déploiement de la 5G sur son site.
Quant à Free, le lancement est prévu pour le 15 décembre et propose d’ouvrir plus de 12000 sites en 5G, soit deux fois plus que les autres opérateurs.
Le choix des fréquences des opérateurs
Les bandes de fréquences acquises par les opérateurs sont présentées dans l‘article précédent.
Free dispose de 12000 site dans la bande de la 5G. Free s’appuie donc sur les sites actuellement 4G pour partager le spectre entre 4G et 5G. Cela signifie donc que la couverture 5G de Free sera la plus importante, mais les débits seront identiques à ceux de la 4G.
On trouve parfois le terme de fausse 5G lorsque l’opérateur utilise les bandes de la 4G pour faire de la 5G (700 MHz, 800 MHz, 900 MHz, 1,8 GHz, 2,1 GHz, 2,6 GHz).
Les attributions sont neutres technologiquement cela veut dire que Les bandes de fréquences déjà utilisées par les réseaux mobiles ouverts au public pourraient aussi être utilisées pour l’introduction de la 5G puisque ces bandes de fréquences ont été définies par les instances de standardisation et que les autorisations d’utilisation de fréquences délivrées sont donc neutres technologiquement.
Les autres opérateurs ont déployés des sites à 3,5 GHz et proposent de la vraie 5G. On dénombre plus de 1000 sites 5G à 3,5 GHz
Néanmoins SFR et Bouygues ont de plus commencé à utiliser la bande de 2.1 GHz car celle-ci offre un bon compromis entre couverture et débit. Il faut savoir que SFR et Bouygues ont également un accord de RAN Sharing (Le partage de réseau d’accès radioélectrique : accord CROZON). Au 1er décembre SFR et Bouygues ont l’autorisation d’activer la 5G sur plus de 5000 sites.
Le partage de la bande 4G et 5G est réalisé de manière dynamique par la station de base via la technique DSS (Dynamic Spectrum Sharing).
La 5G NSA s’appuie sur une station de base 4G couplée avec une station de base 5G. La 4G est la station de base maitresse. Les opérateurs ont choisi la bande à 700 MHz pour les sites 4G/5G. La bande de 700 MHz peut également être utilisée pour partager l’interface 4G/5G.
Dans le principe, la bande à 3,5 GHz est utilisée comme la bande 5G pour le trafic bidirectionnel et la bande de 700 MHz ou 2100 MHz est utilisée comme un lien Uplink (SUL : Supplementary UpLink).
Dans les faits, la bande à 3,5 GHz ou 700 MHz peut être utilisée comme noeud secondaire.
Ainsi la carte de déploiement est la suivante (cf site ANFR) :
Entre les différents opérateurs :
Sur les bandes de fréquences 5G
Le 12 novembre 2020, l’ARCEP a attribué les bandes de fréquences 3.5 GHz aux différents opérateurs (figure 1).
Figure 1 : La répartition des fréquences 5G
Une seule bande est représentée car la bande de fréquence 5G à 3.5 GHz utilise une méthode de duplexage en temps (TDD).
La méthode de duplexage TDD a deux principaux avantages :
La répartition des slots proposée par l’ARCEP suit la recommandation ECC 20(03), adoptée en octobre 2020. Cette recommandation limite le nombre de trames 5G aux deux formats suivants :
D pour Downlink, U pour Uplink, S est une sous-trame spéciale permettant la commutation du sens de transmission D vers U.
Le premier choix présente l’avantage d’une compatibilité avec la structure de trame LTE utilisée par les réseaux français.
Le deuxième choix n’est pas compatible avec le LTE.
Ces deux trames, incompatibles entre elles, vont nécessiter de nouvelles fonctionnalités pour éviter les brouillages aux frontières comme le « DL Blanking ».
Figure 2 : Les modes de duplexage en Europe
La solution « DL symbol blanking » consiste à neutraliser les intervalles de temps (sous-trames) d’émission des stations (« D ») lorsque ces sous-trames sont simultanés avec les créneaux de réception (« U ») du réseau voisin. Il faut pour cela que les opérateurs partagent la même horloge (UTC +/- 1.5µs) et alignent chaque début de trame.
La figure ci-dessous illustre cette solution pour les deux trames retenues pour l’instant. Les trames originelles sont tout en haut et tout en bas de la figure. Dans les trames adaptées, au centre de la figure, les émissions « D » sont supprimées (en rouge) lorsqu’elles coïncident avec la réception « U » dans le pays voisin.
Figure 3 : La gestion des interférences entre pays
Si la bande 3,5 GHz est définie comme la vrai 5G, les opérateurs peuvent également utiliser la bande de 2,1 GHz. Celle-ci ne dispose cependant pas d’une largeur de bande suffisante pour apporter les mêmes débit que la 5G. Toutefois, la couverture et la pénétration indoor est meilleure par rapport à la bande de 3.5 GHz.
Voici la troisième et dernière partie
E2E Network Slicing : le découpage du réseau de bout en bout (Partie 1)
E2E Network Slicing : le découpage du réseau de bout en bout (Partie 2)
IV) La virtualisation de l’accès radio
IV-1) Description des fonctionnalités de la station de base
Le découpage du réseau est une tranche de bout en bout comme le montre la figure 13.
Figure 13 : Le découpage du réseau de bout en bout.
Les fonctionnalités réseaux sont partagées au niveau du cœur de réseau (SNI CN) et de l’accès radioélectrique (SNI RAN). Nous allons maintenant nous intéresser au découpage sur l’infrastructure radioélectrique et à la gestion de ressources.
Une station de base 5G réalise les tâches suivantes :
Pour réaliser ces tâches, la station de base s’appuie sur la pile protocolaire présentée sur la figure 14. La station de base 5G peut également se décomposer en deux unités : une unité centralisée gNB-CU et une unité distribuée gNB-DU).
Figure 14 : Présentation de la pile protocolaire de la station de base 5G
La spécification 3GPP propose le découpage du plan de contrôle (RRC) et du plan de trafic IP (SDAP). La signalisation et les données sont gérées par la couche de niveau 2 décomposée en trois sous-couches : PDCP, RLC, MAC et par la couche physique.
La couche physique réalise la modulation et la démodulation de données des signaux sur l’interface radioélectriques.
Le rôle de la sous-couche MAC est de faire :
Le rôle de la sous-couche RLC est de faire :
Le rôle de la sous-couche PDCP est de faire pour le plan utilisateur :
Le rôle de la sous-couche SDAP est :
Le partage de la station de base gNB en deux unités gNB-DU et gNB-CU est spécifié par le standard 3GPP lequel propose différentes options. Toutefois actuellement le gNB reste mono-constructeur même en cas de découpage en deux sous unités gNB-CU et gNB-DU.
Les différentes options sont proposées sur la figure 15 :
Figure 15 : Le découpage des fonctions du gNB
A titre d’exemple, on pourrait imaginer le découpage suivant :
Figure 16 : Un découpage du gNB
Actuellement (standard R.15) l’unité gNB-CU est composée de la sous-couche RRC/SDAP et PDCP, l’unité gNB-DU est composée des sous-couches RLC et MAC et physique. Mais les autres partages de fonctions décrites sur la figure 11 peuvent virtuellement être mise en œuvre.
La couche physique a pour rôle de transférer le signal issu de la couche MAC (le bloc de transport) en un signal RF et inversement récupérer un signal RF pour l’envoyer vers la couche MAC.
La couche physique se compose de plusieurs fonctions :
Les signal RF est envoyé à l’antenne.
La tête radioélectrique déportée (RRH) correspond à la chaîne RF. Pour la 4G, l’entité eNB se composait de deux parties : BBU et RRH. Cette option est maintenue pour la 5G (option 8) toutefois, le débit du bus série CPRI (Common Public Radio Interface) qui transporte les symboles I/Q est d’autant plus élevé que :
Pour réduire le débit entre le gNB-DU et la tête radioélectrique déportée, il est également prévu de proposer un découpage au niveau de la couche physique différent (figure 17) :
Figure 17 : Les options de décomposition de la station de base gNB
Le transport des données sur les interfaces optionnelles est normalisé par le protocole eCPRI (evolved Common Public Radio Interface) et est véhiculé sur une fibre optique.
La gestion des ressources radioélectrique (protocole RRM) est réalisée par la station de base gNB. La gestion des ressources radioélectrique a pour objectif :
L’implémentation logicielle de la partie RRM n’est pas du ressort de la 3GPP, c’est pour cela qu’il n’est pas envisageable d’avoir une unité gNB-CU et gNB-DU de deux équipementiers différents.
IV-2) La virtualisation de la station de base : C-RAN
Le point de départ consiste à respecter le contrat SLA et d’apporter la QoE défini par le contrat. Ce contrat peut concerner la QoS pour un utilisateur. Toutefois, la virtualisation et l’isolation des slices permet à l’opérateur de louer les services de la station de base à des opérateurs virtuels ou à des entreprises.
Pour des entreprises privées, cela revient à mettre en place un DAS et la station de base est uniquement dédiée à l’entreprise.
Pour les opérateurs, il est possible de faire un partage de l’accès radioélectrique (Shared RAN) connecté directement au cœur réseau des différents opérateurs (MOCN : Multi-operator Core Network).
Jusqu’à présent, les stations de base étaient des entités physiques (PNF) installées au niveau de l’antenne. Ainsi, la gestion du spectre (contrôle d’admission, séquencement), la gestion des acquittements (HARQ/ARQ), le chiffrement étaient réalisés localement.
Dans le cas où l’entité est physique (PNF) alors les ressources matérielles de la station de base (CPU/RAM/Carte réseaux) doivent gérer les différents services (eMBB/mMTC pour la 4G).
Le découpage de la station de base en deux unités permet de mieux allouer les ressources matérielles aux fonctions protocolaires de la station de base. Excepté la tête radioélectrique déportée, les fonctionnalités de la station de base gNB-CU et gNB-DU sont toutes virtualisables.
La virtualisation est demandée par le support opérationnel OSS/BSS qui utilise le gabarit NST du slice pour imposer à l’orchestrateur (MANO ou ONAP) de gérer le cycle de vie dans l’instance virtuelle.
L’alliance O-RAN portée par les opérateurs propose une normalisation (figure 18) sur la gestion du slice RAN. L’orchestrateur dispose d’un contrôleur SDN nommé RIC non-RT (RAN Intelligent Controller non Real Time) permettant de configurer le déploiement, la mise en échelle ou le relâchement de la sous-instance radioélectrique par un découplage du plan de contrôle et du plan utilisateur.
Figure 18 : Le fonctionnement du Cloud-RAN
La virtualisation du RAN est réalisée en suivant le protocole NFV de l’ETSI. Nous n’aborderons pas ici les solutions OpenSource existantes (OPNFV, OpenStack, QEMU, …).
Pour l’alliance O-RAN,
La configuration des gNB permet de définir la liste des services S-NSSAI supportés par le gNB par une procédure de configuration du paramétrage des stations de base (cf. figure 8). Cette phase de provisionning est gérée au moment de la création du slice radioélectrique (figure 19).
Figure 19 : La configuration des slices supportées par les gNB
Lorsque le gNB s’active, il informe la fonction AMF de l’ensemble des slices supportés avec la localisation TAC correspondante. Si la station de base est connectée à plusieurs fonctions AMF, alors elle transmet l’information à toutes les fonctions AMF. Chaque fonction AMF l’informe en retour des services S-NSSAIs supportés par la fonction AMF.
Au niveau du gNB, le découpage entre le gNB-DU et le gNB-CU est ordonné au niveau du contrôleur RIC-near RT. Un descripteur de slice permet de définir les fonctions gérées au niveau de chaque unité (gNB-CU et gNB-DU).
Une entité gNB peut supporter plusieurs slices. Le découpage entre gNB-CU et le gNB-DU est identique pour chaque slice par contre les fonctions utilisées sur chaque sous-couches peuvent être communes ou spécifiques. Par exemple, il est possible de définir un slice pour les terminaux statiques et de désactiver la fonction handover pour ce slice.
Figure 20 : La mise en place de plusieurs slices au niveau d’un gNB
On définit ainsi le comportement attendu pour chaque sous-couche et lorsque le mobile fera une demande de connexion radioélectrique, le message RRC transmis du mobile à l’entité gNB-CU contiendra l’information S-NSSAI du slice demandé. Ainsi, lors de la connexion radioélectrique, l’entité gNB créera un context UE avec le numéro de slice correspondant (figure 21).
Figure 21 : L’identification du slice
IV-3) Exemple de C-RAN
L’objectif de la virtualisation consiste à répartir la charge sur différents serveurs en fonction de la QoE demandée. Ainsi :
En contrepartie, le fait de déporter les calculs vers le DataCenter va avoir comme incidence d’augmenter la latence, ce qui n’a aucune importante pour les terminaux IoT HLCom (High Latency Communication). En effet, la QoS pour le service IoT n’est pas la latence mais la problématique est la gestion d’un nombre très élevé de terminaux (mMTC :massive MTC).
Toutefois, le mobile n’est pris en charge que par une seule paire gNB-CU et gNB-DU, le choix du gNB-CU s’effectue par rapport aux paramétrages radioélectrique du mobile sur le module USIM (PLMN), c’est-à-dire par la sélection d’un PLMN.
La tranche de réseau par PLMN est identifiée par un indicateur de slice Slide ID NSSAI. Les slices gérés par le PLMN sont stockés au niveau du gNB-CU.
L’exemple (figure 22) ci-dessous est extraite de l’article [ferrus] :
Figure 22 : Déploiement 5G-NR
La figure présente 2 PLMN différents, PLMN#A et PLMN#B.
Le PLMN#A est géré par une entité gNB monolithique déployée sur un MEC du PoP #1 puisqu’on est sur une infrastructure légère (LW NFVI)
Le PLMN#B est géré par une unité gNB-CU qui est située sur le DC du PoP #2. L’unité gNB-CU est connectée à deux unités gNB-DU, une située sur le MEC PoP#1 et l’autre sur le MEC #PoP3.
Lorsque le mobile s’allume, il cherche le PLMN correspondant, soit le PLMN#A soit PLMN#B.
On peut supposer que le PLMN#A est dédié pour l’IoT sur une bande de fréquences à 700 MHz (@RF Carrier#1), la zone de couverture est étendue (NR Cell#1). Lorsque le terminal s’allume, il scanne une fréquence basse et cherche le PLMN #A. Une fois synchronisé, il fait une demande de connexion radioélectrique avec le gNB#1.
Le PLMN#B exploite une bande de fréquence @RF Carrier#2 sur deux cellules NR Cell#2 et NR Cell#3. Lorsque le smartphone s’allume, il scanne la bande de fréquences et une fois synchronisée il fait une demande de connexion auprès du gNB-CU. Selon sa position, il fait la demande auprès du gNB-DU du PoP#1 ou du PoP#3.
Conclusion
Le découpage du réseau en tranche est constitué de deux sous instances virtuelles (NSI), une sous-instance au niveau du cœur de réseau et une sous-instance au niveau de l’accès radioélectrique.
Le mobile est enregistré sur une seule fonction AMF mais peut activer plusieurs slice simultanément. Au niveau accès radioélectrique, le mobile est géré par un unique gNB.
La figure 23 est issue d’une documentation NoKia et réprésente le découpage du réseau 5G.
La figure 24 est issu d’une documentation Samsung et réprésente le découpage du réseau, l’orchestration de bout en bout. Ce document reprend donc l’ensemble des fonctionnalités et le découpage du réseau décrit dans cet article.
Figure 23 : Un découpage de réseau de bout en bout [Nokia]
Figure 24: Un découpage de réseau de bout en bout [Samsung]
References :
Liens 3GPP :
3GPP TS 28.530 V16.1.0 : Management and orchestration; Concepts, use cases and requirements
3GPP TS 38.300 : NR; NR and NG-RAN Overall Description; Stage 2, Release 16
3GPP TS 23.501 V16.1.0 : System architecture for the 5G System (5GS); Stage 2, Release 16
3GPP TS 29.510 V15.1.0 : 5G System; Network function repository services; Stage 3, Release 15
3GPP TS 29.531 V15.1.0 : 5G System; Network Slice Selection Services; Stage 3, Release 15
3GPP TS 28.500 : Management concept, architecture and requirements for mobile networks that include virtualized network functions, Release 15
3GPP TS 24.501 : Non-Access-Stratum (NAS) protocol for 5G System (5GS); Stage 3; (Release 16)
3GPP TS 21.915 : Release Description ; Release 15
ETSI
Article
[ferrus] R. Ferrús, O. Sallent, J. Pérez-Romero, R. Agustí , « Management of Network Slicing in 5G Radio Access Networks: Functional Framework and Information Models ».
Equipementiers
https://www.huawei.com/minisite/5g/img/gsa-5g-network-slicing-for-vertical-industries.pdf
Figure 13 : https://www.5g-ks.org/pdf/Network_Slicing_in_5GS-E2E_View-Nokia.pdf
Figure 23 : https://www.5g-ks.org/pdf/Network_Slicing_in_5GS-E2E_View-Nokia.pdf
[bws_captcha]Cet article est la suite de :
« E2E Network Slicing : le découpage du réseau de bout en bout (Partie 1)
III) La virtualisation du cœur de réseau
Les entités du cœur de réseau AMF, SMF, NEF, PCF sont des fonctions qui peuvent être virtualisées. Ces fonctions gèrent le plan de contrôle du réseau de mobiles et les performances fonctionnelles sont analysées au niveau du support opérationnel OSS (FCAPS).
L’entité UPF peut également être virtualisée, cette fonction gère le plan utilisateur. La fonction UPF possède des capacités d’aiguillage de trafic à partir de la classification de flux UL-CL (Uplink Classifier). Ainsi, la fonction UPF peut avoir le rôle de point de branchement (multi-homing), point d’ancrage de session (PSA : PDU Session Anchor) ou classificateur de flux pour définir le prochain saut. La classification de flux est une fonctionnalité supportée par la fonction UPF afin de diriger le trafic localement en fonction des filtres appliqués au trafic UE.
Le contrôle des fonctions virtuelles dans le cœur de réseau 5G est réalisé par deux fonctions nommées NSSF (Network Slice Selection Function) et NRF (Network Repository Function).
Figure 5 : Inscription d’une fonction virtuelle au niveau de la fonction NRF (TS 29.510)
Une sous-instance virtuelle est composée au minimum de fonctions AMF, SMF, PCF, NRF. L’opérateur (OSS) met en place un ou plusieurs sous réseaux virtuels SNI et peut à tout moment activer ou désactiver un sous-réseau (procédure NSI figure 3). Chaque fonction activée vient se déclarer auprès de la fonction NRF (figure 5).
Une instance de réseau permet de gérer un type de service. Le type de service est défini par la variable S-NSSAI. Le S-NSSAI contient 2 champs :
La fonction NSSF permet d’identifier les NSI. Cette fonction est configurable via une API REST.
Voici un exemple de configuration de la fonction NSSF :
https://host:port/v1/nssf/configurations/nsiprofiles
POST
Content-Type: application/json
BODY
{
« name »: « NSI001 »,
« nrfUri »: « https://nrf.bloglaunay.com »,
« nsiId »: « 1 »,
« targetAmfSets »:
[
{
« regionId »: « 01 »,
« setId »: « 001 »,
« setFqdn »: « set001.region01.amfset.5gc.mnc111.mcc208.3gppnetwork.org »
},
{
« regionId »: « 01 »,
« setId »: « 002 »,
« setFqdn »: « set002.region01.amfset.5gc.mnc111.mcc208.3gppnetwork.org »
}
]
}
Pour être plus complet, la configuration de la fonction NSSF permet aussi de diriger le choix de la fonction NRF en fonction du NSSAI demandé.
D’un point de vue opérateur : Lorsqu’une tranche de réseau est mise en œuvre, la fonction AMF peut toujours mettre à jour la configuration S-NSSAI de la fonction NSSF afin d’informer celle-ci des types de service supportés par la fonction AMF sur une zone de localisation TA.
Une fonction AMF peut gérer plusieurs tranches de réseaux S-NSSAI (il n’y a pas de limite fixée au niveau du cœur de réseau).
Figure 6 : La mise à jour de la fonction NSSF
L’entité NSSF sélectionne le (ou les) instances de réseau NSI correspondant(s) à la demande du mobile à partir du (ou de la liste des) S-NSSAI et détermine ainsi les fonctions AMF candidates correspondant spécifiquement (ou au mieux) à la demande de l’UE. Eventuellement, l’entité NSSF interroge la base de données NRF (Network Repository Function).
Figure 7 : Procédure d’enregistrement et sélection du NSI
L’entité NSSF renvoie à la fonction AMF qui l’a interrogée, la valeur NSSAI autorisée sur la zone TA et la liste des fonctions AMF candidates (figure 7).
Lorsque la station de base s’active (mise en route ou suite à une procédure de ré-initialisation), elle interroge les fonctions AMF pour connaître les tranches de réseaux (slices) supportées par chaque fonction AMF accessible comme le montre la figure 8.
Figure 8 : La déclaration des slices supportées par les fonctions AMF auprès de l’entité gNB
Si la station de base gNB était déjà en fonctionnement, alors elle est informée des modifications NSSAI apportées au niveau de la fonction AMF via le message NG Setup request (figure 9).
Figure 9 : La mise à jour des slices supportées par les fonctions AMF auprès de l’entité gNB
Lorsque le mobile s’active, il réalise une procédure d’attachement auprès d’une fonction AMF. L’attachement se fait sur une fonction AMF parmi toutes les fonctions AMF qui ont été activées par le support opérationnel OSS et accessible par la station de base gNB.
La sélection de l’entité AMF est réalisée au moment de la procédure d’attachement. Le choix est effectué à partir de l’identifiant NSSAI émis dans la requête NAS REGISTER. La station de base gNB reçoit la requête RRC qui porte le message NAS et l’indicateur NSSAI à partir duquel il sélectionne une fonction AMF. Si plusieurs fonctions AMF candidates peuvent être choisies (cf figure 8), la station de base gNB fait son choix par équilibrage de charge.
La fonction AMF sélectionnée par l’entité gNB interroge la base de données UDM pour vérifier que l’indicateur NSSAI demandé par le terminal (requested NSSAI) est accepté. L’entité UDM transmet à la fonction AMF le NSSAI autorisé pour ce client (allowed NSSAI). A partir de ce moment, la fonction AMF consulte la fonction NSSF (Network Slicing Selection Function) à partir d’une requête GET en indiquant la liste des S-NSSAI autorisés.
Si après consultation de la fonction NSSF, la fonction AMF sélectionnée initialement (appelée AMF source) par la station de base n’est pas appropriée pour les services demandés (NSSAI), alors la fonction AMF source réalise la procédure de ré-allocation de la fonction AMF.
Concernant la ré-allocation (lors de la procédure d’attachement), deux options sont possibles :
Dans le cas de l’option A (figure 10), en fonction des informations de souscription et de politique locale, la fonction AMF source décide d’envoyer la requête initiale vers la fonction AMF cible via le message Namf_Communication_N1MessageNotify portant le message NG-RAN Reroute Message.
Cependant, comme il ne peut y avoir qu’un seul point de terminaison N2 entre l’entité gNB et la fonction AMF pour un UE donné, la fonction AMF cible met à jour le point de terminaison auprès du gNB via le message NG AMF Configuration Update.
Figure 10 : Procédure de ré-allocation de la fonction AMF pour la gestion des transches de réseau du mobile UE : Option A
Dans le cas de l’option B (figure 11), en fonction des informations de souscriptions et de politique locale, la fonction AMF source décide d’envoyer le message NGAP Reroute NAS Message à l’entité gNB afin que celle-ci formule une nouvelle requête d’attachement vers la fonction AMF cible.
Figure 11 : Procédure de ré-allocation de la fonction AMF pour la gestion des tranches de réseau du mobile UE : Option B
Au niveau du cœur de réseau, le mobile s’enregistre sur une seule fonction AMF.
Le mobile peut demander à profiter de plusieurs tranches de réseaux (figure 12), les fonctions AMF, NSSF font parties des fonctions communes à toutes les tranches. Les fonctions PCF et NRF peuvent être communes ou spécifiques à une tranche de réseau.
Pour que le mobile puisse recevoir ou émettre des données, il faut mettre en place une session PDU. La session PDU est contrôlée par la fonction SMF, avec des règles PCF spécifiques.
Figure 12 : Les tranches de réseaux : Fonctions communes et spécifiques.
Il est aussi possible d’ajouter des fonctionnalités supplémentaires comme imposer la direction de trafic (trafic steering) en sortie du réseau de mobiles Gi-LAN afin d’apporter des services comme de l’optimisation vidéo, optimisation http, un cache CDN, un cache de réalité virtuelle, un détecteur de malware, une fonction parentale, un parefeu, …
Au niveau du mobile, le mobile fait une demande d’enregistrement auprès du cœur de réseau. Le mobile indique dans sa requête NAS les tranches de réseaux souhaitées (Requested NSSAI). Le requested NSSAI correspond soit au NSSAI configuré pour le PLMN (configured NSSAI), soit au NSSAI autorisé pour le PLMN (allowed NSSAI). Ce dernier (allowed NSSAI) a été récupéré lors d’un précédent enregistrement. Si le mobile n’a aucun NSSAI configuré pour le PLMN sur lequel il s’enregistre, alors il transmet l’information NSSAI configurée par défaut (Default configured NSSAI).
L’information NSSAI est configurée sur la mémoire non volatile du mobile. Il ne revient pas au standard 3GPP d’indiquer où est stockée cette information mais aux fabricants de terminaux. Le mobile peut contenir plusieurs informations NSSAI, chaque NSSAI est couplée à l’identifiant SUPI et est identifiée par le PLMN ID (cf. TS 24.501). Si on change l’identifiant SUPI, les informations NSSAI sont supprimées de la mémoire du terminal.
Dans le cas des smartphones, l’information NSSAI est configurée par défaut (Default configured NSSAI).
Dans le cas des terminaux IoT et URLCC, l’information NSSAI devrait être provisionnée afin de limiter l’impact de charge au niveau de la fonction AMF grand public lorsque les terminaux IoT s’allumeront.
Le mobile doit stocker les informations S-NSSAI du HPLMN. Si le mobile est enregistré sur un réseau visité VPLMN, le mobile doit aussi sauvegarder le NSSAI configuré pour ce VPLMN et doit faire la correspondance avec les S-NSSAI qu’il peut exploiter sur le réseau HPLMN. Le mapped NSSAI est utilisé en roaming pour faire la correspondance entre un S-NSSAI spécifique (128 à 255) du réseau H-PLMN et le S-NSSAI correspondant dans le VPLMN.
Lorsque le mobile demande l’établissement d’une session PDU, il transmet dans le message NAS l’information S-NSSAI souhaitée et des règles URSP (UE Route Selection Policy).
Le dernier paragraphe sera traité dans un autre article.
Le découpage du réseau (Network Slicing)
Au cours de cet article, nous allons décrire plus précisément le découpage du réseau de mobiles en reprenant plusieurs articles précédents sur la virtualisation et la programmation du réseau (NFV/SDN).
La vision du NFV dans cet article reprend les travaux de l’organisme de spécification ETSI et les fonctionnalités du SDN s’appuie sur le travail de l’ONF.
Ainsi, le SDN est vu comme un contrôleur de tranche de réseaux et un contrôleur du plan de transport, et le NFV gère l’allocation des ressources virtuellement (déploiement, dimensionnement et relachement).
Je remercie Antoine Mouquet (Expert 3GPP – Orange), Nicolas Bihannic (Chercheur Orange Labs) et le professeur Adlen Ksentini (Eurecom Sophia Antipolis) pour les échanges qui ont permis d’améliorer considérablement cet article.
Le déploiement d’un réseau 5G s’effectue en deux étapes :
Le découpage du réseau s’appuie sur la virtualisation du cœur de réseau et la virtualisation de l’accès radioélectrique. Le découpage de réseau est la solution permettant d’apporter une qualité de service spécifique (SLA : Service Level Agreement) pour les utilisateurs en fonction des usages suivants :
L’objectif de cet article est d’expliquer le fonctionnement du découpage du réseau (network slicing). Ce découpage doit nécessairement être mis en œuvre pour pouvoir répondre aux exigences des différents services auxquels la 5G souhaite répondre. La spécification 3GPP a normalisé à ce jour 4 catégories : smartphones (eMBB), les terminaux IoT (mMTC), les communications critiques (URLLC), les véhicules connectés (autonomes : V2X), mais les opérateurs peuvent mettre en œuvre d’autres fonctionnalités dédiées.
L’article est décomposé en quatre parties techniques :
En conclusion, nous reviendrons sur la virtualisation des fonctions du réseau et l’avantage de cette architecture.
I) Un réseau basé sur les services (SBA : Service Based Architecture)
Le réseau de 5ème génération est avant tout un réseau cellulaire devant assurer la continuité des services offerts par le réseau de mobiles 4G. Il est ainsi conçu pour répondre aux exigences des smartphones à très haut débit, et aux exigences du marché des objets connectés.
Toutefois, le réseau de mobiles 5G s’ouvre également à des applications nécessitant des latences faibles pour des communications critiques avec une convergence des marchés PMR (Private Mobile Radio), et des offres TETRA, GSM-R (voir la spécification FRMCS : Future Railway Mobile Communication System).
L’un des objectifs des spécifications 5G est de définir un déploiement automatique de fonctions réseaux afin de répondre aux différentes exigences à respecter (KPI : Key Performance Indicator) spécifique à chaque type de services à mettre en œuvre. La stratégie est de réduire le délai de la mise sur le marché d’un service Tiers players. On parle ainsi de services verticaux et pour identifier les besoins, nous allons dans un premier temps lister de manière non exhaustive un panel de secteurs :
La liste est non exhaustive, et chaque service nécessite des caractéristiques que l’on peut résumer avec les critères suivants :
Les indicateurs de performance doivent être respectés au niveau du cœur de réseau et de l’accès radioélectrique.
Figure 1 : Des exemples de services 5G
II) Description d’une tranche de réseau et mise en œuvre de la virtualisation
II-1) Définition
La spécification 3GPP défini :
La supervision d’une tranche de réseau est essentielle pour valider la qualité de service (QoS) et le respect des indicateurs de performance.
L’isolation opérationnelle de chaque tranche permet aux utilisateurs verticaux (OTT ou entreprise) de pouvoir configurer, superviser, contrôler leur tranche de réseau de manière indépendante.
L’isolation au niveau du réseau signifie que les clients verticaux ont des ressources dédiées. La description des slices permet à un utilisateur de profiter de fonctions réseaux dédiées et d’un accès radioélectrique partagé. Le client étant ici le demandeur de service auprès d’un opérateur, et l’utilisateur est celui qui utilise le service en bout de chaîne (terminal).
L’isolation opérationnelle permet donc de partager des ressources matérielles et logicielles comme des hébergeurs de cloud, en isolant les fonctions réseaux entre elles.
L’isolation au niveau réseau (figure 2) permet de proposer des ressources dédiées, à la fois au niveau du cœur de réseau, mais également au niveau de l’accès radioélectrique (RAN dédié). Des applications comme la sécurité civile ou le smart-grid peuvent nécessiter une isolation du réseau. Les réseaux PNI-NPN (Public Network Integrated Non-Public Network) sont des réseaux dédiés dont l’accès radioélectrique peuvent être partagés avec le réseau PLMN.
Figure 2 : Les ressources dédiées ou partagées du réseau de mobiles 5G
A l’instar des solutions portées par les hébergeurs cloud, il n’est pas nécessaire de déployer une tranche de réseau (slice) par client vertical, mais de partager le slice entre plusieurs clients.
II-2) Gestion d’une NSI (Network Slice Instance)
L’instance est mise en œuvre à partir d’un gabarit et la procédure de déploiement et d’activation d’un slice est défini par les étapes suivantes (figure 3, 3GPP SA5).
Figure 3 : Gestion d’un slice. De l’activation à la désactivation
La procédure (figure 3) met en œuvre les entités du réseau de mobiles 5G en gérant la durée de vie des instances à partir des fonctionnalités NFV décrites par l’organisme ETSI (se référer à l’article : http://blogs.univ-poitiers.fr/f-launay/tag/5g-nfv/).
Une tranche de réseau NSI peut contenir des fonctions réseaux physiques (PNF : Physical Network Function) ou virtuelles (VNF : Virtual Network Function).
Le réseau de transport n’est pas défini dans le cadre du travail de l’organisme 3GPP.
II-3) La virtualisation des fonctions du réseau
La figure 4 rappelle l’architecture système pour la mise en œuvre de fonctions virtuelles.
Figure 4 : L’architecture ETSI NFV
On identifie 3 groupes :
Le premier groupe est le système de gestion des réseaux de mobiles. Il est composé :
Le deuxième groupe est le système de gestion et d’orchestration des ressources matérielles et virtuelles (NVF – MANO : Management and Orchestration). Il a pour rôle :
Le 3ème groupe correspond aux machines physiques et au déploiement des instances, ainsi que les fonction de routage.
II-4) Le système de gestion des réseaux de mobiles
II-4-1) OSS/BSS et NM
La phase de préparation est réalisée au niveau du support système OSS/BSS par la fonction Gestion de Réseau (NM : Network Management) via un contrôleur de slice. On peut trouver également l’acronyme NSMF (Network Slicing Management Function). Ce dernier soumet l’ordre à un orchestrateur (à travers le point de référence Os-Ma-nfvo) qui va pouvoir gérer l’infrastructure de virtualisation à partir du modèle de slice.
Le NSMF prend en charge le déploiement du end-to-end slice. On pourrait le nommer un end-to-end slice orchestrateur.
Le gestionnaire de réseau (NM) fourni les fonctions de gestion du réseau de mobiles, ce qui inclut les fonctions de virtualisation. Le NM supporte les fonctions de gestion FCAPS (fault, configuration, accounting, performance, security) du cœur de réseau 5GC et du réseau IMS. Il supervise le FCAPS spécifique pour maintenir et exposer le SLA.
Dans le cas de la gestion de slice, c’est le gestionnaire de réseau MN qui initie la gestion du cycle de vie de chaque fonction virtuelle (figure 3).
II-4-2) EM
Le gestionnaire d’élément (EM : Element Manager) est responsable de la gestion FCAPS au niveau d’un élément logiciel VNF (Virtual Network Function) ou d’un élément matériel (NE : Network Element). Les fonctions du gestionnaire d’entité correspondent à :
Un gestionnaire d’éléments peut gérer des fonctions virtuelles à travers des interfaces propriétaires. Un gestionnaire d’éléments peut aussi être une fonction réseau virtuelle.
II-4-3) NFV-MANO
II.4.3.1) NFVO
L’orchestrateur joue un rôle primordial :
Pour gérer les services réseaux, l’orchestrateur s’appuie sur des catalogues de ressources définissant le gabarit souhaité :
II.4.3.2) VNFM
Le gestionnaire VNFM (Virtual Network Function Manager) gère :
Il expose :
II.4.3) VIM
Une infrastructure matérielle est un serveur COTS hébergeant un hyperviseur. L’infrastructure est découpée en domaine, chaque domaine porte une VM ou un containeur.
Le gestionnaire VIM gère :
Ainsi, le gestionnaire VIM gère le cycle de vie des ressources virtuelles allouées à un domaine, conserve l’appairage entre la machine virtuelle et la machine physique, analyse via un agent les performances matérielles, logicielles et virtuelles et gère les performances et les fautes.
Il expose :
II.4.4) Pour aller plus loin
Il y a une différence entre le gestionnaire d’éléments (EM) et le gestionnaire de fonctions réseau virtuelles (VNFM) : Le gestionnaire d’éléments EM supervise la partie fonctionnelle du réseau de mobiles alors que le gestionnaire VNMF gère les entités virtuelles.
L’infrastructure NFVI est décomposée en plusieurs parties :
La suite dans un autre article.