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

L’agrégation de porteuses sur les bandes licenciées et non licenciées

3.1. Principe d’agrégation de porteuses pour le LTE-Advanced

En théorie de l’information, le débit maximum de transmission à travers un canal de communication dépend de la bande de fréquence B utilisée et du rapport signal sur bruit (SNR : Signal Noise Ratio). Le théorème de Shannon-Hartley donne une limite maximale C pour bruit gaussien :

C=B.log2(1+SNR)

(la démonstration mathématique à partir de la théorie du signal se trouve facilement sur Internet)

La bande de fréquence B utilisée par le LTE est au plus égale à 20 MHz. L’agrégation de porteuses (Carrier Aggregation ou CA) permet d’atteindre des débits de transmission beaucoup plus rapides en augmentant la bande de fréquence.

L’agrégation de porteuse est une fonctionnalité qui est apparue avec le LTE-Advanced (LTE-A R.10), pour le mode duplex FDD ou TDD (Frequency Division Duplex, Time Division Duplex).

Avant la R.10, les terminaux de catégorie 1 à 5 étaient mono-porteuse sur une bande comprise entre 1.4 MHz et 20 MHz. Les premiers tests d’agrégation de porteuses ont été réalisés sur des terminaux de catégorie 4 et sur deux bandes de 10 MHz. Les terminaux de catégorie 6 sont disponibles depuis 2014, et permettent d’atteindre des débits de 300 Mbps (en DownLink DL) en supportant deux bandes de 20 MHz. Les terminaux de catégories 9 disponibles à la vente depuis 2015 supportent 3 bandes de 20 MHz, ce qui permet d’atteindre un débit de 450 Mbps. Les terminaux de catégories 4, 6 et 9 possèdent 2 antennes et supportent la modulation 64 QAM sur le lien descendant. Pour ces terminaux, une bande de 20 MHz correspond à un débit de 150 Mbps. En pratique, pour un opérateur qui disposerait un total de 45 MHz sur 3 bandes différentes pourrait proposer un débit maximal descendant de 337.5 Mbps avec ces catégories de terminaux.

On peut ainsi définir une première classification des catégories de terminaux en vente en 2017 en fonction du nombre de canaux de fréquences supportés :

Tableau 2.1. Catégories de terminaux définies dans la R.10 et R.11

Le LTE-Advanced étend l’agrégation de porteuses à 5 canaux, portant à 100 MHz la bande maximum. L’UE de catégorie 8 (également défini dans la R.10) supportera cette fonctionnalité.

Dans les R.10 et R.11, le nombre de porteuses pour le lien montant est inférieur ou égal au nombre de porteuses pour le lien descendant.

Dans la R.12, les UE peuvent réaliser de l’agrégation de porteuses en mode TDD et conjointement en mode FDD. La R.12 propose 80 combinaisons de deux porteuses et quelques combinaisons de trois porteuses.

La R.13 ajoute de nouvelles combinaisons de porteuses pour 2, 3, 4 et 5 porteuses et étend la combinaison avec les bandes WiFi. La R.13 a normalisé 492 combinaisons de porteuses pour l’agrégation de deux bandes, 248 combinaisons sur 3 bandes, 56 combinaisons pour 4 bandes et 2 combinaisons pour 5 bandes.

3.2. Mécanisme d’agrégation de porteuses

Le principe consiste à augmenter la bande utilisée par le mobile pour accroitre son débit, on nomme Component Carrier (CC) chaque bande agrégée. L’UE est connecté avec un seul eNb, l’eNb dispose de plusieurs bandes de fréquences contiguës ou disjointes.

Après avoir décrit les fonctionnalités de l’Agrégation de porteuses, nous allons maintenant étudier son mécanisme.

En mode de veille, l’UE écoute les informations émises par l’eNb (canal balise, paging) sur la bande de fréquence spécifique à la cellule. Si l’UE doit émettre ou recevoir des données, il doit passer en mode connecté (RRC Connected). L’UE pouvant exploiter plusieurs bandes de fréquences, on différencie la PCC (Primary Component Carrier) correspondant à la bande sur laquelle l’UE échange la signalisation NAS et les données avec l’eNb (PCell : Primary Cell) et le(s) SCC (Secondary Component Carrier) les bandes sur lesquelles l’UE échangent les données avec les autres cellules (SCell : Secondary Cell). Les paramètres de la cellule primaire et des cellules secondaires sont configurés au niveau RRC. Ainsi, la PCC est modifiée uniquement par une procédure de Handover et les SCC peuvent être dynamiquement activées et désactivées par des nouvelles requêtes RRC. Dans le cadre du CA, l’UE ne dispose que d’une seule connexion RRC avec l’eNb.

Figure 3.1. Impact de l’agrégation de porteuses sur l’interface radio

Toutes les SCC sont considérées comme des ressources de transmission additionnelles. Les couches Physique et la couche MAC sont les deux couches impactées par la CA (Figure 2.1), avec de nouvelles requêtes RRC :

  • La couche Physique réalise la transmission d’un bloc de transport (TB), la retransmission rapide des paquets erronés via le mécanisme HARQ est réalisée sur chaque CC.
  • L’allocation de ressources est réalisée sur le canal PDCCH. Dans le cas de l’agrégation de porteuses, soit le PDCCH de chaque cellule assigne les ressources pour sa cellule (self scheduling), soit un seul PDCCH assigne les ressources pour toutes les cellules (PCell et SCell). Ce scénario se nomme Cross Carrier Scheduling.

Figure 3.2. Séquencement avec et sans cross scheduling

La couche MAC multiplexe les données issues de la couche PDCP et RLC sur les différentes porteuses.

La signalisation relative à l’agrégation de porteuses est donc transparente pour le protocole de convergence des paquets de données (PDCP) et pour la couche de contrôle des liaisons radio (RLC).

L’UE doit en retour émettre un acquittement pour chaque HARQ. Dans la R.10, le lien étant asymétrique, l’UE doit pouvoir, sur le canal montant, transmettre les acquittements (ACK/NACK) de chaque HARQ ainsi que des mesures du lien radio (CQI, PMI, RI). Le PUCCH de format 3 permet de compiler les informations.

Concernant le lien montant, l’UE doit émettre ses données avec un temps d’avance (TA Timing Advanced) afin de compenser la durée du trajet de l’onde Radio et assurer ainsi une synchronisation avec la trame en réception de l’eNb. Lorsque l’UE réalise de l’agrégation de porteuse, les antennes de réception (RRH) peuvent être déportées (se référer au chapitre 1), et le temps de trajet n’est donc pas identique sur chacune des porteuses. Si la R.10 ne gère le TA que pour la Pcell, la R.11 permet d’appliquer des TA différents selon la bande de fréquence.

Cours IUT – Chap 1 (Part 2)

L’architecture du réseau de mobiles 4G

Suite de l’article précédent

1.2. L’architecture protocolaire

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

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

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

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

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

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

1.2.1 L’interface LTE-Uu

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

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

Le protocole RLC opère dans trois modes :

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

La couche RLC effectue les opérations suivantes :

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

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

Le couche MAC assure les fonctions suivantes :

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Références

1 : Livre LTE-Advanced Pro

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

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