Archives de l’auteur : flaunay

La Mutualisation de l’accès radio : RAN SHARING

Posté le by - 438 vues
Répondre

Je remercie Rafika Rezgui (responsable New Deal Bouygues Télécom ) et Hugues-Antoine ROUSSILLO (Chef de projet Programme Réglementaire Bouyues Télécom) pour la relecture et les explications fournies qui ont contribuées à l’amélioration de l’article.

I) La mutualisation du RAN – RAN SHARING

L’architecture des réseaux de mobiles fait une séparation entre le réseau d’accès radio (RAN Radio Access Network) et le cœur de réseau (CN : Core Network).

Le partage du réseau (Network Sharing) a pour objectif de réduire les coûts de déploiement en partageant une partie du réseau entre opérateurs.

Selon la définition de l’ARCEP [1]: le partage de réseaux mobiles correspond à la mise en commun entre plusieurs opérateurs de tout ou partie des équipements constituant leurs réseaux mobiles.

 On distingue ainsi plusieurs solutions sur le partage de l’accès radio :

  • Location de site (Tower Companies)  nommée partage d’infrastructure passive : chaque opérateur installe ses équipements actifs (antennes mobiles) sur une infrastructure passive partagée (pylône) ;
  • La mutualisation active des réseaux (RAN Sharing)
    • Avec partage de fréquences MOCN (Multi-Operator Core Network) : la station de base (ou le cœur d’accès radio) est connectée au cœur de réseau de plusieurs opérateurs et les porteuses de fréquence de chaque opérateur sont combinées. Les clients d’un opérateur peut donc accéder à l’ensemble des fréquences de l’ensemble des opérateurs [2]
    • MORAN (Multi-Operator RAN) : La station de base est partagée entre plusieurs opérateurs mais chaque opérateur dispose de sa propre bande de fréquence. Les équipements mis en place par un des opérateurs émettent les fréquences des autres opérateurs mais chaque client n’a accès qu’aux fréquences de son opérateur. (exemple : Accord Crozon entre SFR et Bouygues)
  • Full MVNO ou itinérance : un opérateur loue et utilise les fréquences d’un autre opérateur hôte qui accueille sur son réseau ses clients
  • L’architecture GWCN (Gateway core network) pour laquelle plusieurs opérateurs partagent l’accès RAN et l’entité MME. L’entité MME doit évidemment supporter l’option RAN Sharing et doit pouvoir délivrer une liste de restriction d’eNB pour la continuité d’appels HO (Handover).

Figure 1 : La mutualisation du réseau de mobiles [1]

II) Exemple du New Deal

L’accord New Deal est un engagement imposé par le gouvernement aux opérateurs Français pour avoir une bonne couverture du réseau mobile. Cet engagement est encadré par l’ARCEP qui définit La notion de « bonne couverture ».

Une bonne couverture permet de téléphoner et d’échanger des SMS à l’extérieur des bâtiments dans la plupart des cas, et, dans certains cas, à l’intérieur des bâtiments (cf. https://www.arcep.fr/cartes-et-donnees/nos-cartes/la-couverture-4g-en-france-par-departement.html)

Le New Deal s’appuie sur la mutualisation radio (RAN SHARING). Le « New Deal » a pris la forme d’un « gentlemen’s agreement » matérialisé dans un échange de lettres, suivies d’annonces.

Le new deal utilise la mutualisation de l’accès radio (RAN Sharing) avec partage de fréquence (MOCN) ou sans partage de fréquence (MORAN).

La mutualisation MOCN est favorisée dans les zones blanches et la mutualisation MORAN dans les zones moins denses. Toutefois, Hugues-Antoine ROUSSILLO précise : « en cas de charge, la bande passante est limitée à ¼ des ressources par opérateur en MOCN ».

III) Les évolutions du spectre radiomobile

A partir de 2024, les plans de fréquences à 900 MHz, 1800 MHz et 2100 MHz seront équilibrés entre les opérateurs (suivant [3]) :

Tableau 1 : Bande de 900 MHz

Tableau 2 : Bande de 1800 MHz

Tableau 3 : Bande de 2100 MHz

Notes 

Le NB-IoT ne supporte pas le RAN SHARING (jusqu’à la R.17)

 

Références

[1] https://www.arcep.fr/la-regulation/grands-dossiers-reseaux-mobiles/le-partage-de-reseaux-mobiles.html

[2] Rapport de la cours de comptes : Réduire la fracture numérique mobile (Juin 2021) : https://www.ccomptes.fr/sites/default/files/2021-09/20210928-58-2-reduire-fracture-numerique-mobile-4G.pdf

[3] Décision n° 2018-1306 du 23 octobre 2018 : https://www.legifrance.gouv.fr/jorf/id/JORFTEXT000038057322

Déploiement de la 5GC

Posté le by - 463 vues
Répondre
  1. Architecture du cœur de réseau 5GC

Le cœur de réseau 5GC est déployé selon l’architecture a 3 niveaux :

  • les instances des fonctions réseaux sont exécutées au sein de DataCenter central
  • un Datacenter régional avec le plan de trafic
  • un Datacenter de proximité (Edge Datacenter) avec le MEC et le CDN

Figure 1 : Architecture 3 niveaux [1]

      2. Fiabilité du réseau : Redondance

Afin de fiabiliser le cœur de réseau, le déploiement des fonctions 5G s’appuient sur la redondance de fonctions dans des Datacenter séparés (DC1/DC2) selon une approche active/active, active/passive ou sur une redondance dans un pool.

La redondance active ou passive sont mises en œuvre pour les fonctions NRF, NSSF, SMSF, UDM, et UPCF alors que la redondance par pool est utilisée pour les fonctions AMF, SMF et UPF.

II-a) La redondance active/passive

La redondance active/passive représente une paire de fonction NF et seule la fonction active apporte le service demandé, la fonction passive est vue comme un backup. Les deux NF échangent un message Heartbeat (battement de cœur) c’est-à-dire un ping envoyé à un intervalle de pulsation régulier configuré.

Figure 2 : La redondance active/passive

Le HeartBeat est un système de haute disponibilité sous Linux (LinuxHA High Availability), mettant en cluster, c’est-à-dire en groupe, plusieurs fonctions. Le processus Heartbeat se chargera de passer les communications aux serveur actif si celui-ci est vivant et au serveur passif le cas échéant.

Sous linux, installez le paquet Heartbeat (apt-get install heartbeat)
et configurez le fichier /etc/heartbeat/ha.cf de la même manière
sur les deux serveurs.

II-B) La redondance active/active

La redondance active/active chaque NF déployée sur 2 DC différents répondent aux services demandés. Les données de backup peuvent être transmises d’une NF active à une autre, mais n’est pas obligatoire.

II-C) La redondance par pool

Les fonctions NFs sont regroupées dans un pool et chaque NF répond aux services demandés. Quand une fonction NF tombe en panne, les autres prennent le relai.

Les fonctions AMF sont regroupées selon l’architecture mesh, c’est-à-dire décentralisée et par type de service à supporter.

Un pool de SMF permet de connecter plusieurs SMF pour contrôler plusieurs UPF sur une zone radio donnée

Figure 3 : Le regroupement des NF

II-D) La surveillance des états

Les fonctions NF du cœur de réseau vérifient l’état des autres fonctions NF couplées via des messages ping à travers l’interface SBI ou des notifications de souscriptions pour la fonction NRF.

Sur l’interface point à point, les fonctions NF vérifient le lien à travers des messages Heartbeat via l’association SCTP ou le lien PFCP.

Figure 4 : La surveillance des états [1]

La fonction NRF est la première instance qui est exécutée lorsqu’on souhaite démarrer un nouveau cœur de réseau. Le NRF répertorie toutes les fonctions réseaux NF. Lors de la procédure de démarrage, une fonction NF vient s’enregistrer au niveau du NRF via une requête http.

Figure 5 : L’enregistrement de la fonction SMSF [2]

Pour la fiabilité du réseau, la fonction NRF fonctionne par paire : les opérateurs copient de manière active le NRF du DC1 vers le DC2.

La fonction NSSF assure la mise en œuvre du network slicing. Pour la fiabilité du réseau, les opérateurs déploient une paire de NSSF.

 

[1] Huawei : Deploy and apply 5G Core

[2] https://nickvsnetworking.com/if-you-like-pina-coladas-and-service-the-control-plane-intro-to-nrf-in-5gc/

 

La transmission PUR (IoT – EPC/5GS)

Posté le by - 300 vues
Répondre

Cet article présente une évolution du standard R.15 pour une transmission de données montante (UPLINK) dans le cas d’une transmission de type machine MTC et pour un terminal IoT 4G.

La transmission PUR s’effectue sur une interface 4G entre deux entités qui supportent cette transmission, c’est-à-dire soit entre un UE et une eNB ou une ng-eNB.

Le cœur de réseau peut être un cœur de réseau 4 (EPC) ou un cœur de réseau 5G (5GS).

Sur un cœur de réseau 4G, l’état RRC du mobile est soit en veille (RRC_IDLE), soit en mode connecté (RRC_CONNECTED). Pour la procédure de transmission PUR, l’état du mobile est obligatoire en veille (RRC_IDLE).

En mode de veille, le terminal écoute les informations émises par la station de base. Pour transmettre des données sur des ressources tempo-fréquentielles dédiées, le smartphone doit passer en mode connecté.

La procédure d’accès aléatoire permet de passer de l’état de veille à l’état connecté, ce qui nécessite un échange de 4 messages (dont 2 messages RRC) entre le mobile et la station de base.

La transmission PUR permet de réaliser une transmission UPLINK lorsque le terminal est à l’état RRC_IDLE sans avoir besoin de réaliser de procédure d’accès aléatoire puisque le terminal est pré-configuré pour une transmission montante, c’est à dire que le terminal dispose déjà des informations sur les ressources tempo-fréquentielles UPLINK à utiliser pour transmettre ses données à la station de base.

La configuration PUR est transmise par la station de base au terminal UE lorsque celui-ci en fait la demande et à l’état RRC_CONNECTED. Cela ne peut s’appliquer que dans la cellule ou la demande a été faite. La configuration est transmise sous condition de disposer des droits (information d’inscription ou de politique local).

Figure 1 : Pré-configuration du terminal par la station de base

Le terminal UE indique à la station de base qu’il souhaite obtenir une préconfiguration PUR par la requête PURConfigurationRequest. Cette requête demande les informations suivantes :

  • Nombre d’occurrences
  • Périodicité (par fenêtre temporelle de 10,24 secondes)
  • La taille du bloc de données TBS
  • Time offset (TA)

La station de base transmet la configuration PUR au mobile lors de la libération de la connexion radioélectrique afin que le mobile soit à l’état RRC_IDLE.

Le terminal peut transmettre ses données lors d’une occurrence configurée, la station de base étant en écoute de l’éventuel message émis par le terminal. La pré-configuration revient donc à réserver une ressource tempo-fréquentielle pour permettre au terminal d’émettre ses données sur un canal radio dédiée.  Afin d’éviter de conserver cette ressource sur une durée trop longue, un nombre d’occurrence et de périodicité définie la durée de validité de la transmission PUR

La transmission PUR est déclenchée quand les couches supérieures demande l’établissement ou la reprise de la connexion RRC. Une fois le paquet émis, la configuration PUR est supprimée. Le terminal ne pourra donc pas re-transmettre tant qu’il n’aura pas une autre pré-configuration.

En mode de veille, le terminal UE peut transmettre les données selon :

  • L’optimisation du plan de contrôle CIoT EPS/5GS Optimization via la requête RRCEarlyDataRequest (Figure 2);
    • La station de base peut à son tour transmettre des données via la requête RRCEarlyDataComplete sur les ressources tempo-fréquentielles proposées dans la configuration PUR. Par contre, si la taille des données est supérieure à la taille du TBS, le mobile enverra la requête RRCConnectionRequest à la place (fall back to the legacy RRC Connection establishment procedure, a new C-RNTI can be assigned)
    • S’il n’y a pas de données, la station de base acquitte la requête PUR par une réponse HARQ et éventuellement des informations de commandes TA (message DCI).
  • L’optimisation du plan de trafic CIoT EPS/5GS Optimization via la requête RRCConnectionResumeRequest (Figure 3)

Figure 2 : La transmission PUR avec l’optimisation du plan de contrôle

Figure 2 : La transmission PUR avec l’optimisation du plan de contrôleFigure 3 : La transmission PUR avec l’optimisation du plan de trafic

Le déploiement d’un réseau 5G SA (cloud privée ou publique)

Posté le by - 665 vues
Répondre

I) Introduction

L’évolution de la 4G vers la 5G n’est pas uniquement une virtualisation des entités 4G (ex: DECOR ou eDECOR – Dedicated Core) mais un déploiement automatisé des fonctions réseaux sur une architecture basée sur les services (SOA).

Une application est dite « native pour le cloud », lorsqu’elle est conçue autour d’instances gérées de façon automatisée dans les clouds privés, publics et hybrides. Aujourd’hui, les entreprises adoptent le Cloud Computing  [1] pour améliorer l’évolutivité et la disponibilité de leurs applications.

Le principal avantage d’une stratégie cloud-native est qu’elle permet d’accélérer le développement des applications dont les ressources de calcul sont réparties dans différents environnements [2].

Selon [1], « le cloud computing consiste à exécuter des charges de travail dans des clouds, des environnements qui dissocient, regroupent et partagent des ressources évolutives sur un réseau. »

Les concepteurs DevOps réalisent une architecture composée de ressources en libre-service et à la demande ainsi qu’à l’automatisation du cycle de vie des applications (de la phase de développement jusqu’à la production).

La 5G est dite cloud Native, la 3GPP propose une architecture composée de fonctions réseaux (NF) faiblement couplées. Une fonction réseau peut être découpée en microservices qui communiquent entre elles via des interfaces de programmation d’application (API).

Dans une architecture de microservices, les applications sont décomposées en éléments les plus simples et indépendants.

Les interfaces de programmation d’application (API) sont des ensembles d’outils, de définitions et de protocoles qui facilitent la création de fonctions d’applications (réseau). Elles connectent les producteurs de services et les consommateurs de services sans connaître les détails de leur mise en œuvre [1].

Le modèle DevOps est une approche d’automatisation et de conception de plateformes pour une solution logicielle complexe [3].

II) Cloud Public, privé, hybride, multicloud

Selon [1] :

Cloud Public : Environnements cloud créés à partir de ressources qui n’appartiennent pas à l’utilisateur final et qui peuvent être redistribuées à d’autres clients.

Cloud Privé : Généralement décrits comme des environnements cloud réservés à l’utilisateur final, la plupart du temps à l’intérieur du pare-feu et parfois sur site.

Cloud hybride : Plusieurs environnements cloud qui offrent différents degrés de portabilité, d’orchestration et de gestion de la charge de travail.

Multicloud : Systèmes informatiques qui comprennent au moins deux clouds (privés ou publics) qui peuvent être mis en réseau ou non.

Un cloud public est un pool de ressources virtuelles, créées à partir de matériel détenu et géré par une entreprise tierce, qui sont automatiquement provisionnées et allouées à différents clients via une interface en libre-service. Il s’agit d’une méthode simple qui permet de faire évoluer les charges de travail soumises à des fluctuations imprévues de la demande.

Déploiement de la 5G SA sur un Cloud Public

Les entités du coeur de réseau 2G/3G/4G stockent des informations, nommées contextes, relatives aux utilisateurs ou à l’association de couche transport (Tunnels). Ces contextes doivent être résilientes à toutes pannes.

La 3GPP propose une architecture sans état (Stateless) pour optimiser le déploiement des fonctions réseaux, en découplant le stockage des contextes et les couches applicatives. Les données sont sauvegardées dans des fonctions UDSF (Unstructured Data Storage Function [5]).

A titre d’exemple, le Cloud Public Amazon propose Elasticache et Google propose Google Cloud Memorystore, l’un et l’autre surtout connus pour leur capacité à sauvegarder des données en mémoire rapide de type NoSQL (REDIS : Remote Dictionary Server – Serveur de dictionnaire à distance).

Le découpage du réseau en tranche (Network Slicing) s’appuie sur l’architecture Cloud Native et les technologies SDN/NFV pour apporter des services à faible latence, haut débit, …

Les microservices n’ont pas nécessité de s’appuyer sur des conteneurs, néanmoins les solutions K3s ou K8s apportent plus de la flexibilité et de la scalabilité des fonctions réseaux par rapport aux VM.

Dans le cas de l’architecture NFV [6], une solution basée sur les VM nécessite des gestionnaires spécifiques S-VNFM (vendor-specific VNF manager) ou générique (generic VNF manager) pour la gestion des durées de vie des VMs.

Une application basée sur Kubernetes permet de gérer la durée de vie des conteneurs et des fonctions réseaux NF.

Les conteneurs permettent de gérer efficacement les fonctions du cœur de réseau (AMF/SMF/…).

Par contre les fonctions UPF sont plutôt distribués sur les MEC et la localisation étant imposée, la gestion par VM est plus efficace.

L’approche Cloud Native impose également un seul protocole http2 entre les fonctions réseaux, à l’exception du protocole PFCP sur l’interface N4.

Au niveau du plan de transport, l’établissement d’une session PDU signifie que le réseau 5G transporte du trafic Ethernet, IP ou non structuré. L’utilisation de PoD multi-homed permet d’avoir plusieurs interfaces et permet aussi de gérer différents protocoles (SCTP par exemple)

[1] https://www.redhat.com/fr/topics/cloud

[2] https://www.redhat.com/fr/topics/cloud-native-apps

[3] https://www.redhat.com/fr/topics/cloud-native-apps

[4] https://d1.awsstatic.com/whitepapers/5g-network-evolution-with-aws.pdf

[5] TS 21.195

[6] https://www.etsi.org/technologies/nfv

Le découpage des fonctions gNB : 3GPP et O-RAN

Posté le by - 701 vues
Répondre

Introduction

Au cours des 5 précédents articles, nous avons vu les sous-couches protocolaires mises en œuvre au niveau de la station de base gNB.

L’entité gNB a été présentée comme une entité monolithique, le standard 3GPP présente la pile protocolaire et les interfaces entre l’UE, la station de base et le cœur de réseau.

Afin d’apporter plus de souplesse, le standard 3GPP propose de découper l’entité gNB en deux unités : une unité distribuée DU (RLC, MAC et Radio) et une unité centralisée CU (RRC et SDAP/PDCP).

Ce découpage définit de nouvelles interfaces (F1) et de nouvelles liaisons (fronthaul, midhaul et backhaul [1]) comparativement au découpage RU et BBU en 4G LTE.

Figure 1: Le découpage d’une station de base eNB et d’une station de base gNB

II) L’architecture 3GPP

L’architecture du gNB est représentée sur la figure suivante [2]

Figure 2 : Architecture gNB (Rahim Navaei) [2]

On sépare le plan de contrôle (Control Plane) et le plan utilisateur (User Plane) (CUPS : Control User Plane Separation).

Au niveau du cœur de réseau, la 3GPP défini une architecture SA en introduisant les interfaces basées sur le service (SBI) et en utilisant le protocole http2 et des API. L’architecture SBA est Cloud-native.

Au niveau de l’accès radio, la décomposition du la BBU en CU et DU et l’évolution de l’eCPRI permet de faciliter le déploiement de la virtualisation de la partie radio (O-RAN).

Dans le plan de contrôle, la figure 2 fait apparaitre un nouveau protocole F1AP entre le gNB-CU et le gNB-DU et un nouveau protocole E1AP sur l’interface E1 entre le gNB-CU du plan de contrôle et le gNB-CU du plan utilisateur.

Les fonctions sur le plan de contrôle F1AP permettent de gérer l’interface (établissement, re-initialisation, achèvement de l’interface F1) et porte les messages de contrôle RRC pour la gestion du contexte utilisateur (via le message F1AP UE Context), la gestion des systèmes d’informations MIB/SIB, le paging et l’allocation d’un numéro de tunnel TEID pour le plan d’acheminement entre le gNB-CU UP et l’UPF.

Le plan d’acheminement est injecté à travers la fonction E1AP. Les fonctions E1AP permettent de gérer l’interface (établissement, re-initialisation, achèvement de l’interface E1) et de gérer le bearer (via le message E1AP Bearer Context).

A titre d’exemple, en cas de Handover, la reconfiguration radio est déclenchée par l’unité gNB-CU de la station de base source et implique une modification du contexte entre l’unité DU source et l’unité DU cible.

Figure 3 : Les messages en cas de HandOver

 

III) L’architecture O-RAN

L’alliance O-RAN (Open Radio Access Network) propose une décomposition des fonctionnalités de la station de base en micro-services.  La première étape consiste à découper le bloc monolithique de l’entité gNB en fonctions réseaux virtualisables et inter-opérables.

La solution Cloud-Native est adoptée et plusieurs options sont possibles quand à l’implémentation RAN en micro-services : conteneurs, K8s K3s ou VM.

Amazon propose les solutions ECS (Elastic Container Service), EKS (Elastic Kubernetes Services – EKS Distro ou EKS Anywhere) [3]

L’alliance O-RAN définie (figure 1) une architecture O-RAN composée de 9 fonctions réseaux et 19 interfaces. En se basant sur l’architecture 3GPP, l’alliance O-RAN vise à définir une architecture ouverte et interopérable.

Figure 4 : Architecture O-RAN [3]

Les interfaces E2 et O1 permettent d’améliorer la gestion de l’accès radioélectrique et d’automatiser le déploiement d’instances en se basant sur des outils d’optimisation et d’automatisation radio (avec l’utilisation de l’apprentissage Machine Learning et l’optimisation par l’IA).

Le découpage des fonctions O-CU, O-DU et O-RU est standardisé par l’alliance O-RAN. La 3GPP qui propose un découpage du gNB en deux unités DU et CU est représenté par l’option 2 du standard O-RAN.

Figure 5 : Le découpage en fonction de l’architecture O-RAN [4]

L’architecture O-RAN comprend 3 niveau (three tiers) :

L’infrastructure O-Cloud contient les serveurs physiques et les fonctions réseaux.

L’orchestrateur SMO (Service Management and Orchestration Framework) fournit les services de gestion des instances, en apportant les fonctionnalités pour la gestion des slices, la gestion des services de transports de données. Le SMO peut être la plateforme ONAP (Open Network Automation Platform).

Le contrôleur RIC (non-real time and near-real time RIC) a pour objectif d’optimiser les fonctions réseaux RAN pour la gestion de la mobilité des utilisateurs (non real time RIC), le contrôle de l’admission radioélectrique (non real time RIC) et la gestion des interférences (near-real time RIC. Le contrôleur utilise les outils ML/IA pour prédire et optimiser la gestion de l’accès radioélectrique et a pour objectif de contrôler les unités O-DU et O-CU pour la gestion de la QoS.

 

[1] TS 38.401

[2] Rahim Navaei :  https://www.linkedin.com/feed/update/urn:li:activity:7018462941226098688/

[3] https://docs.aws.amazon.com/whitepapers/latest/open-radio-access-network-architecture-on-aws/open-radio-access-network-architecture-on-aws.html

[4] TR 38.801

Evolution de la pile protocolaire LTE vers NR (5/5)

Posté le by - 390 vues
Répondre

La couche SDAP (Service Data Adaptation Protocol)

La couche SDAP a pour rôle de définir la qualité de service à mettre en œuvre pour chaque support de données radios DRB (Data Radio Bearer).

La couche SDAP fait la correspondance entre la QoS de chaque flux d’une session PDU (session de données entre la station de base et le cœur de réseau) et la gestion de la QoS au niveau du DRB. Une entité SDAP gère autant de DRB qu’il y a de QoS différentes au niveau de la session PDU.

Deux sessions PDU différentes sont gérées par deux entités SDAP et même si deux flux de chaque session ont la même QoS, la station de base gère deux DRB différents, un par entité SDAP.

La QoS du flux est identifiée par l’identifiant QFI (QoS Flow Identifier) de 6 bits, ce qui limite à 64 QFI par session PDU.

Figure 1 : La gestion de la QoS et le gabarit de filtres (TFT) [1]

On parle de QoS réflective lorsque la couche SDAP rajoute l’identifiant QFI sur le lien montant. Ceci permet d’appliquer la même QoS au niveau du cœur de réseau pour le flux montant que la QoS appliquée au niveau du flux descendant. Mais, l’entité SDAP peut être configurée en mode transparent, l’absence d’en-tête SDAP ne permet plus d’ajouter l’identifiant QFI. Cela correspond au DRB UL par défaut.

La configuration du DRB est réalisée par un message RRC, la QoS est soit indiquée dans la configuration du message ou récupérée au niveau de l’identifiant QFI du paquet descendant (QoS réflective). Pour que la couche SDAP de l’UE puisse mettre en oeuvre la QoS réflective, la station de base positionne le bit RDI (Reflective QoS Flow ti DRB mapping Indication) à 1 [2]. Quand le bit RDI=1, l’UE met à jour la table de correspondance QFI -> DRB pour le lien montant.

L’identifiant QFI est standardisé et correspond à un profil de QoS. Au niveau de la station de base, le profil de QoS permet de définir comment traiter le trafic au niveau du DRB.

La couche SDAP est également configurée par la signalisation RRC pour chaque DRB.

Conclusion

La session PDU permet de connecter le terminal vers un réseau PDN, ce réseau est susceptible d’offrir plusieurs services avec des flux de QoS différentes.

La connexion radio est assurée par la station de base qui contrôle les ressources radios. Les différentes couches ont pour rôle d’apporter un service de transfert de données sécurisés en respectant la QoS établie avec le coeur de réseau.

Figure 2 : Les couches protocolaires de l’interface radio

[1] https://www.sharetechnote.com/html/5G/5G_QoS.html

[2]  TS 137 324 – V15.1.0 – LTE; 5G

[3] https://www.techplayon.com/5g-nr-sdap-service-data-adaption-protocol/

 

Evolution de la pile protocolaire LTE vers NR (4/5)

Posté le by - 322 vues
Répondre

La couche PDCP

La couche NR PDCP réalise les fonctions de la couche LTE PDCP et de nouvelles fonctions sont implémentées au niveau du NR PDCP comme la mise en ordre des paquets ce qui permet de faciliter la double connectivité et le partage des fonctions CU/DU (sur l’interface F1, les paquets peuvent être reçus dans un autre ordre).

Les fonctions réalisées par la couche LTE PDCP et la couche NR PDCP sont :

  • Chiffrement et Intégrité des supports de signalisation SRB2/SRB3;
  • Chiffrement du support de trafic DRB. La couche NR PDCP peut également apporter l’intégrité;
  • compression/décompression d’en-tête (ROHC);
  • fonction de routage dans le cas de la double connectivité (split bearer).

Parmi les nouvelles fonctionnalités, le couche NR PDPC a en charge seule :

  • la mise en ordre des paquets
  • la duplication des paquets pour les services à faible latence et fiable (typiquement URLLC)

La mise en ordre des paquets est réalisée sur une taille de fenêtre (nombre de PDCP PDU) définie par la couche RRC et qui démarre à la réception SN du paquet PDCP PDU (push-based window) et une durée d’expiration . Tout paquet PDCP PDU reçu au niveau de la couche PDCP réceptrice avec un SN en dehors de la fenêtre est considéré comme perdu contrairement à la mise en ordre de la couche LTE RLC ou tout nouveau paquet était vu comme nouveau et donnait la valeur de la fenêtre.

La fonction de mise en ordre peut être désactivée si le service n’est pas adapté.

La fonction de duplication

La duplication permet à la couche PDCP d’envoyer le même paquet PDCP PDU à deux entités RLC différentes. La duplication est contrôlée au niveau de la couche MAC (MAC CE).

Evolution de la pile protocolaire LTE vers NR (3/5)

Posté le by - 317 vues
Répondre

La couche RLC

La couche RLC (Radio Link Control) a pour rôle de contrôler le lien de données c’est-à-dire :

  • Le Transfert de PDU vers la couche PDCP selon l’un des trois modes suivants
    • Acquitté AM (Acknowledged Mode)
    • Non Acquitté UM (Unacknowlege Mode)
    • Transparent TM (Transparent Mode)

L’optimisation de la transmission des données est réalisée par l’utilisation d’une fenêtre d’émission et de réception.

  • La correction d’erreur en mode AM par la retransmission d’un RLC PDU perdu
  • La segmentation et le réassemblage des RLC SDU (Mode AM et UM)
  • La re-segmentation de données RLC PDU car le RLC PDU en entier ne peut pas être transmis

 

Afin d’optimiser le contrôle des flux, les fonctions suivantes, réalisées au niveau du RLC-LTE, sont implémentées sur la sous-couche MAC ou PDCP:

  • la concaténation, réalisée au niveau de la couche LTE RLC est mise en œuvre sur la couche NR MAC.
  • La mise en ordre des données, réalisé au niveau de la couche LTE RLC est maintenant réalisée au niveau de la couche NR PDCP.

 

Une entité RLC est établie par la couche RRC afin de monter un bearer radio DRB. L’unité de service de données RLC SDU est issue de la couche PDCP (cf. figure 2) et un numéro de séquence SN (Sequence Number) est assigné à la transmission du RLC PDU et incrémenté à chaque transmission.

L’entité TM RLC transporte (cf. figure 2) les canaux logiques de diffusions BCCH et de notification (Paging : PCCH) et les supports de signalisation SRB0 [FL4].

Les supports de signalisation, autre que le SRB0, sont transmis sur l’entité AM RLC et les supports DRB peuvent être transmis sur une entité AM RLC et une ou deux entités UM RLC.

L’entité UM RLC est mise en oeuvre pour des services en temps réel dont la perte de paquets est acceptable, comme les services multimédias (VoLTE), streaming. L’entité UM RLC est configurée en émission ou réception (uni-directionnel UL ou DL) et supporte la fonction de segmentation.

L’entité AM RLC est mise en œuvre pour des services sensibles à la perte de données et la transmission de rapport de statut. Le protocole ARQ est gérée pour la retransmission des paquets perdus. L’entité AM RLC est bi-directionnelle.

Le RLC PDU est transmis à la couche MAC selon les exigences attendues par la couche MAC (ordonnancement). Ainsi, la couche RLC met en œuvre la segmentation pour adapter la taille du paquet à la MAC SDU et réduire le padding.

La gestion des erreurs pour le mode de transmission AM est mise en œuvre par le protocole ARQ (Automatic ReQuest) au niveau de la couche RLC.

La fonction de segmentation

La fonction de segmentation permet à la couche RLC à l’émission de découper les paquets PDCP PDU qui seront multiplexés par la couche MAC vers un MAC PDU. La couche RLC en réception réalise l’opération inverse, en assemblant les RLC SDU et fournir un PDCP PDU à partir des séquences reçues et numérotées SN.

Figure 7 : Segmentation RLC SDU

La fonction de concaténation n’étant plus assurée au niveau de la couche RLC, les en-têtes RLC augmentent lorsque plusieurs RLC SDU sont multiplexées dans une MAC PDU.

Le nombre de RLC SDU dépend de la taille du bloc de transport TB MAC. Si la taille du bloc de transport n’est pas suffisante alors le paquet de données RLC PDU est segmenté.

Au niveau de l’en-tête RLC PDU, les champs :

  • SI Segment Information indique sur le RLC PDU contient
    • SI =00 un RLC SDU en entier (provenant de la couche PDCP)
    • un segment du RLC SDU (SI=01 début du segment, SI=10 le milieu ou SI=11 la fin du segment)
  • SO Segment Offset indique le décalage en octet du segment du segment par rapport au RLC SDU initial.

Par exemple, le 3ème RLC SDU est segmenté en deux partie : 1000 octets sont transmis dans le 1er segment et 231 octets dans le deuxième segment.

Figure 8 : La segmentation d’un RLC PDU

Figure 9 : La transmission de segments RLC PDU [2]

Pour réduire la taille des en-têtes, il existe deux structures de la MAC PDU pour le mode UM. La figure 10 présente une première structure sans segmentation. On ne transmet pas le numéro de séquence SN car celui-ci ne sert qu’à différencier les différents segments de service RLC SDU dans le RLC PDU.

Figure 10 : Structure RLC PDU en mode UM

Figure 11 : Structure RLC PDU en mode UM

Le protocole ARQ

Dans le cas de transmission en mode acquittée, le protocole ARQ s’appuie sur le numéro de séquence SN pour vérifier qu’aucun segment SDU n’a été perdu lors de la transmission.

Trois fonctions sont implémentées :

  • Interrogation (polling) demandée par l’entité RLC émettrice permet de déclencher un rapport d’état au niveau de la couche RLC réceptrice. Le déclenchement est émis au bout d’un certain nombre de SDU reçus (numéro SN) ou à l’expiration d’un temporisateur. En absence de réception du rapport, l’entité RLC émettrice n’émet pas de nouveaux RLC PDU.
  • Emission d’un rapport d’états, émis par la couche RLC réceptrice permet d’indiquer à la couche RLC émettrice la réception de tous les RLC SDU ou les RLC SDU/segments RLC SDU manquants. Les RLC SDU manquants sont explicitement indiqués par le numéro de séquence SN et en cas de segment, le décalage SO correspondant. Si tous les SDU RLC sont reçus, alors la couche RLC émettrice transmet dans son rapport la valeur de séquence SN la plus haute.
  • Retransmission est effectuée par la couche RLC émettrice en se basant sur le rapport d’état. Le nombre maximum de retransmission est configuré par la couche RRC à l’entité RLC émettrice. Lorsque ce nombre est atteint, la couche RLC émet une notification d’échec du lien radioélectrique RLF (Radio Link Failure). Le ré-établissement d’une entité RLC est contrôlé par le message RRC re-establishment [FL4]

 

 

[1] 3GPP TS 38.322

[2] [https://www.techplayon.com/5g-nr-rlc-um-mode-data-transmission/

[FL4] : https://blogs.univ-poitiers.fr/f-launay/2023/03/21/les-supports-de-signalisation-srb-signaling-radio-bearer/

 

Evolution de la pile protocolaire LTE vers NR (2/5)

Posté le by - 346 vues
Répondre

Suite de l’article

La couche MAC [TS 38.321]

La couche MAC transmet ou reçoit :

  • de la couche physique des canaux de transport (interface L1 : Layer 1),
  • de la couche RLC des canaux logiques

Figure 2 : Les canaux de la pile protocolaire LTE/NR

 

L’unité de données protocole de couche MAC (MAC-PDU) remplit le bloc de transport TB (Transport Block).

Le bloc de transport est défini par la signalisation L1 (L1 signaling) c’est à dire sa taille et des paramètres physique comme le schéma de modulation et de codage MCS et la longueur du slot.

La couche MAC transporte les données utilisateurs (plan de trafic) et les données de signalisation (plan de contrôle). Différentes structures de la couche MAC ont été définies et l’élément de contrôle MAC CE (Control Element) transport de la signalisation.

La structure MAC est définie par dans l’en-tête MAC (MAC Header) via l’information LCID (Logical Channel ID)

Figure 3 : Liste des MAC CE

 

La structure de la couche MAC PDU pour la transmission de données (UL-SCH et DL-SCH) est optimisée pour transporter des grandes quantités de données, en utilisant notamment la fonctionnalité de concaténation des données de la couche RLC : plusieurs MAC SDU peuvent être multiplexée dans une seule MAC PDU.

Contrairement en 4G ou l’en-tête MAC contient un ensemble de sous-entête pour chaque CE ou SDU, la MAC PDU se découpe en sous en-tête MAC suivi du CE ou du SDU. Cette structure facilite le traitement en pipeline au niveau de l’émetteur et du récepteur et le traitement démarre dès qu’une sous en-tête et le SDU ou le CE associé est reçu.

MAC PDU LTE

Figure 4a : MAC PDU LTE en DL

MAC PDU NR

MAC PDU NR

Figure 4b : MAC PDU NR en DL

La taille du SDU ou le champs LCID pour la MAC CE est dynamiquement indiquée dans l’en-tête.

Les rôles de la sous-couche MAC sont [FL2]:

  • la correspondance entre les canaux logiques et les canaux de transport;
  • le multiplexage/démultiplexage des unités de données de services 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 concaténation des MAC-SDU lors du multiplexage des unités de données.
  • La demande de transmission de données de la part du mobile (BSR : Buffer Status Reporting)
  • la correction d’erreur rapide HARQ ;
  • la gestion de priorité entre les mobiles ;
  • la gestion de priorité sur les canaux logiques pour un mobile ;
  • la gestion des échecs radio de faisceau

MAC

Figure 5 : La structure MAC

La gestion des faisceaux est la principale nouveauté de l’interface NR par rapport à l’interface LTE. Toutefois, pour faciliter la gestion du très haut débit, la fonction concaténation est réalisée au niveau de la couche MAC 5G (RLC en 4G)

La fonction de séquencement et la gestion de la priorité

La couche MAC priorise les données reçues de la couche RLC en fonction de la nature des données (canal logique CCCH, DCCH et DTCH).

Au niveau du terminal, la couche MAC implémente la fonction LCP afin de séquencer les données sur le lien montant. L’ordonnanceur de la fonction LCP détermine la taille des données qui seront multiplexées à partir des différents canaux logiques LCH pour former un MAC PDU. Chaque LCH est caractérisé par une priorité PBR (Prioritized Bit Rate) et une durée de la taille du paquet (BSD : Bucket Size Duration). La fonction LCP implémente également des restrictions comme la fenêtre d’acquittement selon le type de service (URLLC, eMBB, mMTC), l’espacement entre sous-porteuses (SCS : Sub Carrier Spacing), le type d’allocation de ressource (dynamique – Dynamic Scheduling ou configuré – Configured Grant [FL1]) et le type de slot (mini-slot). Enfin des restrictions sont également fournie de la part de la couche PDCP à la couche MAC dans le cas de la duplication de paquets afin de ne pas multiplexer deux paquets dupliquer dans une seule MAC PDU.

La fonction LCP est contrôlée par la couche RRC qui configure les restrictions sur chaque canal LCH (figure 6) :

  • allowedSCS-List définit les valeurs SCS proposées pour la transmission ;
  • maxPUSCH-Duration indique la durée de transmission PUSCH maximale ;
  • configuredGrantType1Allowed informe si la transmission est préconfigurée de type 1 (Configured Grant Type 1) ou dynamique;
  • allowedServingCells which indique les cellules autorisées pour la transmission ;
  • allowedCG-List qui indique les configurations autorisées (CG) pour la transmission ;
  • allowedPHY-PriorityIndex allouant les index de priorités aux transmissions allouées dynamiquement.

Le séquencement sur la voie montante (UL Scheduling) est réalisé à partir d’informations physiques fournies par la station de base gNB

Figure 6 : la configuration des canaux logiques et le paramétrage de séquencement

 Afin d’assister le gNB sur les décisions radio de l’UE, d’autres fonctions (similaires en 4G) sont implémentées au niveau de la couche MAC comme la fonction SR (Scheduling Request), BSR et PHR (Power Headroom Report).

Les procédures de la couche MAC

La couche MAC est à l’initiative des procédures suivantes :

  • l’accès aléatoire [FL3]
  • la transmission de données (DL assignments, UL scheduling request)
  • La demande de séquencement -SR procedure : l’entité MAC CE de l’UE informe le gNB de données à émettre de la part du terminal. Différentes configurations SR permettent de prioriser l’émission de canaux logique UL LCH.
  • La procédure BSR permet à la couche MAC UE d’indiquer au gNB la quantité de données stockée dans le buffer de l’UE par groupe de canaux logiques LCG (Logical Channe Group). Le BSR est transmis dans une structure MAC CE sur 2 octets (short BSR/truncated BSR) ou 4 octets (long BSR). Les valeurs du LCID sont :
    • 11100 Truncated BSR
    • 11101 Short BSR
    • 11110 Long BSR

L’Interface NR implémente 8 LCG au lieu de 4 pour le LTE (l’information LCG n’était que sur 2 bits).

La couche RRC contrôle la procédure BSR en configurant 3 temporisateurs (le déclenchement BSR peut être régulier, périodique, ou padding) :

  • periodicBSR-Timer (periodic BSR)
  • retxBSR-Timer ( (regular BSR)
  • logicalChannelSR-ProhibitTimer
  • la procédure PHR (Power Headroom Report) permet à la couche MAC UE d’envoyer un rapport au gNB lui indiquant la réserve de puissance du mobile avant d’émettre à la puissance maximale. Le PH est transmis à chaque cellule serveuse qui configure la porteuse UL (dans le cas de l’agrégation de porteuses CA). Cela permet d’assister le gNB sur la décision du MCS dans le cas du séquencement montant. Le PHR est transmis dans une structure MAC CE. Deux types de PHR sont définis : périodique ou déclenchement sur seuil (RSRP). Ces valeurs de déclenchement sont configurées par la couche RRC lors d’un message RRC Setup, RRC Reconfiguration, .. (cf. FL4) dans l’IE PHR-Config (PeriodicPHR-Timer, ProhibitPHR-TImer, dl-pathlossChange)
  • la réception discontinue DRX pour réduire la consommation énergétique du terminal. Le mode DRX contrôle le moment ou le terminal écoute le canal PDCCH (décision d’ordonnancement) à travers plusieurs temporisateur [FL5]. La différence principale par rapport au LTE est sur la gestion de différents SCS configurés sur différentes cellules.

Pour la transmission montante, la configuration Grant-Free Scheduling [FL6] permet de réduire encore davantage la consommation énergétique (selon les restrictions LCP)

  • la commutation de BWP
  • la surveillance d’inactivité
  • la gestion du faisceau : La gestion de l’échec de faisceau (Beam Failure Management) est gérée par la couche MAC à partir de mesures de la couche physique (BFI : Beam Failure Instance). Deux procédures sont impliquées :
    • Procédure BFD (Beam Failure Detection) à partir de la mesure de la couche physique L1-RSRP (en dessous d’une certaine limite).
    • Procédure BFR ( Beam Failure Recovery)

La couche RRC contrôle les paramètres des procédures BFD et BFR dans les paramètres suivants : BeamFailureRecoveryConfig, BeamFailureRecoverySCellConfig et  RadioLinkMonitoringConfig

  • beamFailureInstanceMaxCount pour la détection de la défaillance du faisceau;
  • beamFailureDetectionTimer pour la détection de la défaillance du faisceau;
  • beamFailureRecoveryTimer pour la procédure de récupération d’un faisceau au niveau de la cellule SpCell ([FL7]);
  • rsrp–ThresholdSSB: la valeur seuil du RSRPpour la procédure SpCell beam failure recovery;
  • rsrp–ThresholdBFR: la valeur seuil du RSRP pour la procédure SCell beam failure recovery;

Références

[FL1] https://blogs.univ-poitiers.fr/f-launay/2020/05/15/e2e-network-slicing-le-decoupage-du-reseau-de-bout-en-bout-partie-3/

[FL2] :  https://blogs.univ-poitiers.fr/f-launay/2022/05/13/sdt-small-data-transmission-3eme/

[FL3] : https://blogs.univ-poitiers.fr/f-launay/2023/03/22/lacces-aleatoire-pour-les-terminaux-lte-ue-et-lte-bl-ce-ue-et-nb-iot-4step-ra-et-2-step-ra/

[FL4] : https://blogs.univ-poitiers.fr/f-launay/2023/03/21/les-supports-de-signalisation-srb-signaling-radio-bearer/

[FL5] : https://blogs.univ-poitiers.fr/f-launay/2016/11/04/paging-et-mecanisme-psmdrx/

[FL6] : https://blogs.univ-poitiers.fr/f-launay/2023/03/19/liot-evolutions-r16-et-r17/

[FL7] https://blogs.univ-poitiers.fr/f-launay/2022/07/20/pcell-scell-pscell-et-spcell/

[TS 38.321] Medium Access Control (MAC) protocol specification (3GPP TS 38.321 version 16.3.0 Release 16)

Evolution de la pile protocolaire LTE vers NR

Posté le by - 397 vues
Répondre

Introduction

Dans ces 4 articles, nous allons expliquer l’évolution des protocoles radioélectriques LTE/NR permettant :

  • de transmettre différents formats de paquets IP sur la couche physique (LTE/NR), mais également la transmission de trames Ethernet (supportée par la NR uniquement). Les paquets de données, Ethernet ou IP, sont transmis dans des supports radio nommés DRB (Data Radio Bearer) ;
  • de transmettre de manière fiable des messages du protocole RRC à travers des supports de signalisation SRB (Signaling Bearer Data) [FL1]

La transmission est assurée par différentes sous-couches protocolaires héritées des réseaux antérieurs (3G/4G).

Toutefois :

  • pour améliorer la transmission de données, certaines fonctionnalités sont gérées de manière différentes en 4G et 5G comme par exemple :
    • la concaténation est effectuée au niveau de la couche MAC NR et au niveau de la couche RLC LTE
    • la structure MAC PDU NR contient une suite de sous-en-tête MAC immédiatement suivi du SDU ou d’un élément de contrôle (différemment de la structure de la couche MAC LTE) ;
    • la couche MAC NR gère la gestion des faisceaux (Beam Management)
    • la couche MAC de l’UE implémente la fonction LCP (Logical Channel Priority)
  • pour gérer les solutions de double connectivité MR-DC (Multi-Rat Dual Connectivity), la fonction PDCP supporte la séparation des paquets. Ainsi la re numérotation des paquets est également réalisée au niveau de la couche PDCP NR et RLC LTE.
  • pour améliorer la fiabilité des données par duplication des paquets. La couche PDCP est à nouveau utilisée pour dupliquer le paquet en mode DC ou en mode CA.

De plus, la NR est conçue pour un déploiement Cloud (C-RAN/O-RAN). Le protocole est donc pensé pour être implémenté sur des serveurs physiques (datacenter) différents.

Rappels généraux sur les concepts réseaux

Les données sont transmises de sous-couches en sous-couches par des primitives. On appelle SDU (Service Data Unit) les données échangées dans les primitives de services. Il s’agit donc des données utiles qu’une sous-couche N+1 (respectivement N) transmet à une autre sous-couche N (respectivement N+1).

Un protocole défini des règles d’échange de service entre entité de même couche.  Les données échangées par un protocole d’une sous couche N à son homologue de couche N sont nommées PDU (Protocol Data Unit). Un PDU est constitué d’un en-tête (information de contrôle PCI Protocol Control Information) et de données de service SDU : plusieurs SDU de la couche N+1 (respectivement N-1) peuvent être transportés par encapsulation/dés-encapsulation dans un même PDU de la couche N à son homologue de couche N.

Figure 1 : La pile protocolaire NR pour le plan de trafic

Les 4 articles suivants seront consacrés respectivement à la couche MAC, RLC, PDCP et SDAP.

Référence : 

[FL1] : https://blogs.univ-poitiers.fr/f-launay/2023/03/21/les-supports-de-signalisation-srb-signaling-radio-bearer/