Archives du mot-clef MANO

E2E Network Slicing : le découpage du réseau de bout en bout (Partie 3)

Posté le by - 4 139 vues
2

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 :

  • fonction RRM pour la gestion de ressources radioélectriques : Contrôle du support radioélectrique, contrôle d’admission radioélectrique, contrôle de la mobilité pour les mobiles connectés, allocation dynamique des ressources radioélectriques dans le sens montant et descendant (ordonnancement) ;
  • compression d’entêtes IP, chiffrement et intégrité des données ;
  • sélection de la fonction AMF lors de l’attachement du mobile ;
  • routage des données du plan de transport dans un tunnel ;
  • routage des informations de signalisation vers la fonction AMF ;
  • établissement et libération de la connexion ;
  • mesures radioélectriques et configuration du rapport de mesures demandé au mobile ;
  • ordonnancement et transmission des informations de diffusions SIB (System Information Block);
  • marquage des paquets dans le sens montant (étiquettes DSCP) ;
  • gestion des sessions ;
  • support du découpage en tranche de réseaux ;
  • gestion de la QoS et correspondance entre les flux IP provenant du plan de transport UPF en support radioélectrique ;
  • partage de l’accès radioélectrique ;
  • gestion de la double connectivité ;
  • interfonctionnement entre les fonctions 5G-NR et 4G-LTE.

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 :

  • la correspondance entre les canaux logiques et les canaux de transport ;
  • le multiplexage/démultiplexage des unités de données MAC SDU en provenance d’un canal logique ou de plusieurs canaux de transport (TB) ou de plusieurs canaux de transport à destination des canaux logiques ;
  • la correction d’erreur rapide HARQ ;
  • la gestion de priorité entre les mobiles ;
  • la gestion de priorité sur les canaux logiques pour un mobile.

Le rôle de la sous-couche RLC est de faire :

  • le transfert des paquets PDU issu de la couche supérieure ;
  • une numérotation des séquences RLC pour le mode sans acquittement UM et avec acquittement AM;
  • la correction d’erreur ;
  • la segmentation/re-segmentation des données ;
  • la détection d’erreur (pour le mode AM).

Le rôle de la sous-couche PDCP est de faire pour le plan utilisateur :

  • la numérotation de séquence ;
  • la compression et décompression d’entête ;
  • le transfert des données ;
  • la détection des paquets dupliqués et la mise en ordre ;
  • le routage des bearer PDCP PDU dans le cas de la double connectivité ;
  • le chiffrement/déchiffrement et la protection d’intégrité;
  • le rétablissement des données PDCP et la récupération des données pour le mode RLC ;
  • la duplication des paquets PDCP PDU.

Le rôle de la sous-couche SDAP est :

  • la correspondance entre la QoS d’un flux IP et le support radioélectrique ;
  • le marquage de l’identité de la QoS sur les paquets UL.

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 :

  • code détecteur d’erreurs CRC ;
  • code correcteur d’erreur et adaptation de débit ;
  • embrouillage ;
  • modulation ;
  • affectation des symboles par sous-couches antennaires ;
  • précodage numérique ;
  • affectation des signaux et canaux sur chaque élément de ressources ;
  • transformée de Fourier Discrète et insertion d’un préfixe cyclique ;
  • chaîne RF (convertisseur CNA, conversion RF, amplification).

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 :

  • la bande de fréquence est importante (cellule principale et secondaire en cas d’agrégation de porteuses) ;
  • le nombre d’antennes est élevé (FD-MIMO ou Massive MIMO).

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 :

  • de gérer le spectre de fréquence : cette fonction décide comment les ressources spectrales sont réparties en porteuses 5G-NR et comment ces porteuses sont allouées aux différents site;
  • de gérer l’interférences entre cellules (mécanisme ICIC). Dans la continuité de la gestion du spectre, le mécanisme ICIC impose une puissance limitée sur un ensemble de sous-porteuses afin d’éviter les interférences avec un point de transmission voisin utilisant les mêmes sous-porteuses ;
  • d’ordonnancer les paquets : cette fonction décide, pour chaque porteuse 5G-NR affectée à une cellule, quelles sont les ressources bloc (RB) disponibles pour transférer les paquets sur chaque bearer radioélectrique établi ;
  • de réaliser les fonctions liées à la prise en charge radioélectrique tels que le contrôle de bearer, le contrôle d’admission radioélectrique, le contrôle de la mobilité (lorsque le mobile est en mode connecté).

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,

  • Le RIC non-RT a pour objectif le respect du SLA et de la supervision en gérant le déploiement, la mise à l’échelle ou la libération des sous-couches de virtualisations radioélectrique SNI.
  • Le contrôleur RIC near RT gère les ressources radioélectrique (fonctionnalités RRM) en proposant un découpage fonctionnel entre l’unité gNB-CU et les entités gNB-DU.

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 :

  • Pour les terminaux IoT, la station de base devant couvrir une superficie sur laquelle on peut avoir 1 million d’IoT par km2 (ce chiffre est la limite haute du standard), les ressources matérielles de la station de base peuvent rapidement saturer si, il y a un réveil en cascade des terminaux IoT, ou si plusieurs terminaux sont dans le mode RRC_Inactive, ou … Il est donc recommandé de déporter les fonctions suivantes vers un DataCenter (DC) :
    • contrôle RRC de chaque terminal IoT ;
    • chiffrement/déchiffrement ;
    • segmentation, contrôle d’erreur ARQ ;
    • multiplexage, contrôle d’erreur HARQ.

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

  • Pour les smartphones eMBB, la station de base doit offrir des services avec une latence d’environ 10 ms pour le plan de trafic et 100 ms pour le plan de transport. On peut donc envisager un découpage avec l’unité gNB-CU au niveau du point de présence (PoP) sur lequel l’opérateur déploie des lames de serveurs (mini Data Center nommé MEC – Multi-access Edge Computing). Ainsi :
    • l’entité gNB-CU gère la couche RRC/PDCP haute ;
    • l’entité gNB-DU au niveau de la station de base gère les sous-couches PDCP base, RLC, MAC et physique.
  • Pour les communications critiques (URLLC et V2X), afin de réduire la latence, tout le traitement du gNB s’effectue au niveau local (près de l’antenne).

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

  • http://www.3gpp.org/ftp//Specs/archive/38_series/38.300/38300-g10.zip

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)

  • http://www.3gpp.org/ftp//Specs/archive/24_series/24.501/24501-g41.zip

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

https://www.opennetworking.org/images/stories/downloads/sdn-resources/technical-reports/onf2015.310_Architectural_comparison.08-2.pdf

Equipementiers

  • Huawei : 5G Network Slicing for Vertical Industries
  • Huawei : 5G Network Slicing for Cross Industry Digitization Position Paper
  • Nokia : Network Slicing in 5GS E2E
  • Samsung

 

https://www.huawei.com/minisite/5g/img/gsa-5g-network-slicing-for-vertical-industries.pdf

http://www-file.huawei.com/-/media/CORPORATE/PDF/white%20paper/5G-Network-Slicing-for-Cross-Industry-Digitization-Position-Paper.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

Figure 24 : https://images.samsung.com/is/content/samsung/p5/global/business/networks/insights/white-paper/network-slicing/200420_Samsung_Network_Slicing_Final.pdf

E2E Network Slicing : le découpage du réseau de bout en bout (Partie 1)

Posté le by - 6 561 vues
Répondre

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 :

  • La première étape est le déploiement d’un accès radioélectrique 5G. La 5G-NSA est la 5G non autonome. Pour le déploiement à venir (5G NSA option 3), le cœur de réseau est le réseau 4G (EPC) et l’accès radioélectrique 5G est contrôlé par une station de base 4G grâce au mécanisme de double connectivité ;
  • La deuxième étape est nommée 5G-SA, il s’agit de la 5G autonome. Le cœur de réseau est entièrement 5G permettant ainsi d’apporter de la souplesse du cœur de réseau en exploitant la virtualisation des fonctions réseaux.

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 :

  • les usagers de smartphone ;
  • les entreprises ;
  • des processus verticaux (IoT) ;
  • le marché de gros (wholesale business).

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 :

  1. la description d’un réseau basé sur les services et identifications des services ;
  2. la description d’une tranche de réseau et mise en œuvre de la virtualisation ;
  3. la virtualisation du cœur de réseaux ;
  4. la virtualisation de l’accès radioélectrique.

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 réalité augmentée et la réalité virtuelle : l’humain interagit avec son environnement nécessitant une latence de 7 à 15 ms, un débit de 250 Mbps (3D/ 12k) à 2.34 Gbps pour de la 3D 24 k et une perte de paquets de 10-6; Le Wi-VR (Weak Interactive VR) peut nécessiter une latence RTT de 10 ms (Ultimate VR) ;
  • Le secteur de l’automobile avec des connectivités pouvant gérer des services de loisir (Infotainment), de télématique (IoT), de sécurité routière (partage d’informations, assistance à la conduite, conduite coopérative, gestion d’une file de camions (platooning), opération à distance) ;
  • Le secteur de l’énergie et du smart-grid (latence < 10 ms, disponiblité de 99,999% et un TEB de 10-9) ;
  • Le secteur de la santé (tracking de patient ou de matériel, soin à distance, soin en urgence) avec le téléchargement d’imagerie radio jusqu’à la télé-chirurgie ;
  • Le secteur de l’industrie 4.0 (smart factory) : automatisation du processus de fabrication, logistiques, maintenance prédictive, systèmes cyber-physiques (C2C : Control To Control Communication), robots mobiles;
  • Le secteur de l’IoT avec la technologie LPWAN qui permet à titre d’exemple la gestion des déchets, le suivi des mobiles, la mesure de consommation (gaz, électricité, eau, …), la détection de fuite, le parking intelligent ;
  • La sécurité publique (Push To Talk, vidéo, …) répondant aux exigences du réseau TETRA;
  • Le secteur du smart-cities (lampadaire intelligent, sécurité publique par détection de bruit).

La liste est non exhaustive, et chaque service nécessite des caractéristiques que l’on peut résumer avec les critères suivants :

  • latence ;
  • débit ;
  • sécurité de la communication;
  • mobilité ;
  • localisation ;
  • accessibilité ;
  • disponibilité ;
  • résilience ;
  • densité de connexion.

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 :

  • Un modèle d’une tranche de réseau (Network Slice Template). Le NST est une description complète d’une tranche de réseau en listant les fonctions virtuelles, les ressources matérielles nécessaires pour chaque fonction en vue de gérer le plan de trafic de bout en bout. Ce modèle sert de référence pour instancier une tranche de réseau ;
  • Une instance de tranche de réseau (NSI : Network Slice Instance) correspond aux entités du réseau de mobile qui répondent aux indicateurs de performances demandés par le support opérationnel et fonctionnel (OSS/BSS). Une entité est une ressource matérielle et une fonction logicielle déployée au moment de la création de l’instance. Afin de simplifier le réseau de mobile, chaque instance se décompose de sous-instance (SNI : Sub Network Instance) qui sont partagées. Ainsi, une instance de tranche de réseau est composée d’une sous-instance RAN (Radio Access Network), d’une sous-instance de cœur de réseau 5G CN (Core Network). Une sous-instance SNI peut appartenir à plusieurs instances de tranche de réseau ;
  • Un support opérationnel et de supervision. Afin de s’assurer que les indicateurs de performances soient respectés à tout instant, la tranche de réseau (NS : Network Slice) contrôle l’instance de tranche de réseau (NSI) à partir de fonctions de gestion et de supervision. La supervision permet d’alerter le contrôleur si les performances se dégradent et le contrôleur va pouvoir gérer de nouvelles entités ou mettre à l’échelle une ou plusieurs entités (scalability and elasticity).

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é :

  • d’un support système OSS (Operation Support System). Le support OSS est une suite logicielle permettant d’administrer le réseau opérateur et de superviser les ressources. Le support OSS maintient un inventaire des entités réseaux, provisionne des services, configure les entités et récupère les éléments de supervision de chaque entité réseau ;
  • d’un support commercial (Business Support System). Le support BSS gère le déploiement de services à la demande des clients. Il offre ainsi les outils logiciels pour gérer les commandes jusqu’à la mise en paiement des services.
  • D’un support de gestion et de supervision (EM/DM). La gestion EM/DM permet de contrôler et de superviser les fonctions virtuelles et les ressources matérielles.

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 :

  • sous l’ordre du support système OSS, l’orchestrateur MANO ordonne le déploiement ou la libération de fonctions virtuelles en respectant les contraintes matérielles inhérentes à chaque fonction ;
  • de superviser le bon fonctionnement des fonctions logicielles et des ressources matérielles allouées ;
  • de contrôler le déploiement de machines virtuelles ou de containeurs, de vérifier l’allocation de ressources et de libérer les ressources ;
  • de conserver des contextes sur les ressources utilisées, les ressources restantes, les images des fonctions virtuelles et les gabarits de chaque fonction virtuelle.

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 à :

  • la gestion de fautes;
  • la gestion de la configuration ;
  • la gestion des éléments de facturation ;
  • la collection des mesures de performance à effectuer ;
  • la gestion des éléments de sécurité.

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 :

  • Il gère l’orchestration de ressources : il coordonne l’attribution des ressources matérielles : l’orchestrateur autorise, met à l’échelle, libère les ressources physiques (NFVI : Network Function Virtualization Infrastructure) parmi l’ensemble des DataCenters (DC). Il ordonne les ordres au gestionnaire de ressource matérielle (VIM : Virtualized Infrastructure Manager) à travers le point de référence Or-Vi ;
  • Il gère l’orchestration de service : il contrôle l’établissement ou la libération d’une ou plusieurs fonctions virtuelles VNF en ordonnant l’ordre au gestionnaire VNFM via l’interface Or-Vnfm.
  • il gère la topologie des NSI (nommé VNF Forwarding Graph dans l’article : http://blogs.univ-poitiers.fr/f-launay/2018/02/04/network-functions-virtualisation-nfv-pour-le-reseau-4g5g/)

Pour gérer les services réseaux, l’orchestrateur s’appuie sur des catalogues de ressources définissant le gabarit souhaité :

  • Catalogue VNFD contient le descripteur de chaque instance VNF en terme de déploiement et de fonctionnement (pour la gestion FCAPS) ;
  • Catalogue de service permet de lister l’ensemble des fonctions VNF à cascader pour obtenir un sous réseau d’instances (SNI) ;
  • Catalogue NFVI contenant les ressources nécessaires pour mettre en œuvre un service NFV.

II.4.3.2) VNFM

Le gestionnaire VNFM (Virtual Network Function Manager) gère :

  • Le cycle de vie des fonctions virtuelles VNF : création, mise à l’échelle, maintenance et libération des instances VNF ;
  • Supervise et détecte les fautes (FCAPS) des fonctions virtuelles VNF.

Il expose :

  • une interface nord à l’orchestrateur à travers le point de référence Or-Vnfm ;
  • une interface sud pour injecter des règles au gestionnaire de ressource à travers le point de référence vi-Vnfm.

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 :

  • les ressources des infrastructures NFVI (stockage, CPU, carte réseau, …) d’un domaine ;
  • les ressources virtuelles (machines virtuelles et/ou containeur) du domaine ;
  • l’hyperviseur.

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 :

  • une interface nord à l’orchestrateur à travers le point de référence Or-Vi ;
  • une interface nord au gestionnaire de machine virtuelle VMF à travers le point de référence vi-Vnfm.

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 :

  • les ressources matérielles : CPU, mémoire RAM, carte réseau. Un commutateur (exemple TOR) et un élément de stockage fait également parti des ressources matérielles ;
  • la couche de virtualisation : Cette couche permet de faire abstraction des ressources matérielles en offrant des ressources logiques. Cette abstraction est réalisée par l’hyperviseur.

La suite dans un autre article.

 

 

 

 

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

Posté le by - 11 339 vues
4

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.