Architecture SBA du réseau 5G : Microservices et SOA

Posté le 26 février 2021 by flaunay - 8 863 vues

L’objectif de cet article est de comprendre l’évolution du cœur de réseau mobile entre l’architecture 4G monolithique et l’architecture 5G basée sur les services.

La nouvelle architecture 5G a été pensée pour pouvoir ajouter des briques logicielles innovantes et une mise sur marché rapide de ces nouvelles fonctionnalités. Ainsi, à l’instar des solutions proposées par Amazon ou Windows Azur, le réseau 5G s’appuie sur les solutions Cloud et la méthodologie DevOps.

Au cours de cet article, nous allons décrire le cœur de réseau 4G, puis les architectures SOA (Service Oriented Architecture) et microservice pour décrire et comprendre l’architecture SBA (Services Based Architecture) du réseau 5G.

Je remercie Mickael BARON [2] d’avoir pris le temps de relire l’article, le corriger et d’avoir contribué aux améliorations de cet article.

L’architecture du réseau 4G

Le cœur de réseau de mobiles 4G (cf. figure 1) est construit à partir des entités fonctionnelles suivantes :

l’entité MME (Mobility Management Entity) a pour rôle de gérer :
- l’attachement des mobile ;
- le suivi de la mobilité ;
- l’établissement de sessions IP prenant en compte la politique de taxation de l’usager ;
- l’établissement d’un appel voix.
l’entité SGW (Serving Gateway) est le point d’ancrage des flux de sessions IP. Le SGW gère l’établissement d’un bearer (un bearer est un tunnel IP de bout en bout associée à une qualité de service QoS). Le bearer s’établit du mobile jusqu’à l’entité PGW. Le SGW mesure le trafic consommé par utilisateur et, en cas de demande judiciaire, dérive le trafic (cas d’interception légale).
l’entité PGW (PDN Gateway) est la passerelle de routage entre le réseau opérateur et un réseau IP (PDN : Packet Data Network). L’entité PGW réalise l’inspection de trafic, met en place les bearer avec le SGW, est en charge de fournir une adresse IP au mobile pour chaque bearer, mesure le trafic consommé et, en cas de demande, dérive le trafic dans le cas d’interception légale.
l’entité PCRF (Policy Charging Rule Function) gère la mise en œuvre de la QoS pour les bearer dédiés et la gestion dynamique de la facturation.

Figure 1 : Le réseau 4G, les bases de données et l’échange d’information

Chaque entité fonctionnelle contient un ensemble de lignes de codes pour pouvoir apporter les fonctionnalités attendues. On parle de bloc monolithique : le langage de programmation choisi pour chaque entité fonctionnelle dépend de l’équipementier. La mise à jour d’une entité nécessite la recompilation de l’ensemble du programme (toutes les lignes de code), ce qui met à jour toutes les fonctions. L’équipementier doit s’assurer que la modification d’une fonction n’ait aucun impact sur le reste du programme.

Chaque entité fonctionnelle contient une base de données importante (une table avec des millions d’entrées). A titre d’exemple, la figure 1 représente en couleur bleue une partie du contexte sauvegardé dans la base de données des entités pour un mobile. Les entités fonctionnelles partagent leurs données aux autres entités dans des appels à fonction. La technologie utilisée pour la base de données est propre à l’équipementier (mariadb, PostgreSQL, …). Ainsi, deux entités MME provenant de deux équipementiers différents (Nokia/Ericsson par exemple) peuvent utiliser des bases de données différentes et un langage de programmation différent. Mais les échanges entre entités sont normalisés.

Enfin, une ou plusieurs entités fonctionnelles peuvent être intégrées dans une seule entité matérielle. A titre d’exemple, le SGW et le PGW peuvent former l’entité S/PGW. L’entité matérielle est dite monolithe.

Définition : en génie logiciel, un modèle monolithique fait référence à une seule unité indivisible.

Par dérivation, le concept de logiciel monolithique réside dans la combinaison de différents composants d’une application en un seul programme sur une seule plateforme. Habituellement, une application monolithique se compose d’une base de données, d’une interface utilisateur côté client et d’une application côté serveur. Toutes les parties du logiciel sont unifiées et toutes ses fonctions sont gérées en un seul endroit.

Comme le montre la figure 1, dans l’architecture 4G, les entités sont connectées les unes aux autres, par une connexion point à point. Cette connexion est nécessaire afin d’échanger des données.

L’architecture 4G est une architecture composée d’entité monolithe modulaire autonome : chaque entité est responsable d’un ensemble de fonctions et fournit aux autres entités les données nécessaires à l’exécution d’un service.

Par exemple :

l’identification, l’authentification et les droits d’accès du mobile sont gérées par l’entité HSS : l’entité MME interroge l’entité HSS pour pouvoir identifier le mobile en lui transmettant l’identité IMSI du mobile. Le HSS transmet à l’entité MME les données d’authentification. L’entité MME va ensuite réaliser la procédure d’authentification avec le mobile ;
lorsque le mobile est en mode connecté, l’entité MME connait l’identité de la station de base (eCGI) sur laquelle le mobile échange des données. L’entité MME peut donc demander à l’entité SGW de mettre en place, pour ce mobile, un nouveau bearer (dédié) vers la station de base.

Les spécifications 3GPP standardisent les interfaces entre chaque entité fonctionnelle en définissant :

les applications au niveau des interfaces (par exemple GTP-C, S1-AP, DIAMETER) ;
les messages échangés entre chaque interface (cf. figure 1).

Dans le cas de l’architecture 4G, une fonction (une portion du code) est sollicitée par une autre entité : à titre d’exemple la fonction PCEF intégrée au niveau de l’entité PGW applique les règles fixées par l’entité PCRF. L’entité PCRF transmet une requête DIAMETER à l’entité PGW sur l’interface Gx. Chaque entité gérant des millions d’utilisateurs, il est nécessaire d’identifier le mobile concerné. Ainsi, chaque entité source soumet à l’entité cible les informations nécessaires (l’identité GUTI ou IMSI, le numéro de tunnel TEID, …comme le montre la figure 1). Les informations à transmettre sont normalisées.

Cette architecture monolithe modulaire facilite l’ajout de nouvelles entités fonctionnelle. Toutefois, puisque les entités communiquent les unes avec les autres selon les spécifications 3GPP, il est nécessaire de respecter les spécifications sur les interfaces. Malgré les efforts de spécifications, l’interprétation de la norme peut être perçue différemment par chaque équipementier.

Ainsi, lorsque l’opérateur ajoute une nouvelle entité, cela nécessite du temps pour vérifier l’intégration de cette nouvelle entité avec les autres entités existantes provenant de constructeurs différents.

En général, une fois la normalisation d’un réseau mobile gelé, l’architecture du réseau de mobiles n’évolue pas. C’est le cas pour la 2G, puis la 3G. Cela aurait dû être le cas pour la 4G, mais l’arrivée de l’IoT a nécessité une évolution de l’architecture du réseau 4G par l’ajout d’une nouvelle entité. Ainsi, initialement la 3GPP a proposé l’ajout d’une entité MTC-IWF pour les cas d’usage du MTC (Machine Type Communication) et a spécifié l’interface DIAMETER entre l’entité fonctionnelle MTC-IWF et les autres entités.

Toutefois, prenant compte qu’il est plus simple de faire évoluer l’architecture du réseau 4G par l’ajout d’une fonction qui expose des services [1], la spécification 3GPP a proposé l’ajout d’une nouvelle entité matérielle. Ainsi, l’entité fonctionnelle MTC-IWF a été abandonnée au profit de la fonction SCEF : Service Capacité Exposure Function.

Pour résumer, chaque entité fonctionnelle de l’architecture 4G est connectée point à point avec les autres entités par une interface normalisée.

A travers cet interface, les entités offrent des services à une autre entité : le service est une action exécutée par un « fournisseur » (ou « producteur ») à l’intention d’un « client » (ou « consommateur »).

A l’instar du rôle des entités de la 4G, l’architecture SOA (Service Oriented Architecture) s’appuie sur deux éléments principaux : un fournisseur de services et un consommateur de services. Ces deux rôles peuvent être joués par un agent logiciel.

La différence importante entre une architecture 4G et l’architecture SOA concerne la mise en relation des fonctions. Nous allons maintenant nous intéresser aux architectures SOA et microservices facilitant le développement logiciel de nouvelles fonctions.

2. Evolution du réseau de mobile vers l’architecture SOA et l’architecture microservices

II-a) L’architecture SOA

Définition : une architecture orientée services (SOA) est une architecture logicielle qui fait référence à une application composée d’agents logiciels discrets et faiblement couplés qui exécutent une fonction requise. Le concept de SOA est le suivant : une application peut être conçue et construite de manière à ce que ses modules soient intégrés de manière transparente et puissent être facilement réutilisés.

Dans une architecture SOA, les fonctions sont connectées les unes aux autres par un médiateur nommé bus d’intégration ESB.

Le bus d’intégration ESB est un logiciel (middleware) facilitant l’échange de données entre différentes fonctions logicielles (application).

Le logiciel ESB est le point de connectivité pour toutes les applications, et il garantit la sécurisation des échanges.

Le logiciel ESB enregistre les services que fournit chaque application (appelée capacité de service) dans un registre. Les applications publient une ou plusieurs de leurs capacités via le bus ESB et les consommateurs peuvent interagir avec ces applications sans même savoir ce qu’est une application

Le bus ESB centralise les informations et répartit le travail entre les applications. Le bus ESB agit comme un pont de données entre les applications. Le routage des données et la répartition de charge sont assurées par l’application BPM (Business Process Management).

Le bus d’intégration ESB permet de fusionner (interconnecter) diverses applications, anciennes comme récentes, pouvant fonctionner sur des systèmes d’exploitation différents et pouvant utiliser des protocoles différents [2]. Le bus d’intégration s’appuie sur des connecteurs sur lesquelles sont connectées les applications. Les connecteurs garantissent l’interopérabilité entre les applications.

Chaque application fournit et consomme des services : les applications exposent des services à travers des interfaces de programmation d’application API (Application Programming Interface). La gestion des API est fondamentale, elle permet aux développeurs d’utiliser des services back-end pour la supervision et permet de garantir l’agilité du réseau (Agilité [3] : Capacité de changer les choses rapidement).

L’architecture SOA permet donc de réduire le temps de déploiement de nouveaux services.

II-b) L’architecture microservices

L’architecture en microservices consiste à concevoir un ensemble de services autonomes qui communiquent entre eux via une API. Les microservices communiquent via des protocoles HTTP (REST), ou via AMQP (Advanced Message Queuing Protocol) en asynchrone chaque fois que cela est possible, surtout pendant la propagation de mises à jour avec des événements d’intégration. Cette communication se produit par le biais d’un bus d’événements pour propager les mises à jour sur les microservices ou pour s’intégrer à des applications externes.

Un microservice [2] doit réaliser une seule fonctionnalité de l’application globale. En général, chaque microservice est déployé en tant que conteneur indépendant, ou dans une machine virtuelle.

Le concept de conteneur est le plus généralement adopté car il consomme peu de ressource (l’application n’a pas besoin d’un système d’exploitation complet) et il améliore la sécurité, puisque la containerisation permet d’exécuter un programme de manière isolée du noyau d’un système d’exploitation (kernel).

Cette architecture apporte :

de la souplesse puisqu’il est possible de développer ou modifier un microservice sans affecter les autres sous-systèmes : chaque microservice étant déployé indépendamment grâce aux solutions de virtualisation et de conteneur, une nouvelle évolution d’un seul service peut rapidement être testée et re-déployée ;
de l’élasticité puisqu’il est possible de dimensionner dynamiquement le réseau en fonction du nombre de sollicitation (montée en charge = scalabilité). En cas de trafic croissant, il suffit de multiplier le nombre d’instances d’un microservice.

Chaque microservice dispose si possible de sa propre base de données, ce qui le découple entièrement des autres microservices. Quand elle est nécessaire, la cohérence entre les bases de données des différents microservices est obtenue à travers l’utilisation d’événements d’intégration au niveau de l’application (via un bus d’événements logiques)

A l’instar d’un bus d’intégration, l’architecture microservice utilise un bus d’évènement et un logiciel d’équilibrage de charge (load balancer) afin de mettre en relation des services.

Un bus d’événements est un logiciel (middleware) qui permet une communication de type publication/abonnement entre les microservices, sans nécessiter que les composants soient explicitement informés de la présence des uns des autres.

Figure 2 : Bus d’évènement

Lorsque le microservice publie un évènement, il ne sait pas que cet évènement sera diffusé vers les microservices B et C. Il ne connait pas les abonnés, ceux-ci se sont enregistrés auprès du bus d’évènement MOM (Message Oriented Middleware comme par exemple RabbitMQ).

Si le microservice est stateless, une même requête produit toujours la même réponse. Ainsi, le bus d’évènement met en relation les deux services qui doivent communiquer directement l’un à l’autre. Lorsque plusieurs instances sont activées, l’équilibrage de charge définit quelles instances doivent être sollicitées. L’architecture microservice est donc bien adapté pour dimensionner le système en fonction de la charge.

En contrepartie, cette architecture peut entraîner des soucis de performance puisque chaque microservice peut faire appel à plusieurs microservices. Ainsi, le temps de réponse du plan de contrôle (ce qui revient à la latence) est accru pour chaque dépendance supplémentaire entre microservices.

II-c) Microservices : les bonnes pratiques du SOA

L’architecture SOA est composée d’applications logicielles réutilisables. Les services sont exposés via des API. L’interface, c’est-à-dire le couplage entre applications est faible ce qui permet d’appeler ces services avec peu de connaissance sur la manière dont les services sont implémentés. Cela permet de réutiliser rapidement des services.

A l’instar du SOA, l’architecture microservice est conçu sur un ensemble de fonctions faiblement couplés.

3. Architecture des réseaux de mobile 5G

III-1) Architecture SBA

Les fonctions du cœur de réseau 5G sont très proches des fonctionnalités du cœur de réseau 4G. L’évolution Next-Gen (NG Core) consiste à séparer le plan de contrôle du plan de trafic. Concernant le trafic, pour le réseau 5G comme pour le réseau 4G, les données IP sont encapsulées par le protocole GTP-U à travers un tunnel. Le protocole GTP-U est utilisé entre la station de base gNB et les fonctions UPF (User Plane Function).

L’architecture du plan de contrôle du réseau de mobiles 5G est une architecture hybride entre des applications Cloud Native, et la virtualisation.

Sur la figure 3, on présente à gauche l’architecture monolithique traditionnelle, et deux solutions complémentaires : la virtualisation des fonctions réseaux (NFV : Network Function Virtualization) et la méthodologie Cloud Native.

Figure 3 : L’architecture monolithique, l’architecture de virtualisation VNF et l’architecture Cloud CNF

Une application Cloud Native (CNA) est développée sous forme de microservices faiblement couplés. Chaque microservice est conditionné dans un conteneur. Un orchestrateur central planifie les conteneurs pour gérer efficacement les ressources du serveur et réduire coûts opérationnels. Les CNA nécessitent également un environnement DevOps.

DevOps fait référence à une méthodologie qui prend en compte le développement logiciel avec les contraintes d’administration des infrastructures informatiques. La partie développement (Dev) intègre le développement logiciel, l’automatisation et le suivi du projet informatique et la partie opérationnelle (ops) intègre l’exploitation, la maintenance et la supervision de l’infrastructure informatique. L’équipe opérationnelle (ops) gère la stabilité du système et le contrôle de la qualité des services, et l’équipe développement (Dev) cherche à améliorer les services à moindre coût en ajoutant de nouvelles fonctionnalités. L’équipe ops doit donc constamment valider les évolutions proposées par l’équipe dev.

La méthodologie DevOps permet d’obtenir les avantages suivant pour les applications Cloud Native :

une évolutivité facilitée par une architecture modulaires (microservice) ;
la réduction du CAPEX et de l’OPEX par mutualisation des applications (hébergement sur des machines virtuelles ou conteneurs) ;
l’automatisation des fonctions applicatives.

La solution alternative NFV (Network Function Virtualization) a été initialement proposée et adaptée au cœur de réseau 5G par le groupe de travail de l’ETSI. L’architecture NFV décrit les interactions entre l’infrastructure matérielle (NFVI), la gestion des machine virtuelles (VNFM : Virtual Network Function Manager) et l’automatisation des VM sur les infrastructures matérielles.

La spécification NFV a permis de définir un environnement stable pour la mise en place automatisée de machines virtuelles et de conteneurs, chaque VM ou conteneur exécutant une fonction du réseau 5G (NFV : Network Function Virtualized).

L’architecture SBA du cœur du réseau de contrôle 5G est une solution hybride SOA/microservices.

Figure 4: L’architecture SBA du réseau 5G [9]

La mise en place des fonctions réseaux, la supervision (monitoring) nécessite un orchestrateur afin d’automatiser le déploiement des services (établissement ou relâchement d’un service ou d’un microservice). Une plateforme de service permet de fournir un environnement temps-réel qui utilise une pile de protocoles open-source pour le déploiement de fonction réseaux NF.

La plateforme de service permet l’intégration et le déploiement de nouvelles fonctions sur un réseau en production :

CI : l’intégration continue de nouvelles fonctionnalités (CI – Continuous Integration) ;
CD : le déploiement continue ou la distribution continue permettant d’automatiser l’ajout d’un nouveau code dans une bibliothèque de code partagé et dans un environnement de production (CD – Continuous delivery/continuous deployment), et résoudre ainsi la difficulté connue sous le nom « integration hell», ou l’enfer de l’intégration.

L’approche CI/CD permet de créer de créer plusieurs versions d’une application, chaque version étant gérées par un serveur de distribution (un serveur référentiel comme github) et de développer l’environnement client afin de tester rapidement la nouvelle version.

Une fois testée en laboratoire, il est assez rapide de rajouter une nouvelle fonction réseau NF (avec la nouvelle version) tout en conservant en parallèle l’ancienne version de la fonction. Le client peut ainsi tester sur son environnement réel la nouvelle version et la conserver en production.

Figure 5 : L’approche CI/CD [9]

L’environnement complet est représenté sur la figure 6 suivante

Figure 6 : L’environnement de production du cœur de réseau 5G [8]

L’approche CI/CD est parfaitement adaptée pour la mise en place du découpage de réseau (Network Slicing) puisqu’elle permet de déployer des nouvelles fonctionnalités rapidement en fonction des spécificités de chaque service.

Figure 7 : L’architecture SBA [10]

MOLI : Management and Orchestration Layer Interface

SOBI : Southbound Interface (SoBI)

III-2) Les fonctions réseau NF (Network Function)

Les fonctions réseau NF se compose d’opérations basées sur un modèle de demande-réponse ou sur un modèle de souscription/notification.

Le protocole HTTP2 est un protocole commun à l’ensemble des fonctions du réseau (NF) remplaçant ainsi les protocoles DIAMETER, GTP-C du réseau de mobiles 4G. Les fonctions réseaux NF communiquent à travers l’interface SBI grâce à un système d’API, principalement le JSON.

Figure 8 : L’interface SBI entre deux fonctions NF

Dans l’architecture SOA, un bus d’intégration permet la communication entre chaque fonction NF. Lorsqu’une fonction NF démarre, elle interroge dans un premier temps un catalogue de fonction pour découvrir les fonctions existantes et communiquer avec elles. Nous avons vu précédemment que le bus ESB enregistre les services que fournit chaque application (appelée capacité de service) dans un registre.

Dans l’architecture réseau 5G, le catalogue de fonction se nomme NRF (Network Repository function). Il offre un service de découverte des fonctions du réseau de mobile et un service d’enregistrement (service registration management et service discovery mechanisms).

La fonction NRF:

implémente une fonction d’authentification via une règle de sécurité d’accès sur chaque requête de services reçue
délivre un certificat à la fonction NF qui l’interroge. La fonction NF initiatrice d’une requête pourra ainsi prouver son authenticité à la fonction NF cible (qui rend le service).

Figure 9 : L’interface SBI et la communication JSON

Dans le cas de l’architecture SOA, les événements d’intégration sont utilisés pour synchroniser l’état du domaine sur plusieurs fonctions (microservices ou systèmes externes). Cette fonctionnalité est effectuée en publiant des événements d’intégration.

La fonction NF peut se décomposer en plusieurs microservices, notamment un agent_NRF permettant à la fonction NF de se déclarer auprès du NRF. Ainsi, en cas d’évolution de la fonction du NF, l’agent_NRF peut mettre à jour les fonctionnalités au niveau du NRF.

Lorsqu’un événement est publié sur plusieurs microservices récepteurs (sur tous les microservices abonnés à l’événement d’intégration), le gestionnaire d’événements de chaque microservice récepteur gère l’événement.

Figure 10 : Le NF découpé en microservice (Source China Telecom [11])

Dans l’architecture microservices, chaque microservice dispose de sa propre base de données. Pour l’architecture SBA du réseau 5G, la fonction réseau NF (microservice) dispose soit de sa propre base de données UDSF (Unstructured Data Storage Function) soit partage la base de données UDSF avec plusieurs NF.

Comme en 4G, la base de données UDSF contient le contexte de chaque mobile UE (User Equipment).

Figure 11 : La base de données

4. Conclusion

Si le cœur de réseau 5G présente beaucoup d’analogie fonctionnelle avec le cœur de réseau 4G, l’évolution majeure consiste en un découpage de fonction réseau NF dans un environnement agile permettant de déployer et adapter dynamiquement le cœur de réseau en fonction de la charge et d’apporter rapidement de nouvelles fonctionnalités.

La méthodologie DevOps et l’approche CD/CI permet la mise à jour de certains microservices tout en conservant des microservices de versions plus anciennes pour assurer la stabilité avec des terminaux non compatibles avec cette mise à jour.

Ainsi en maintenant des microservices en fonction (version 1.0) tout en proposant des microservices dans une nouvelle version (version 1.1) cela permet à certains téléphones de profiter des dernières évolutions sans impacter certains terminaux mobiles qui peuvent continuer à fonctionner sur les anciennes versions.

Figure 12 : Le cœur de réseau 5G [7]

L’architecture SBA permet donc une meilleure adaptation aux évolutions de service (Network Slicing).

Figure 13 : Comparaison de l’architecture monolithique et SBA (HPE [12])

La figure 14 fait une synthèse des améliorations ainsi apportées par l’architecture SBA

Figure 14 : Comparaison des architectures [4]

Références :

[1] Andrea Zerial

https://www.organisation-performante.com/le-monolithe-dans-l-it-pour-en-comprendre-l-origine/

https://www.organisation-performante.com/les-evolutions-du-si-2-soa-et-le-monolithe-seffrita/

[2] Mickael BARON : https://mickael-baron.fr/soa/introduction-microservices

[3] Thimothée Barray : https://slides.com/tyx/sflive2020-bb8c28

[4] Michael Sukachev : https://fr.slideshare.net/MichaelSukachev/soa-vs-microservices-vs-sba

[5] Jonathan Huteau, Jérôme Cognet,

https://blog.link-value.fr/architectures-de-projet-b42dc5213857

[6] https://www.ibm.com/cloud/blog/soa-vs-microservices

[7] https://docs.microsoft.com/fr-fr/dotnet/architecture/microservices/multi-container-microservice-net-applications/integration-event-based-microservice-communications

[8] https://images.samsung.com/is/content/samsung/p5/global/business/networks/insights/white-paper/cloud-native-5g-core/Cloud-Native-5G-Core-Samsung-5G-Core-Volume-2.pdf

[9] https://www.redhat.com/fr/topics/devops/what-is-ci-cd

[10] https://5g-monarch.eu/wp-content/uploads/2019/05/5G-MoNArch_761445_D2.3_Final_overall_architecture_v1.0.pdf

[11] https://www.3g4g.co.uk/5G/5Gtech_6004_2017_11_Service-Based-Architecture-for-5G-Core-Networks_HR_Huawei.pdf

[12] http://www.hpe.com/info/5g

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

Posté le 22 février 2021 by flaunay - 1 712 vues

Répondre

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 2 – Niveau Master (Chap 1 – Part 3)

Posté le 18 février 2021 by flaunay - 2 148 vues

Répondre

Les Modes de transmission

2.3 LTE et MIMO

2.3.1 Chaîne de transmission dans le sens descendant.

La couche physique du LTE se décompose en sous-bloc afin de répartir les flux d’informations issues de la couche MAC en bloc de transport jusqu’au mappage OFDM transmis sur chaque antenne.

Le synoptique de la chaine de transmission est décrite à la figure 2.10.

Figure 2.10. Chaîne de transmission MIMO

Afin de détailler le rôle de la chaîne, nous allons séparer l’étude en trois sous-parties :

Description de la chaîne entre les mots de code (codeword) aux couches spatiales
Description de la matrice de Précodage et association avec les modes de transmissions
Affectation aux ressources spectrales : Association du signal de référence au port d’antenne.

2.3.1.1 Chaîne de transmission du mot de code aux couches spatiales

A chaque TTI, la couche MAC délivre un ou deux bloc de transport (de taille TBS)

Un code CRC (cyclic redundancy check) de 24 bits est rajouté au transport bloc. L’objectif est de détecter une erreur de transmission. Le code CRC est le reste de la division euclidienne du transport block par le générateur G exprimé par l’équation suivante.

La séquence binaire est ensuite segmentée en bloc de codage. Un CRC de 8, 16 ou 24 bits est rajouté à chaque bloc de codage avant d’être codé par un turbo-code ou un code convolutif. Le Turbo code utilise deux entrelaceurs dont la taille minimum est de 40 bits et la taille maximum est de 6144 bits (la norme propose 188 tailles différentes). Les codes bloc ont donc une taille comprise entre 40 bits et 6144 bits.

Le turbo code a un rendement de 1/3, le signal est ensuite poinçonné ou répété afin d’adapter la taille du flux de bits de sortie au débit désiré.

Le flux de bits ainsi obtenu se nomme codeword ou mot de code.

Figure 2.11. Couche Physique LTE

Le mot de code est ensuite embrouillé par une séquence pseudo-aléatoire de Gold (scrambling) et modulé suivant la modulation QAM définie par la couche MAC. La séquence de Gold est calculée en fonction de l’identité de la cellule, et avec l’identifiant RNTI de l’UE pour les canaux PDSCH, PUSCH et PUCCH. Ainsi, le récepteur peut séparer les mots de code provenant de cellules différentes dans le sens descendant et les mots de code provenant d’UE différent dans le sens montant et d’un même UE dans le cadre du MIMO.

Les mots de blocs embrouillés et modulé sont issus de la segmentation du bloc de transport ou des blocs de transport et constituent les sources d’entrées du bloc MIMO. On numérote par 0 et 1 les mots de code issus des blocs de transport.

En R.8, dans le sens descendant, les mots de code peuvent être transmis sur 1, 2 ou 4 antennes physiques. Dans le cas d’un retour d’information, l’eNb utilise l’information du rang de la matrice de propagation (RI) pour définir le nombre de couches spatiales utilisable par l’UE. Le nombre de couches spatiales est inférieur ou égale au RI. Le bloc Layer Mapper a pour objectif d’associer le ou les mots de codes au nombre de couches spatiales. Le nombre de couche spatiale est donc de 1, 2 ou 4 pour la R.8 et jusqu’à 8 antennes à partir de la R.10.

Figure 2.11. Layer Mapper

La figure 2.7 est un exemple de mise en correspondance de deux codewords vers 4 couches spatiales. Cependant, les différentes combinaisons résumées dans la table 2.7 existent.

Table 2.7. Associations entre mots de code et couches spatiales pour le sens descendant

SM : Spatial Multiplexing et DT : Diversity Transmission

2.3.1.2 Les matrices de précodage et les modes de transmission en DL

Après avoir disposé les mots de codes sur les différentes couches spatiales, chaque couche spatiale est précodée par des coefficients complexes en fonction du mode de transmission (TM) et transmis vers des ports d’antennes. Nous reviendrons sur la notion de port d’antenne ultérieurement et sur l’association entre les ports d’antennes et les antennes physiques.

Le traitement du signal consiste à convertir L couches spatiales vers N ports d’antennes en multipliant les symboles d’entrées par des coefficients complexes (matrice de précodage de taille N x L).

Le précodage s’appuie sur une matrice extraite d’un livre de code (codebook). Le livre de code est connu par l’UE et l’eNb et dans le cas de l’estimation du CSI avec retour vers l’émetteur, l’UE informe l’eNb de la matrice de codage la plus adaptée parmi la liste définie dans le livre de code. L’UE renvoie le numéro de la ligne correspondant à la matrice et cette information est portée par le PMI.

Dans le sens descendant, 10 modes de transmission ont été définis :

TM1 à TM7 ont été définis dans la R.8.
TM8 a été défini dans la R.9
TM9 a été défini dans la R.10
TM10 a été défini dans la R.11
TM9 a évolué dans la R.13 pour gérer les UE dédiés aux objets connectés.

TM1 : Single Transmission antenna.

Dans le cas de la transmission SISO, une seule antenne est utilisée à l’émission et une seule en réception.

TM2 : Transmit Diversity

La diversité de transmission utilise :

pour deux antennes d’émission : le codage SFBC (Space Frequency Block Coding). Il s’agit du codage Alamouti exploité en fréquence et non en temps (ce qui le différencie du STBC). La figure 2.4 illustre le code Alamouti en temps, on retranscrit le code dans le domaine fréquentiel :

En écrivant :

Alors, on obtient :

La matrice de précodage est donc (cf. section 6.3.4.3 3GPP TS 36.211) :

Pour 4 antennes d’émission : le codage FSTD (Frequency Switched Transmit Diversity) : 4 symboles sont découpés en 2 paires, chaque paire est transmise sur deux antennes comme le SFBC sur des RB différents (frequency switched). Chaque ligne de la matrice correspond un port d’antenne :

est le code en temporel. Lorsqu’on retranscrit en fréquentielle, on obtient :

Se référer à la section 6.3.4.3 3GPP TS 36.211

Les canaux PDSCH, PDCCH et PBCH utilisent la diversité de transmission.

TM 3 – Open loop spatial multiplexing with CDD (Cyclic Delay Diversity)

Le multiplexage spatial en boucle ouverte se base sur le choix d’une matrice de précodage au niveau de l’émetteur sans connaissance de l’estimation du canal. En général, ce mode est choisi lorsque l’UE se déplace rapidement (scénario de haute mobilité) et le temps de calcul de l’estimation du canal (PMI) est supérieur au temps de cohérence du canal. Le RI est néanmoins transmis à l’eNb mais pas le PMI.

Ce mode supporte le multiplexage spatial de 2 ou 4 couches transmises simultanément sur 2 ou 4 antennes. La matrice de précodage utilisée en émission est connue par le récepteur et se calcule par le produit de trois matrices : Une matrice de taille N x L et deux matrices carrées D et U de taille L x L : D.U

La matrice W distribue le signal provenant de chaque couche vers les P ports d’antennes, la matrice D permet d’avoir un décalage alors que la matrice U distribue l’énergie sur chacun des ports d’antennes.

Avec :

Table 2.8. Bibliothèque de matrices de précodage pour deux ports d’antennes

Afin de connaitre la position des colonnes constituant la matrice de précodage W, on se réfère à la spécification TS 36.211 Table 6.3.4.2.3-2 (cf. table 2.9).

Table 2. 9. Bibliothèque Tableau de codes pour la transmission sur 4 antennes en DL

Pour l’index 0 et pour deux couches spatiales, la matrice de précodage est constituée de la colonne 1 et de la colonne 4 de la matrice w₀, laquelle se calcule à partir du vecteur u₀.

Pour le mode de transmission TM3, 4 antennes, l’index est 12, 13, 14 et 15.

Les matrices D et U sont définies dans la spécification 3GPP TS 36.211 (Table 6.3.4.2.2-1) :

Table 2.10. Matrice de précodage : Matrices U et D

CDD représente la diversité temporelle : Un bloc est retransmis avec un retard spécifique constant représenté par U

TM3 : Transmit Diversity

Le TM3 nécessite uniquement l’information RI. Le PMI n’est pas transmis. Dans le cas où le rang de la matrice est unitaire, le mode TM3 est utilisé pour la diversité d’émission

Dans ce cas, la matrice de précodage est identique à la matrice de précodage du mode TM2

TM 4 – Multiplexage spatiale en boucle fermée (CSI transmis à l’émetteur)

Ce mode supporte le multiplexage spatiale SU-MIMO jusqu’à 4 couches spatiales multiplexées jusqu’à 4 antennes. L’estimation du CSI est réalisée à partir du CRS ce qui signifie que le retour de l’UE n’exploite pas de pilote dédié à l’UE.

La matrice de précodage s’appuie

Sur la table xx.8 pour un utilisateur transmettant un ou deux couches spatiales sur 2 ports d’antennes.
Sur la table xx.9 pour un utilisateur transmettant une à 4 couches spatiales sur 4 ports d’antennes.

Dans le TM4, les mêmes ressources temps fréquentielles sur les différentes antennes sont transmises vers un seul UE

TM 5 – MU-MIMO

Ce mode est similaire au TM4, il supporte la fonction de multiplexage spatial en boucle fermée de deux utilisateurs (MIMO 2×2) ou de 4 utilisateurs (MIMO 4×4). La matrice de précodage est extraite à partir des mêmes tables.

Dans le TM5, les ressources temps fréquentielles sur les différentes antennes sont transmises vers plusieurs UE

TM6 : Multiplexage spatial en boule fermé en utilisant qu’une seule couche de transmission.

Ce mode est un cas particulier du TM4 pour lequel le rang de la matrice (RI) est 1. L’UE estime le canal et retourne l’index PMI de la matrice de précodage la plus adaptée.

Dans le cas de deux antennes, la matrice de précodage est définie par la table xx.8 (1^ère colonne) et par la table xx.9 (1^ère colonne) dans le cas de 4 antennes.

TM7 : Faisceau de voie (Beamforming)

Le mode TM7 peut être vu comme le mode TM6 en boucle ouverte. Le faisceau de voie est dédié vers un UE, l’estimation du canal s’appuie de la part de l’UE sur le signal de reference UE-specific RS. Ainsi, les données et l’UE-RS sont précodés par la même matrice.

TM8 : Faisceau de voie sur deux couches

La R.8 a spécifié le beamforming sur une seule couche (TM7). La R.9 a specifié le beam-forming sur 2 couches. Ainsi, le TM8 permet de combiné le beamforming avec un multiplexage spatial pour un ou plusieurs utilisateurs. L’utilisation de deux couches permet également de faire du SU-MIMO ou du MU-MIMO.

TM9 : Faisceau de voie sur deux couches

La R.10 a spécifié le TM.9 pour étendre les configurations du MIMO sur 8 antennes. Ainsi, le SU-MIMO et le MU-MIMO sont définies dans le TM9 (comme une extension du TM4 et du TM8)

Pour pouvoir exploiter 4 antennes supplémentaires, la R.10 propose 8 signaux de références nommés CSI-RS et de nouvelles matrices de précodage calculées à partir des mots de codes existants : W=W₁W₂ ou :

W₁ est une matrice de précodage diagonale large bande permettant de définir la sélection de voies
W₂ change la phase du signal sur chaque polarisation de l’antenne

TM 10

Le TM10 est similaire au TM9 mais les antennes utilisées peuvent être sur des eNb différents. Le TM10 supporte la technologie COMP

xx.3.1.3 Les matrices de précodage et les modes de transmission en UL

La R.8 et la R.9 ne spécifient pas la possibilité de faire du MIMO sur le sens montant.

A partir de la R.10, les UE supportent le MIMO jusqu’à 4 couches, il n’existe donc que deux modes de transmission en Uplink :

TM1 : SISO

TM2 : Closed loop spatial Multiplexing

2.3.2 Les mappage sur les éléments de ressources

Le dernier bloc de la chaîne de transmission correspond à l’association entre les ports d’antennes et les antennes physiques.

Les ports d’antennes sont des entités logiques qui se définissent par les signaux de références qu’ils transportent. La table xx.11 fait l’association du port d’antenne et du signal de référence.

Table 2. 11. Association Signaux de références et port d’antenne pour le DL

Signaux de références CRS

Dans le chapitre sur la structure de la trame radio LTE, nous avons vu que les signaux de références CRS sont insérés dans chaque bloc de ressource (RB) émis par la station de base. L’UE doit estimer toute la bande du canal à partir de la connaissance du CRS et même en cas de forte mobilité (120 km/h à 250 km/h).

Les signaux de références CRS sont insérés dans tous les RB de la bande avec un motif répétitif.

Pour un préfixe cyclique normal, le mappage est effectué sur le premier et cinquième symbole OFDM de chaque slot pour les ports d’antennes 0 et 1 et sur le deuxième symbole OFDM pour les ports d’antennes 2 et 3.

Au niveau fréquentiel, les CRS sont espacés de 6 sous porteuses sur chaque port d’antenne et peut prendre une position parmi les 6 positions possibles. La position en fréquence du CRS dépend de l’identité physique PCI de la cellule.

De plus, les éléments de ressource utilisés pour le port d’antenne p0 ne doivent pas être utilisés pour le port d’antenne p1, et vice versa pour éviter les interférences entre antenne.

Ainsi, la figure 2.13 présente le mapping dans le cas du préfixe normal (7 symboles par slot) pour une, deux et 4 antennes

Figure 2. 13. Mappage des CRS dans les ports d’antennes

L’allocation de ressources des données transmises est signalée dans le canal physique PDCCH par l’information .

La table 2.12 propose une synthèse entre le TM et les ports d’antennes.

Table 2. 12. Correspondance entre le TM et les ports d’antennes

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

Posté le 17 février 2021 by flaunay - 2 187 vues

Répondre

Les Modes de transmission

Si vous n’avez pas lu le précédent article, cliquez ici.

2.2. LTE : Trame et le transport des canaux

Le LTE défini un certain nombre de canaux et signaux physiques pour la voie descendante et la voie montante qu’on rappelle sur les tables 2.1 et 2.6. Les signaux physiques permettant l’estimation du canal sont exploités par le MIMO. Nous allons présenter les canaux/signaux physiques en DL/UL selon les releases.

Table 2.1. Canaux et signaux physiques DL

Table 2.2. Signaux physiques DL définies dans la R.9

Table 2.3 Signaux physiques DL définies dans la R.10

Table 2.4. Canaux physiques DL définies dans la R.11

Table 2.5. Canaux physiques DL définies dans la R.12

Le signal physique Cell-specific RS est utilisé pour une estimation du canal de propagation. Il sert également à la mesure de la puissance RSRP (Reference Signal Received Power) et la qualité RSRQ (Reference Signal Received Quality).

Le signal physique MBSFN RS est transmis uniquement sur le canal physique PMCH pour effectuer l’estimation du canal et la démodulation cohérente du signal reçu.

Le signal physique UE-specific RS est utilisé pour mesurer la puissance du signal reçu et pour aider à la formation des faisceaux (estimation du canal pour le beamforming). UE-specific RS est transmis dans le canal physique PDSCH et améliore l’estimation du canal.

Le signal physique CSI RS améliore la mesure du signal reçu au niveau des interférences par rapport au CRS et étend l’estimation du canal à 8 antennes. Le CRS ne peut estimer le canal que pour 4 antennes.

Table 2.6. Canaux et signaux physiques UL

Le signal physique DM-RS associé au canal physique PUSCH ou PUCCH est utilisé pour l’estimation et à la démodulation cohérente du canal physique respectif PUSCH ou PUCCH

Le signal physique SRS permet à l’entité eNb de mesurer la qualité du signal pour le sens montant.

2.2.2 Structure de la trame

Les données sont émises dans une trame découpées en 10 sous trames dont la durée est de 1 ms (nommée aussi TTI : Transmission Time Interval). Chaque sous trame est composée d’une paire de slots.

Au niveau fréquentielle, la trame s’étend sur toute la bande de l’eNb. Selon les possibilités des opérateurs, la largeur de bande est une des valeurs suivantes : [1.4MHz, 3 MHz, 5 MHz, 10 MHz, 15 MHz, 20 MHz].

La bande de fréquence est découpée en sous bande de 180 kHz, elle-même découpée en 12 porteuses espacées de 15 kHz. Pour les largeurs de bandes supérieurs ou égales à 3MHz, l’opérateur doit libérer 10% de bande de garde (5% bande supérieur et 5% de bande inférieure). Ainsi, pour 20 MHz de bande, l’opérateur dispose réellement de 18 MHz de bande ce qui représente 100 sous bandes de 180 kHz.

La méthode de transmission utilisée est l’OFDM : on émet une séquence binaire sur différentes porteuses en parallèle. Chaque porteuse est séparée de 15 kHz, pour assurer l’orthogonalité, la durée symbole OFDM est de 1/15 kHz soit 666.67 µs. ON ajoute à chaque symbole OFDM un préfixe cyclique pour réduire l’interférence entre symbole, on peut ainsi transmettre jusqu’à 14 symboles (14 * 666.67 µs) par sous-trame ou 7 symboles par slot.

On appelle PRB, Physical Ressource Block, un bloc tempo-fréquentielle constitué de 12 porteuses sur une durée d’un slot. Un PRB est donc constitué de 12 porteuses et de 7 symboles OFDM par porteuse soit 84 symboles (0.5 ms et 180 kHz). On appellera RE (Ressource Element) et non symbole l’entité élémentaire car cette ressource est utilisée soit pour transmettre des données soit pour transmettre de la signalisation ou des signaux physiques servant à l’égalisation (apprentissage).

Figure 2.7. Description du PRB

Si on suppose que chaque RE transporte un symbole de DATA alors, selon le mode de modulation (4QAM, 16 QAM, 64 QAM), chaque symbole OFDM transporte respectivement 2, 4,6 ou 8 bits. Un rapide calcul, pour une modulation de 64 QAM sur une bande de 20 MHz conduit à un débit maximum de 84 symboles *6 bits par symbole *100 RB soit 50400 bits sur une durée de 0.5 ms. Le débit théorique maximum est donc de 100,8 Mbit/s.

En réalité un PRB sur deux porte les informations de signalisation (PDCCH) et le reste du PRB et le PRB suivant porte les données (PDSCH).

Figure 2.8. Les canaux logiques et signaux de références sur un slot

Le mapping des canaux est le suivant : l’eNb transmet périodiquement en temps et en fréquence des canaux de références (REF) aidant à l’égalisation du canal de transmission pour les UE en mode de veille (signaux physiques CRS).

Sur une période temporelle d’une demi-trame ou d’une trame, l’eNb transmet respectivement des signaux de synchronisation et d’informations balises sur 64 porteuses au centre de la bande de fréquence du eNb.

Figure 2.9 Les canaux logiques et signaux de références sur une sous-trame

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

Posté le 16 février 2021 by flaunay - 3 063 vues

Répondre

Les Modes de transmission

2.1. Principe Général

Le signal reçu par une antenne est déformé par le canal de propagation, c’est-à-dire par l’environnement qui sépare l’antenne d’émission à l’antenne de réception. D’une part, le canal atténue la puissance du signal émis en fonction de la distance, mais d’autre part, les transmissions sur le canal mobile dans des environnements plutôt urbains (présence de nombreux bâtiments) ou intérieurs (murs, meubles,. . .) provoquent des multi-trajets (équivalent à de l’écho) ce qui génère en réception en évanouissement du signal.

Figure 2.1. Atténuation du signal et évanouissements

On distingue :

les évanouissements à moyenne échelle, dont l’origine est la présence de zones d’ombre, influent sur la distribution de la puissance moyenne reçue. Cette puissance est sensible aux paramètres suivants : Hauteur des antennes, fréquence du signal et topologie de l’environnement (immeubles, relief…).
les évanouissements à petites échelles provoquent une variation rapide du signal reçu. Cette variation est importante sur des faibles distances (il suffit de déplacer l’UE de quelques centimètres pour gagner ou perdre plusieurs dB), sur des faibles temps (en fonction du temps de cohérence du canal) et sur des faibles bandes de fréquence (en fonction de la fréquence de cohérence du canal). Les principales sources d’évanouissement sont les perturbateurs entre l’émetteur et le récepteur créant différentes interactions sur l’onde comme la réflexion, la réfraction, la diffraction, la diffusion.

Figure 2.2. Propagation en milieu exterieur (urbain) : Outdoor

Comme le montre la figure 2.1, les multi-trajets provoquent en réception une sommation constructive ou destructive du signal. Pour contrer les effets du canal, le récepteur chercher à estimer le canal, c’est-à-dire à lui donner une représentation mathématique : un multi-trajet est un retard et une atténuation. Si le récepteur est en mesure de représenter le canal de propagation par une fonction mathématique (comme un filtre à réponse impulsionnel fini), il suffit de calculer la fonction inverse du canal pour récupérer le signal émis.

L’estimation du canal est simplifiée par la connaissance d’une séquence d’apprentissage aussi nommée séquence pilote : l’émetteur émet une séquence connue par le récepteur. Ce dernier compare le signal reçu avec le signal connu pour estimer le canal. Le LTE utilise des signaux de références, que nous verrons ultérieurement. Il existe d’autres techniques pour identifier le canal de manière aveugle.

Le modèle du canal n’est cependant pas inversible et de plus, est sujet au bruit. Afin de remettre en forme les signaux modulés qui ont été modifiés par le canal de propagation, on cherche à estimer le modèle inverse du canal. Il s’agit de l’égalisation du canal.

Il existe plusieurs techniques d’égalisation comme la technique de retour à zéro (ZF : Zero Forcing) qui a pour objectif de converger vers 0 l’interférence inter symbole (aux instants de décision) ou la technique MMSE (Minimum Mean Square Error) qui a pour objectif d’estimer le canal pour avoir une puissance d’erreur moyenne la plus faible possible entre les mesures et le modèle.

Les imperfections du canal influent principalement sur deux critères de performances. Les critères de performance se nomment KPI (Key Parameter Indicator). Le premier indicateur est la capacité qui s’exprime par le débit maximal supporté par le canal (notion de Shannon). Le deuxième indicateur est la probabilité d’erreur (TEB): Il s’agit de prédire la probabilité que le symbole ou le bit émis soit faux. Plus cette probabilité est faible et meilleur est le système.

La technique du MIMO (Multiple Input Multiple Output) permet d’améliorer le KPI. Le MIMO est basé sur plusieurs antennes en émission et plusieurs antennes en réception.

Figure 2.3. Schéma MIMO

On représente le canal de propagation par une matrice H de dimension, chaque coefficient i,j de la matrice représente le gain du canal de l’antenne i vers l’antenne j :

H étant une matrice rectangulaire, la diagonalisation de la matrice H se fait par la méthode de décomposition en valeurs singulières ce qui permet d’écrire H sous la forme suivante :

Avec U , une matrice unitaire de dimension n_R x n_R., \Sigma la matrice diagonale de dimension n_R x n_T à coefficients \lambda_k réels positifs ou nul et V* la matrice adjointe à V, V matrice unitaire de dimension n_T x n_T. Une matrice unitaire est une matrice telle que UU*=U*U=I, I est la matrice identité.

La matrice \Sigma représente le lien du canal entre l’antenne d’émission i et l’antenne de réception i, on se ramène donc à un système équivalent à n SISO, avec n le rang de la matrice H. Le traitement du signal consiste donc à précoder le signal d’entrée par une matrice V et à coder le signal reçu par les n_R antennes par la matrice adjointe de U.

On peut aussi calculer les coefficients de la matrice H \lambda_k à partir de la matrice carrée H.H*. Dans ce cas, la diagonalisation de la matrice carrée H.H* est constitué du carrée des coefficients de la matrice H \lambda_k.

2.1.1 Diversité spatiale : Réduire le TEB

Pour combattre ces fluctuations rapides du signal et réduire le TEB (ce qui revient à dire améliorer la robustesse face au canal), une solution complémentaire à l’égalisation consiste à introduire de la diversité. La diversité est une technique utilisée pour combattre l’évanouissement. Le principe consiste à transmettre plusieurs fois le même signal soit à des instants différents (diversité temporelle), soit sur des bandes de fréquences différentes (diversité fréquentielle), soit avec une polarisation différente (polarisation verticale ou horizontale de l’onde), soit sur des points d’émission différents (diversité spatiale).

La diversité spatiale nécessite au moins deux antennes à l’émission, on parle alors de système MISO (Multi Input Single Output) pour la diversité de transmission ou deux antennes en réception, on parle alors de système SIMO (Single Input Multiple Output) pour la diversité en réception. Mais on peut aussi apporter de la diversité spatiale en émission et en réception avec un système composé de plusieurs antennes à l’émission et plusieurs antennes à la réception. On parle alors de système MIMO (Multi Input Multiple Output).

A titre d’exemple, pour améliorer le signal reçu par deux antennes en réception, il est possible de combiner le signal reçu de chaque antenne comme le montre la figure 2.4 ou plus simplement de sélectionner l’antenne dont le SNR est le meilleur.

Figure 2.4. Recombinaison du signal reçu par deux antennes : Diversité en réception

Le signal transmis étant unique, la recombinaison au niveau du récepteur ne peut être efficace que si les deux signaux reçus ne sont pas corrélés.

Lorsqu’on utilise plusieurs antennes, que ce soit à l’émission ou à la réception, il est nécessaire de séparer les antennes d’une distance environ égale à une demi-longueur d’onde (de l’ordre de 0.45 à 0.5 de la longueur d’onde). En respectant cette contrainte spatiale, le trajet subi par chacune des ondes est indépendant du trajet des autres ondes. Ainsi, le signal reçu par l’antenne est affecté par un bruit gaussien et par des évanouissements différents car chaque signal reçu aura subit des trajets multiples différents.

Cependant, transmettre des données simultanément dans la même bande de fréquence génère des interférences en réception. Il est donc nécessaire d’apporter un traitement aux données avant l’émission afin d’orthogonaliser les flux.

A titre d’exemple, pour un système MIMO 2×2, Alamouti propose un système de codage spatio-temporelle : Soit s₁, et s₂ deux symboles à transmettre pendant une période 2.T. Au lieu de transmettre s1 sur l’antenne 1 et s₂ sur l’antenne 2, on transmet :

Sur l’antenne 1 : s₁ pendant T et -s_2*pendant T ( est le complexe conjugé de s₂)
Sur l’antenne 2 : s₂pendant T et s_1*pendant T

La représentation mathématique est la suivante :

c2 est une matrice orthogonale (en considérant les vecteurs u1 et u2 extraits de chaque ligne ou de chaque colonne, le produit scalaire est nul).

Le récepteur estime le canal de propagation et recombine les échantillons reçus. Les signaux recombinés y₁ et y₂ ne dépendent respectivement que de s₁ et s₂. Le code d’Alamouti découple donc les symboles mais en contrepartie, on ne gagne pas en débit puisqu’on transmet les deux symboles sur un instant 2T. Le code d’Alamouti (nommé aussi STBC : Space-Time Block Code) permet donc de faire de la diversité spatiale en émission.

Tarok a généralisé le code d’Alamouti pour un système de dimension supérieure à 2×2 (nommé OSTBC : Orthogonal STBC) et a proposé un autre type de code prenant en compte la modulation sur les antennes émettrices. Il s’agit des codes spatio-temporels en Treillis ou Space-Time Trellis Code (STTC).

Le synoptique est le suivant :

Figure 2.5. Diversité spatiale par le code d’Alamouti (STBC) : Diversité en émission

2.1.2 Multiplexage spatiale en boucle ouverte : Augmenter la capacité

Au lieu d’exploiter la diversité du signal en transmettant la même information, il est possible de découper l’information en plusieurs flux et de transmettre chaque flux sur une antenne à l’émission vers une antenne en réception. Ainsi, en exploitant les deux réseaux d’antennes à l’émission et à la réception de manière coopérative, il est possible d’augmenter le débit de transmission (la capacité). On parle alors de multiplexage spatial : la largeur de bande est inchangée mais l’efficacité spectrale est augmentée par la dimension des antennes (exemple d’un système MIMO 4×4 : 4 antennes à l’émission et 4 antennes à la réception). Le multiplexage spatial peut être mono-utilisateur, on parle de SU-MIMO (Single User MIMO) ou MU-MIMO (multi-utilisateur). Dans le cas du SU-MIMO, plusieurs flux d’informations sont transmis sur les mêmes ressources en temps et en fréquence vers un seul utilisateur. Dans le cas du MU-MIMO plusieurs flux sont transmis simultanément sur les mêmes ressources en temps et en fréquence mais pour des utilisateurs différents. On peut aussi faire du MU-MIMO en affectant plusieurs antennes par utilisateurs, par exemple pour deux 2 UE possédant 2 antennes et un eNb qui possède 4 antenne peut transmettre en même temps et sur la même bande de fréquence 2 flux vers l’UE 1 sur deux antennes différentes et 2 flux vers l’UE2 sur les deux antennes restantes.

Le SU-MIMO améliore le débit de l’utilisateur, le MU-MIMO améliore la capacité de l’eNb.

Au niveau du récepteur, le détecteur optimal est basé sur le maximum de vraisemblance (ML) lequel nécessite une charge de calcul élevé lorsque le nombre d’antennes et la taille de la constellation sont grands. Il existe d’autres algorithmes sous-optimaux basés sur le ML et le codeur à retour de décision V-BLAST : le symbole de l’émetteur le plus favorisé (possédant le meilleur TEB suivant le critère considéré) est démodulé en premier. Sa contribution au vecteur reçu r est ensuite annulée, ce qui augmente le SNR sur les autres émetteurs (à chaque bonne décision). Cette étape est répétée jusqu’au dernier émetteur, le moins favorisé.

Le débit théorique maximum est alors défini par la formule suivante :

2.1.3 Connaissance du canal à l’émission : CSI (Channel State Information)

Les deux techniques présentées précédemment s’appuyait sur la connaissance du canal (CSI) au niveau du récepteur uniquement. Nous allons maintenant exploiter la connaissance du canal de transmission au niveau de l’émetteur : le récepteur est en mesure d’estimer le canal à partir d’une séquence d’apprentissage émise par l’émetteur. Si le rapport de mesure est transmis à l’émetteur, ce dernier peut alors combiner différemment les symboles à émettre sur les antennes afin de répartir la puissance selon une stratégie bien précise. Cette combinaison est réalisée par un précodeur linéaire à l’émission.

2.1.3.1 Multiplexage spatial avec connaissance du canal de propagation

On parle dans ce cas de multiplexage spatial en boucle fermée (closed loop spatial multiplexing), pour laquelle l’UE calcule par la méthode de décomposition singulière la matrice de précodage V et la matrice de post-traitement U. La matrice de précodage doit être transmise à l’émetteur (retour d’information). Le récepteur couple le traitement par une méthode d’égalisation ZF ou MMSE.

Ainsi, soit x le signal à émettre, le signal précodé est Vx. Le signal reçu est H.(Vx) soit par décomposition on obtient :

Après traitement au niveau du récepteur, le signal est \Sigma.x

Figure 2.6. Principe multiplexage MIMO

Le nombre de réel positif non nul \lambda_k correspond au rang de la matrice H.H* appelé RI : Rank Indicator. Ce nombre permet à l’émetteur de connaître le nombre de couche spatiale indépendant pouvant être utilisé pour cet UE.

Afin d’optimiser le débit, la méthode de WaterFilling permet de répartir la puissance totale vers les différentes antennes en émission. Cela consiste à transmettre plus de puissance aux canaux les plus dégradés afin d’obtenir un rapport signal sur bruit équivalent au niveau du récepteur en résolvant l’équation suivante :

La puissance est répartie sur chaque antenne selon la formule suivante :

avec la contrainte telle que :

2.1.3.2 Diversité Spatiale avec connaissance du canal de propagation : Réduire les interférences (Beamforming)

La technique de beamforming SDMA (Space Division Multiple Access) correspond à un filtre spatial directif pour favoriser le gain dans une direction souhaitée et atténuer la puissance de l’onde dans les directions non souhaitées. Pour le contrôle et la formation des diagrammes de rayonnement, on applique à chaque antenne une pondération correspondant aux critères fixés comme la maximisation du gain dans une direction donnée, ou la maîtrise du niveau des lobes secondaires.

La pondération consiste à réaliser une multiplication par des coefficients complexes, des signaux à émettre sur chaque élément du réseau d’antennes. Ce calcul est similaire au précodage effectué pour le multiplexage spatial, en remplaçant la matrice de précodage par une matrice de Beamforming nommée B et s’appuie également sur la décomposition en valeur singulière de la matrice , et de la méthode d’égalisation ZF ou SMMSE (Successive Minimum Mean Square Error)

Pour calculer la matrice de pré-codage, le réseau d’antennes en réception va chercher à localiser l’émetteur, selon la technique DoA – Direction of arrivals. Au lieu d’estimer la matrice H de manière fréquentiel, le récepteur est un spectre dont les pics identifient les angles d’arrivés (on mesure la puissance du signal en modifiant l’angle d’orientation, le spectre est donc une fonction de l’angle).

L’algorithme du maximum de vraisemblance peut être utilisé pour améliorer la résolution des angles d’arrivés. Parmi les pré-codeurs, il existe un pré-codeur max SNR aussi appelé précodeur Beamforming dont l’objectif est d’orienter le signal dans une direction donnée (réduire le TEB et les interférences).

2.1.4 Conclusion

Le traitement des données s’alourdit en émission et en réception à cause de l’augmentation des dimensions mais grâce à l’augmentation de la puissance de calcul embarquée, la miniaturisation des composants, la technologie des antennes …, il est désormais possible de commercialiser des systèmes MIMO 8×8.

Le MIMO pour un utilisateur permet d’augmenter la capacité de transmission mais cette capacité est malgré tout limitée par le nombre d’antenne de l’UE (en général, l’UE à moins d’antenne que l’eNb). Une autre évolution très importante est le MU-MIMO ou l’eNb génère plusieurs flux simultanément à partir de plusieurs d’antennes d’émission vers plusieurs UE. On parle de MU-MIMO

Cours IUT – Chap 1 (Part 5)

Posté le 13 février 2021 by flaunay - 1 786 vues

Répondre

L’architecture du réseau de mobiles 4G

Suite de l’article précédent

1.5. La transition vers la 5G

1.5.1 La Double Connectivité sur le NG-RAN

L’évolution vers la 5G propose dans un premier temps un scénario de déploiement entre les stations de bases 5G (nommé gNB) avec une station de base 4G eNb (DC option 3C) puis entre les stations de bases 5G avec le cœur réseau EPC (DC option 1A). La solution de DC constitue ainsi la première phase nommée NSA (Non Standalone).

Nous allons donc nous intéresser au DC en considérant l’un des trois scénarios suivants (Figure 1.25) :

eNB est le maître, le gNb est l’esclave
gNB est le maître, le eNB est l’esclave
ng-eNB auparavant nommé eLTE eNB est le maître, le gNb est l’esclave

La station de base ng-eNB est une evolution de la station de base eNB leur permettant d’être interconnectée avec le coeur réseau 5G (appelé 5GC).

Figure 1.25 : La description des scénarios DC pour le réseau 5G

Dans le cadre de la 4G, nous avions défini deux types de séparations de flux :

au niveau des bearers (QoS, ARP) : Split Bearer
au niveau des paquets PDCP : MCG/SCG bearer

En appliquant les principes sur le réseau 5G, nous obtenons :

1 – pour le trafic (U-Plane) ne pas utiliser le gras une séparation (se référer à la figure 1.20)

au niveau des paquets PDCP : SCG bearer
au niveau du SGW

Les paquets sont séparés au niveau de la couche PDCP de la station de base 5G secondaire SgNB (si la station de base eNB est le maître MeNB) ou la station de base 4G secondaire SeNB (si la staion de base 5G gNB est le maître MgNb).

Figure 1.26 : L’architecture protocolaire de la double connectivité en 5G

2 – pour le contrôle (C-Plane), deux options :

Option C1 : Seul la station de base 4G maître MeNB génére les messages RRC transmis au mobile UE
Option C2 : Les deux stations de bases émettent des messages RRC vers l’UE. Cette configuration est nouvelle par rapport à la technologie DC 4G.

Figure 1.27 : La couche RRC pour l’architecture DC en 5G

1.5.2 Le réseau hétérogène 5G

Une solution pour densifier le réseau est de s’appuyer sur le réseau WiFi pour les zones comme les aéroports et les surfaces commerciales. L’UDN (Ultra Dense Network) s’appuie sur une couverture LTE Indoor, le LTE sur la bande non licenciée et le WiFi.

Dans les releases R.13 et R.14, le WiFi est vu comme un point d’accès supplémentaire et la 3GPP propose trois solutions alternatives que nous étudierons dans le chapitre 3 :

Interfonctionnement du LTE et du WiFi afin de transférer le trafic LTE sur le WiFi
LWA : LTE WiFI Aggregation pour lequel on agrège des canaux WiFi avec des canaux LTE
LAA : Licenced Assisted Access permettant d’utiliser la technologie d’accès LTE sur les bandes non licenciées

En 5G, les terminaux pourront exploiter à la fois les stations de bases 4G (eNB), les stations de base 5G (gNb) et les points d’accès WiFi grâce à un découpage des flux sur le réseau de transport fronthaul : L’unité BBU et le module RRU sont décomposés en trois entités nommées CU (Control Unit), DU (Digital Unit) et RRU/AAU (Active Antenna Unit).

L’entité CU gère les ressources radios et l’établissement, le maintien et la libération des DC.

L’entité DU gère la couche physique et la gestion des erreurs (HARQ/FEC).

Le RRU/AAU gère les couches physiques RF/BB pour le massive MIMO.

1.5.3 La réduction de la latence : le Fog Computing

Afin de réduire la latence, une nouvelle entité MEC (Mobile Edge Computing) joue le rôle de Datacenter au plus proche des antennes afin de répondre à des applications de type :

Vidéos
IoT : Internet of Thing
Réalité Augmentée
Cache de données
Intelligence Artificielle

Le MEC est installé au plus proche des antennes, ce qui permet à un grand nombre d’utilisateurs d’accéder en temps réels à des services avec une faible latence. A titre d’exemple, dans le cadre de manifestation sportive (stade de foot), les vidéos professionnelles peuvent être diffusées en locale via un serveur vidéo de broadcast hébergé par le MEC afin que les spectateurs puissent visualiser en temps réel les différents champs de caméra. Pour l’IoT, un serveur d’hébergement peut réaliser les actions à effectuer au niveau du MEC afin d’éviter un transfert de toutes les données vers le serveur d’application hébergé dans le Cloud.

Figure 1.28 : L’évolution du réseau d’accès 5G – MEC/CU/DU/AAU

Pour ceux qui veulent en savoir plus, des formations 5G à distance ou en présentielles peuvent s’organiser.

Contactez moi : frederic.launay@univ-poitiers.fr

Cours IUT – Chap 1 (Part 4)

Posté le 12 février 2021 by flaunay - 1 749 vues

Répondre

L’architecture du réseau de mobiles 4G

Suite de l’article précédent

1.4. La double connectivité

La technologie DC (Dual Connectivity ) est définie à partir de la release R.12 et permet au mobile UE de partager son trafic avec deux stations de base eNB simultanément et par extension permettra de réaliser de l’agrégation de porteuses CA (Carrier Aggregation) sur deux stations de base eNB. On distingue la station de base eNB maître (MeNB Master eNB) et la station de base eNB esclave (SeNB Secondary eNB). Chaque station de base eNB gère son ordonnanceur indépendamment de l’autre. La station de base MeNB est connectée au cœur réseau via l’interface S1-MME, les stations de bases MeNB et SeNB dialoguent via l’interface X2. Le réseau de transport backhaul qui relie les stations de base eNB au cœur réseau peut être non idéal car il n’est pas besoin d’être parfaitement synchronisé entre les émetteurs mais il est nécessaire d’avoir un réseau de transport backhaul supportant un trafic élevé (jusqu’à 3 fois la charge nécessaire pour chaque mobile UE dans le pire cas).

Figure 1.15 : Le plan de contrôle de l’architecture DC

Le mécanisme DC s’applique donc sur deux stations de bases différentes. En général, la station de base MeNB est une macro-cellule et la station de base SeNB est une petite ou micro-cellules, mais le DC fonctionne aussi avec des cellules de mêmes tailles.

Concernant la signalisation (Control Plane), la station de base MeNB établit une connexion S1 avec l’entité MME : Il n’y a qu’une seule connexion sur le plan de signalisation.

Concernant le trafic de données (User plane), le mobile UE est connecté (RRC Connected) aux deux eNB simultanément (deux Radios Bearers). La norme propose 7 architectures différentes, mais seules deux architectures ont été retenues.

les stations de base SeNB et le MeNB établissent chacune une connexion avec l’entité SGW. Il s’agit de l’architecture MCG/SCG bearers, nommée architecture 1A, le plan utilisateur (User Plane) est séparé au niveau du cœur réseau (CN).

seule la station de base MeNB établit un tunnel avec l’entité SGW et le flux est partagé au niveau de la station de base MeNB vers la station de base SeNB. Il s’agit de l’architecture du Split Bearer nommée architecture 3C, le plan utilisateur (User Plane) est séparé au niveau du RAT.

Autrement dit, selon la configuration choisie, soit les flux de données (deux bearers S1) sont émis indépendamment vers les deux stations de base eNB soit les flux de données sont commutés au niveau de la station de base MeNB.

Dans le premier cas, chaque station de base eNB possède sa propre connexion S1-U avec l’entité SGW, chaque station de base eNB configure sa connexion radio pour transporter les données du support (bearer) S1 qui lui est attribué. En cas de mauvaises conditions radio pour la station de base SeNB, le débit du support (bearer) est réduit et donc le transport de ce support (bearer) est affecté. La communication établie entre le mobile UE et les deux stations de base eNB est bi-directionnelle. Cette configuration permet de favoriser le déchargement d’une cellule vers une autre (offloading).

Dans le deuxième cas, le trafic est commuté au niveau de la station de base MeNB. En cas de mauvaises conditions radios pour la station de base secondaire SeNB, la station de base maître MeNB va pouvoir ordonnancer différemment les flux. En contrepartie, dans la release R.12, le lien montant n’est géré que sur la station de base maître MeNB. La gestion du lien montant sur la station de base secondaire SeNB est possible à partir de la release R.13.

Ainsi, la première solution est moins adaptée en cas de mobilité du mobile UE car la mobilité du mobile UE de la station de base secondaire SeNB vers la station de base SeNB impacte l’entité SGW, donc le CN. Quant à la deuxième solution, elle nécessite de pouvoir gérer une charge de trafic plus conséquente au niveau du réseau de transport backhaul.

Enfin, dans les releases R.12 et R.13 les bandes de fréquences des deux stations de base eNB sont distinctes, aucun mécanisme de gestion d’interférence n’a été proposé pour permettre l’utilisation des mêmes bandes.

Figure 1.16 : Les architectures 4G-DC 1A/3C

1.4.1. Le plan de signalisation du DC

Quel que soit l’architecture retenue pour le plan de transport, la terminaison du plan de contrôle S1-MME est ancrée au niveau de la station de base MeNB. L’entité MME ne voit donc pas la station de base secondaire SeNB.

La station de base maître MeNB contrôle la configuration du DC, le MeNB est la seule entité qui transmet et reçoit les messages RRC vers le mobile UE (figure 1.17). La station de base secondaire SeNB gère la couche RLC et la couche MAC. En cas de changement de configuration du support radio ou de handover avec la station de base secondaire SeNB, l’information RRC est échangée entre la station de base secondaire SeNB et la station de base maître MeNB dans un conteneur RRC via l’interface X2. Dans le cas du DC, le mobile UE est configuré pour faire des mesures radios sur les deux cellules (RRM measurements events A3 et A5) et pour réaliser une procédure d’accès aléatoire (RACH). En cas de perte de connexion du lien radio RLF (Radio Link Failure) avec la station de base secondaire SeNB, le mobile UE n’émet aucune requête RRC puisque la connexion radio avec la station de base maître MeNB est maintenue.

Figure 1.17 : La couche RRC pour l’architecture DC 3C

1.4.2. La description du plan utilisateur

Concernant le trafic, celui-ci est partagé entre le mobile UE et les 2 stations de base (MeNB et SeNB). La 3GPP propose une séparation du trafic utilisateur (flux IP) représentée sur les figures 18 et 19.

au niveau de l’entité SGW (QoS, ARP) : MCG bearer/SCG bearer (figure 1.18)
au niveau des paquets PDCP : Split Bearer (figure 1.19)

Initialement, 7 architectures ont été proposées :

1A : 2^ème support (bearer) S1-U est ancré au niveau de la station de base secondaire SeNB et géré par la couche PDCP de cette station de base secondaire SeNB indépendamment du 1^er bearer ;
2A : les 2 supports (bearer) S1-U sont ancrés au niveau de la station de base maître MeNB. Le deuxième bearer est commuté vers la station de base secondaire SeNB et pris en charge par la couche PDCP de cette seconde station de base SeNB indépendamment du 1^er support (bearer) ;
2B : les 2 supports (bearer) S1-U sont ancrés au niveau de la station de base maître MeNB. Le deuxième support (bearer) est commuté vers la station de base secondaire SeNB, géré au niveau de la couche PDCP de la station de base maître MeNB et transmis à la couche RLC de la station de base secondaire SeNB ;
2C : les 2 supports (bearer) S1-U sont ancrés au niveau de la station de base maître MeNB. Le deuxième bearer est commuté vers la station de base secondaire SeNB, géré par la couche PDCP et la couche RLC de la station de base maître MeNB et transmise à la couche RLC de la station de base secondaire SeNB ;
3A/3B/3C se different des architectures 2A/2B/3C par le fait que le 2^ème support (bearer) est commuté à partir de la couche PDCP de la station de base MeNB vers la couche PDCP de la station de base secondaire SeNB

La norme 3GPP propose deux architectures différentes :

Architecture 3C s’effectue au niveau de la couche PDCP. L’eNB maître MeNB effectue une commutation de support (bearer).
Architecture 1A correspond à une séparation de flux au niveau du SGW. Le trafic est séparé et transporté sur deux supports (bearer) S1 logique différent vers les entitées MeNB et SeNB.( MCG/SCG Bearer)

Figure 1.18 : La séparation des flux au niveau du SGW : MCG/SCG Bearer (1A)

Figure 1.19 : La séparation des paquets au niveau du eNB : Split Bearer (3C)

Figure 1.20 : La séparation des flux au niveau de la couche 2

Le mobile UE doit disposer de deux entités MAC et RLC dans le cas du DC, l’une échange le trafic avec la station de base maître MeNB, la seconde échange le trafic avec la station de base secondaire SeNB et d’une seule entité PDCP pour l’architecture Split Bearer ou deux entités PDCP pour l’architecture MCG/SCG bearer.

La fonctionnalité de la couche PDCP pour le mobile UE doit être mise à jour pour pouvoir gérer et ordonnancer des paquets provenant de deux couches RLC différentes et prenant en compte la latence du backhaul.

1.4.3. Le plan de transport

Concernant le réseau de transport backhaul, lors de la séparation du trafic au niveau de la station de base maître MeNB, le flux est transmis de l’entité SGW vers la station de base maître MeNB via des routeurs. Dans l’architecture Split Bearer, la station de base maître MeNB va retransférer les paquets concernant la station de base secondaire SeNB vers le même routeur comme le montre la figure 1.21. Il y a donc un impact sur la capacité du lien du réseau de transport backhaul lors de la séparation des paquets au niveau de la station de base maître MeNB.

Figure 1.21 : Backhaul CN vers les eNB

1.4.4.1 L’interface S1

Concernant le plan de transport, selon la séparation de support (bearer) (figure 1.18) au niveau de l’entité SGW ou la commutation de bearer au niveau de la station de base maître MeNB (figure 1.19), il est nécessaire de construire respectivement deux supports (bearers) S1-U (SGW/MeNB et SGW/SeNB) ou un seul support (bearer) S1-U entre l’entité SGW et la station de base maître MeNB.

Concernant le plan de contrôle, nous avons vu qu’il n’existe qu’une seule interface S1-MME entre l’entité MME et la station de base maître MeNB.

L’architecture 3C est transparente pour le cœur réseau CN, la station de base MeNB fournit ses identifiants de tunnel pour construire le contexte au niveau de l’entité SGW.

Dans le cas de l’architecture 1A, la station de base maître MeNB doit gérer d’une part l’établissement du RAB concernant la station de base secondaire SeNB et d’autre part assister l’entité MME pour l’établissement du contexte de routage au niveau de l’entité SGW. Ainsi deux contextes sont à créer :

Le contexte de routage de support (bearer) de l’entité SGW vers la station de base maître MeNB (procédure classique) ;
le contexte de routage du support (bearer) de l’entité SGW vers la station de base secondaire SeNB. La station de base maître MeNB doit donc informer l’entité MME des paramètres de contextes différents tels que le TEID de la station de base secondaire SeNB et son adresse IP pour pouvoir construire la table d’acheminement de contexte au niveau de l’entité SGW.

L’établissement d’un ou plusieurs RAB est à l’initiative de l’entité MME qui envoie un message E-RAB Setup Request vers la station de base maître MeNB. Pour que la station de base maître MeNB puisse apporter des modifications sur un E-RAB établi, elle envoie une requête E-RAB Modification Indication vers l’entité MME.

La requête E-RAB Modification contient les champs suivant :

Le numéro de tunnel GTP TEID pour la transmission de données vers le SeNB
L’adresse IP du SeNB

Figure 1.22 : La procédure d’établissement d’un support pour l’architecture 1A

Cet échange permet de mettre à jour la table d’acheminement des données sur le plan utilisateur.

1.4.4.2 L’interface X2

Avec la technologie DC, de nouvelles fonctionnalités doivent être rajoutées sur l’interface X2 entre les stations de base maître et secondaire (MeNB et SeNB) pour :

prendre en compte les mesures radios du mobile UE effectuées sur la station de base secondaire SeNB pour que la station de base maître MeNB puisse établir, modifier ou libérer le contexte du mobile UE au niveau de la station de base secondaire SeNB.
informer la station de base maître MeNB de l’acquittement des paquets de la couche PDCP PDU transférer par la station de base secondaire SeNB dans le cas de l’architecture 1A

Ainsi, le protocole d’application X2-AP doit :

permettre à la station de base maître MeNB d’ajouter/de modifier/de libérer des ressources radios entre la station de base secondaire SeNB et le mobile UE ;
permettre de réaliser un handover de la part de la station de base secondaire SeNB ;
Dans le cas d’une séparation des flux au niveau de la station de base maître MeNB (sur la couche PDCP PDU), les données sont sauvegardées au niveau de la station de base maître MeNB puis transférées vers la station de base secondaire SeNB cible.
Dans le cas d’une séparation de bearer au niveau de l’entité SGW, les données doivent être transférées de la station de base secondaire SeNB vers la station de base maître MeNB (phase de préparation du handover).
permettre de réaliser un handover de la station de base maître MeNB ;
Les données sont transférées de la station de base secondaire SeNB vers la station de base maître MeNB source puis de la station de base maître MeNB source vers la station de base eNB cible.
réaliser un contrôle de flux entre la station de base maître MeNB et la station de base secondaire SeNB en cas de séparation de flux au niveau paquets
la station de base secondaire SeNB transmet les Informations Système vers la station de base maître MeNB dans un container SI

A titre d’exemple, la station de base maître MeNB décide de répartir la charge de trafic avec une station de base secondaire SeNB. L’établissement d’un E-RAB avec la station de base secondaire SeNB est initié par la requête SeNB Addition Request. Cette commande a pour objectif de demander à la station de base secondaire SeNB d’allouer des ressources en vue de préparer une opération de Dual Connectivity avec un mobile UE spécifique et de transférer à la station de base secondaire SeNB la clé de chiffrement S-K_eNB dans le cas de l’option 1A (car la couche PDCP est gérée par la station de base secondaire SeNB).

Figure 1.23 : La procédure d’ajout d’une station de base secondaire

Le message SeNB reconfiguration complete permet d’informer la station de base secondaire SeNB de la prise en compte de la configuration au niveau du mobile UE. Le mobile UE reçoit préalablement une requête RRCConnectionReconfiguration pour lui permettre d’associer le support radio de données RAB avec le support bearer EPS. Lorsque la station de base maître MeNB reçoit la réponse RRCConnectionReconfigurationComplete, le RAB est établi et la station de base maître MeNB pourra ainsi transmettre à l’entité MME les adresses IP et les points de terminaisons TEID des tunnels GTP pour la transmission de données.

En reprenant la figure 1.22 et 1.23, l’ensemble des messages pour établir la procédure DC est la suivante :

Figure 1.24 : La procédure d’établissemen DC initiée par le MeNB

Pour résumer, la station de base maître MeNB sélectionne la station de base secondaire SeNB sur laquelle le tunnel supplémentaire va être créé. La release R.13 maintient le principe de sélection de la station de base secondaire SeNB par la station de base maître MeNB, avec une évolution permettant au mobile UE de calculer la différence de marche (timing difference) entre la station de base maître MeNB et secondaire SeNB.

Chaque station de base eNB va gérer le mobile UE de manière indépendante. Cependant, le mobile UE est limité par ses capacités en fonction de sa catégorie (Nombre maximum de bloc de transport DL-SCH, … UE-AMBR, …). La station de base maître MeNB peut donc définir des restrictions sur la capacité de l’UE pour la station de base secondaire SeNB ou la station de base secondaire SeNB peut aussi informer (via l’interface X2) les schémas d’allocation pouvant être assurés par celle-ci pour le mobile UE.

Si le mobile UE détecte un échec du lien radio (dépassement du nombre de RACH, rupture du lien radio, …), alors le mobile UE informe la station de base maître MeNB afin que celle-ci libère le RAB avec la station de base SeNB.

Court IUT – Chap 1 – Part 3

Posté le 11 février 2021 by flaunay - 1 727 vues

Répondre

L’architecture du réseau de mobiles 4G

Suite de l’article précédent

1.3. L’évolution de l’architecture

Afin de faire face à un trafic de plus en plus élevé et afin d’accroitre la couverture, les opérateurs doivent densifier leur réseau cellulaire en ajoutant soit des relais RN (Relay Node) soit des stations de base. La portée de chaque relai ou station est réduite (d’une dizaine de mètres à quelques kms) et constitue ainsi des petites cellules (small-cell).

La release R.10 introduit la notion de relai et des réseaux hétérogènes, la release R.11 optimise les déploiements hétérogènes et la release R.12 propose une optimisation de la mobilité des mobiles UE dans le réseau hétérogène. La release R.12 propose de plus la gestion des cellules (On/Off) selon le trafic. La gestion des cellules répond à deux besoins : Réduire la consommation d’énergie du réseau et réduire les interférences d’une station de base eNB vers une autre station de base eNB.

1.3.1. Les relais

Le nœud relais RN communique avec l’entité eNB via l’interface air nommée Un (backhaul). L’entité eNB se nomme DeNB (Donor eNB) pour le relai RN. L’entité DeNB supporte les fonctionnalités de proxy S1 et X2. A ce titre, il apparait à la fois comme une entité MME pour le RN (interface S1-MME), comme une station de base eNB pour le le RN (interface X2) et comme une entité SGW pour le RN (interface S1). Le mobile UE est connecté au relai via l’interface Uu traditionnelle. Un relai RN ne peut pas être lui-même un relai pour une station de base eNB. Dans les releases R.10 et R.11, le handover inter-relai n’est pas supporté.

On distingue deux types de relai : Les relais aussi appelés répéteurs (Amplify and Forward Relay) récupère le signal émis par la station de base eNB et le re-transmet, amplifiant ainsi le bruit de réception (sans amélioration du rapport signal sur bruit SNR). Pour améliorer la transmission, il est préférable de décoder le signal et le re-transmettre. Il s’agit des relais de type Decode and Forward.

Quel que soit le type de relai, ce dernier est transparent pour le mobile UE, ce qui signifie :

le RN contrôle une cellule et apparait pour l’UE comme une cellule différente du DeNB. Il dispose ainsi de son propre identifiant PCI, de ses signaux de références ;
l’UE reçoit les informations de contrôle d’ordonnancement, l’HARQ et retourne les informations de buffer, de canal CQI et d’ACK au RN

Le relai RN possède deux connexions physiques radios, l’une vers la station de base DeNB, l’autre vers el mobile UE.

Dans la release R.8, afin de ne pas générer d’interférences, le relai RN communique soit sur deux bandes de fréquence différentes entre le mobile UE et la station de base DeNB (isolation RF – outband relay) ou sur une zone géographique non couverte par la station de base eNB en utilisant la même bande de fréquences (inband relay).

La Release R.10 propose de faire du multiplexage temporel entre la communication du relai RN vers la station de base DeNB et la communication du relai RN vers le mobile UE pour le scénario Inband Relay. La gestion de la connexion est gérée par la couche RRC. Les sous trames du lien descendant de la station de base DeNB vers le relai RN sont configurées au niveau du relai RN comme un canal de communication de type MBSFN (Multibroadcast Single Frame Radio) afin de maintenir la compatibilité avec la release R.8 : Le MBFSN permet à la station de base eNB et au relai RN de transmettre sur les 2 premiers octets de la sous-trame (cas du préfixe CP long) la signalisation (PDCCH, PCFICH, PHICH) sans avoir à transmettre les signaux de références (RS). Les sous-trames réservées pour le MBSFN sont les sous trames 1,2, 3, 6, 7 et 8.

Le relai est alors configuré en sous trames MBSFN et de nouveaux canaux de contrôle (R-PDCCH) et de données (R-PDSCH) sont introduits pour utiliser les symboles inoccupés de la trame MBSFN en voie descendantes de la station de base DeNB vers le relai RN. Le R-PDCCH porte les informations de contrôle DCI (Downlink Control Information) pour les relais RN et sont transmis à la place des données du canal PDSCH.

Si la sous trame de numéro n est allouée pour une transmission sur le lien descendant de la station de base DeNB vers le relai RN alors la sous-trame n+4 sera allouée pour le sens montant du relai RN vers la station de base DeNB. Il ne peut donc pas avoir de communication entre le mobile UE et le relai RN pendant cette sous-trame. Il suffit au relai RN de n’allouer aucune ressources PUCCH sur ces sous-trames (ou PDCCH pour la trame précédente). Par contre, le relai RN utilise les sous-trames restantes pour communiquer avec l’UE.

A partir de la release R.10, la 3GPP prévoit des scénarios de déploiement ou les petites cellules sont des entités eNB localisées dans une zone déjà couverte par une macro-cellule, on parle alors de déploiement hétérogène. Toutefois, si le nombre de petites cellules est très élevé, les interférences entre cellules seront importantes. Pour réduire les interférences entre cellules, la release R.12 propose un mécanisme permettant d’activer ou de désactiver des petites cellules en fonction de la charge du trafic (Small Cell On/Off) ou d’augmenter la taille de la cellule (Cell Range Expansion).

1.3.2. Les réseaux hétérogènes

Afin de fournir une capacité élevée (débits par km²), il est nécessaire de densifier l’accès radio en augmentant le nombre de nœuds. Le déploiement hétérogène consiste à superposer aux macro-cellules (réseau overlaid) un réseau de petites cellules (hot-spot, pico-cellules, micro-cellules : réseau underlaid) comme le montre la figure 1.11.

Figure 1.11. Déploiement hétérogène

Le LTE est une technologie d’accès radio large bande, utiliser des bandes différentes entre le réseau overlaid et underlaid conduit à une fragmentation spectrale non optimale. La gestion des interférences est donc un enjeu majeur pour le déploiement hétérogène à re-utilisation de fréquence (single frequency reuse). Nous verrons la gestion des interférences dans le chapitre 4.

Toutefois, si l’opérateur a déployé son réseau de macro-cellules sur une bande de fréquences basses (700 ou 800 MHz), il va plutôt préférer utiliser une fréquence élevée pour les petites cellules.

Dans l’un des trois cas suivant; démarrage, perte de couverture ou de manière périodique, le mobile UE fait une sélection de cellules en identifiant les cellules à partir des signaux de synchronisation et l’identifiant de cellule PCI (Physical Cell Identity) émis par les stations de base eNB. Une fois la cellule sélectionnée, en mode de veille, le mobile UE détecte les cellules voisines et peut faire une demande de re-sélection de cellule.

En LTE, le choix de re-sélection de cellule dépend :

De la fréquence de la bande
Du réseau cellulaire d’accès (2G/3G/4G) nommé RAT

Le mobile UE dispose de critères de déclenchement de recherche de cellule afin d’éviter de faire en permanence des mesures radios. Les règles définies pour le LTE sont les suivantes :

le mobile UE doit faire des mesures sur une fréquence ou un RAT plus prioritaire que la cellule sur laquelle il est connecté ;
une fois à l’écoute de la cellule la plus prioritaire, tant que la puissance du signal de la cellule sur laquelle l’UE est connecté est supérieure à un seuil de référence, l’UE ne fait pas de recherche de cellules voisines. Cela évite à l’UE de consommer de l’énergie pour faire des recherches de cellules ;
si le niveau de la cellule est inférieur à un seuil, l’UE doit réaliser des mesures sur des cellules voisines

En mode de veille, lorsque le critère de déclenchement est atteint :

le mobile UE re-sélectionne une cellule plus prioritaire ;
le mobile UE re-selectionne une cellule de même priorité sur la même fréquence ou sur une fréquence différente en comparant la puissance reçue par la cellule serveuse et les cellules voisines (à partir du signal de référence RSRP). Pour éviter les effets de ping-pong, la puissance mesurée (RSRP) sur la cellule serveuse est augmentée d’une valeur d’hysteresis alors que les puissances mesurées sur les cellules cibles sont diminuées d’une valeur d’Offset. Les valeurs d’offset et de trigger sont émises par chacune des stations de base eNB dans les messages d’informations SIBs.

En mode de veille, le mobile UE peut donc sélectionner une petite cellule grâce aux valeurs d’offset et d’hystéresis paramétrés sur chacune des stations de base eNB.

En mode connecté, la sélection est déclenchée par la station de base eNB en fonction des mesures réalisées par le mobile UE et transmis au mobile UE par le protocole RRC.

Dans le cas déploiement hétérogènes, le mobile UE peut être sous la couverture de stations de bases différentes comme par exemple sous la couverture d’une macro-cellule et d’une pico-cellule comme le montre la figure 1.12.

Si le mobile UE est à l’intérieur de la zone de couverture de la pico-cellule, les liens montant et descendant seront réalisés par la pico-cellule. La zone de couverture est dimensionnée par rapport à la puissance d’émission du nœud. Si le mobile UE est à la périphérie de la zone de couverture, il recevra un meilleur signal en provenance de la macro-cellule mais le lien montant sera moins atténué avec la pico-cellule. Cependant, le mobile UE établi une connexion RRC qu’avec une seule entité eNB.

Figure 1.12. La communication bi-directionnelle dans un réseau hétérogène

Le CRE (Cell Range Expansion) est une technique qui permet d’augmenter la zone de couverture de la pico-cellule afin de décharger le trafic de la macro-cellule.

Figure 1.13 : L’ajustement automatique de la taille des cellules

Le mobile UE mesure le niveau de puissance de la cellule macro et de la pico en ajoutant un biais de 6 à 9 dB sur la puissance RSRP mesurée au niveau de la cellule pico.

1.3.3 Le mécanisme d’extinction des cellules

Même en l’absence d’utilisateur, les stations de base eNb émettent en permanence des signaux de références CRS, des informations de synchronisation (PSS/SSS) et des informations de la voie balise (BCCH). Cela permet à un mobile UE en mode de veille de détecter la présence de station de base eNB. Dans le cas des pico-cellules, la probabilité qu’il n’y ait aucun mobile UE connecté dans la zone de couverture de la pico-cellule n’est pas négligeable. Ainsi, pour réduire les interférences (le rapport signal sur bruit), la release R.9 et le mécanisme SON (Self Optimized Network) permet d’éteindre des cellules lorsque la station de base est très peu chargée. La station de base ne transmet plus aucun signal, elle est à l’état dormant mais peut être réveillée par une station de base voisine via l’interface X2.

Lorsque le réseau décide de basculer une cellule à l’état OFF (peu de trafic), la station de base libère les connexions existantes via le mécanisme de handover ou de re-direction vers une autre cellule. Ainsi, la technique d’extinction d’une pico-cellule ne peut se faire que si d’autres stations de base peuvent couvrir la zone de la pico-cellule.

Toutefois, le fait qu’il n’y ait pas de mobile UE connecté avec la pico-cellule (RRC Connected) n’exclut pas l’existence de mobiles UE en mode de veille à l’écoute de la pico-cellule. De plus, le passage de la pico-cellule de l’état dormant à l’état actif prend une centaine de millisecondes, ce qui ne permet pas de suivre efficacement le trafic et la mobilité des utilisateurs.

La release R.12 améliore l’efficacité du mécanisme d’extinction de cellule afin d’accélérer le temps de passage de l’état dormant à l’état actif en proposant deux mécanismes supplémentaires :

Transmission d’un signal de découverte DRS (Discovery Reference Signal)
Utiliser la commande RRC SCell Activation/Deactivation

Lorsque la cellule est à l’état dormant, la release R.12 propose de transmettre périodiquement un signal de découverte DRS permettant aux mobiles UE supportant cette fonctionnalité de découvrir l’existence de la cellule dormante et de faire des mesures sur cette cellule. Le signal DRS est transmis sur deux sous-trames, afin d’assurer une compatibilité avec les évolutions antérieures : le DRS est composé du PSS, SSS, CRI-RS et du CRS comme le montre la figure 1.14. Le retour des mesures effectuées par le mobile UE vers la macro-cellule peut inciter le réseau à basculer la pico-cellule à l’état actif et le mobile UE peut rapidement se connecter sur la pico-cellule pour l’agrégation de porteuses. Ainsi, la pico-cellule n’est vu que comme une cellule secondaire et le mobile UE active/désactive une connexion avec la cellule par la procédure RRC Activation/Déactivation.

Figure 1.14: Découverte de la cellule : DRS

La périodicité du DRS peut être de 40, 80 ou 160 ms.

COURS IUT Chapitre 1 (Part 1)

Posté le 7 février 2021 by flaunay - 2 924 vues

Répondre

Chapitre 1 : L’architecture du réseau de mobiles 4G

1-1. L’architecture fonctionnelle

Le réseau de mobiles 4G a été défini dans la Release.8 sous le nom EPS (Evolved Packet System).

L’architecture fonctionnelle du réseau EPS est décrite à la figure 1.1. Elle se découpe en deux sous réseaux : un cœur réseau EPC (Evolved Packet Core) et un réseau d’accès radioélectrique E-UTRAN (Evolved Universal Terrestrial Radio Access Network).

Figure 1.1. L’architecture fonctionnelle du réseau EPS (1)

Le réseau d’accès E-UTRAN assure la connexion des mobiles et la réservation des ressources radio entre le mobile UE (User Equipment) et l’entité eNB (evolved Node Base station) sur une bande de fréquences (LTE) ou sur plusieurs bandes de fréquences (LTE-Advanced).

Le cœur de réseau EPC interconnecte les réseaux d’accès, fournit l’interface au réseau de données PDN (Packet Data Network) et assure l’attachement des mobiles, l’autorisation d’accès au service et l’établissement des supports (bearers).

L’architecture protocolaire s’appuie sur le protocole IP (Internet Protocol), chaque entité dispose d’une ou plusieurs adresses IP. Les entités sont connectées entre elles par un réseau de transport (backhaul) constitué de routeurs permettant de faire des marquages de QoS (Quality Of Service). Le protocole de routage utilisé est le MPLS (MultiProtocol Label Switching ) et la QoS est gérée par étiquetage d’un champ d’entête IP nommé DSCP (DiffServ Code Point).

Figure 1.2. Le réseau EPS et le backhaul

1.1.1. L’entité eNB

L’entité eNB est la partie visible du réseau de l’opérateur. L’eNB est composé :

d’une ou plusieurs antennes : l’antenne est l’élément passif qui transforme un signal électrique en une onde électromagnétique et réciproquement ;
d’un ensemble d’émetteurs/récepteurs nommés TRX modulant le signal numérique en signal analogique vers l’antenne et inversement. Les modules TRX gèrent aussi la compensation du signal modulé ;
d’amplificateur de puissance. Le signal issu de l’émetteur est amplifié ;
d’une unité de traitement en bande de base BBU (Base Band Unit).

Le système actif est généralement situé dans un local technique constitué :

d’une alimentation et des batteries de secours (Power Distribution Module)
d’un système de ventilation (Fan Control Module) ;
d’un contrôleur (Control and Maintenance Module) ;
d’élément de transmission (Transceiver Module) ;
des connecteurs d’antennes (Combiner Distribution Unit).

Le local technique est soit positionné au pied de l’antenne, soit dans un abri (shelter) sur le toit (rooftop). La figure 1.3 représente la structure matérielle de l’entité eNb dans laquelle se trouvent l’unité BBU, et le système actif.

Figure 1.3. La description matérielle d’une station de base (2)

Depuis quelques années, on voit apparaître un boitier nommé unité RRU (Remote Radio Unit) ou RRH (Remote Radio Head) proche de l’antenne.

L’unité RRU englobe les fonctions permettant de convertir le signal en bande de base vers un signal radio-fréquence (RF) et inversement.

L’unité RRU est donc composée des modules de transmissions TRX et des amplificateurs.

Figure 1.4. Le découpage BBU et RRU

On sépare ainsi la fonction de bande de base effectuée par l’unité BBU de la fonction Radio Fréquence. Sur la figure 1.4, le module RRU est logé près de l’antenne afin de supprimer l’amplificateur faible bruit TMA (Tower Mounted Amplifier).

L’unité BBU gère la couche physique, elle réalise la pré-modulation, le codage, l’allocation de ressource. L’unité BBU est constituée d’une carte contrôleur et d’une carte SDR (Soft Design Radio) dans un châssis. La carte contrôleur se raccorde à l’entité MME et à l’entité SGW (Serving Gateway) et la carte SDR est connectée au module RRU. La carte SDR (radio logicielle) permet de réaliser le traitement logiciel du signal pour la 2G/3G/4G. Ainsi, le même équipement peut gérer les différents accès radios, ce que réalise l’opérateur lorsqu’il fait évoluer (swap) ses équipements.

Le lien entre l’unité BBU et le module RRU s’appelle le réseau de transport fronthaul. En général, le lien est un câble optique standard nommé CPRI (Common Public Radio Interface). La technologie CPRI transporte les flux de données et la synchronisation entre deux entités : l’entité Radio Equipment (RE) qui correspond au module RRU et l’entité Radio Equipment Control (REC) qui correspond à l’unité BBU. Le rôle du RE est de construire la forme d’onde du signal radio, le REC génère le signal radio. Les données de plan de transport sont numérisées (I/Q) sur M

bits pour chaque secteur d’antenne et pour une seule porteuse (connu sous le nom de concept AC Antenna Carrier).

Il est ainsi possible de transférer différents types de signaux via le CPRI et de reconstruire la forme d’onde au niveau du RE (GSM, UMTS, WiMAX, LTE). Le débit du lien CPRI-1 est de 614.4 Mbps, légèrement inférieur au lien STM-4. La distance entre le RE et le REC peut être de 10 kms. Nativement, le CPRI supporte le multiplexage de 2 CPRI-1, nommée CPRI-2 (1228,8 Mbit/s).

Figure 1.5. REC – CPRI – RE

Prenons un exemple : si l’on suppose que le module RRU doit gérer 4 secteurs opérant chacun sur une bande MIMO 2×2 LTE de 20 MHz, alors il est nécessaire de transmettre 4 groupes (un groupe par secteur) de 2 AC (MIMO 2×2). Si la numérisation est sur M=15 bits par voies (I et Q), alors le débit est de 15*2* 8 AC =240 bits par T_e, T_e étant la période d’échantillonnage. Sachant que pour 20 MHz, la fréquence d’échantillonnage est de fe=30,72MHz alors le débit est de 7372.8Mbps. Une multi-trame est composée d’une trame de synchronisation et de 15 trames de données, le débit réel est donc de 16/15* 7372.8 soit 7864,32 Mbps. Enfin les données sont encodées par un codeur canal 8B/10B, le débit total est donc de 8/10*7864,32=9830,4 Mbps, ce qui correspond à un multiplexage de 8 CPRI-2.

Dans le cas d’une agrégation de porteuses sur 5 canaux (100 MHz) sur 4 secteurs, avec des antennes MIMO 8×8, le débit est alors multiplié par 20.

Il est également possible d’empiler (stack) plusieurs unités BBU, chacune connectée à différents modules RRU créant ainsi un pool de cartes BBU (BBU centralization ou BBU Hosteling), afin d’améliorer la fiabilité du réseau d’accès radio. Il s’agit du Cloud RAN ou C-RAN. L’unité BBU n’est plus distribuée mais centralisée et connectée aux modules RRU par des modules de transports optiques CPRI.

Figure 1.6. La BBU centralisée

Après avoir présenté la partie matérielle, nous allons lister les fonctions de l’entité eNB.

L’entité eNB assure l’établissement du support radioélectrique DRB (Data Radio Bearer) sur lequel est transmis le trafic du mobile dans le sens montant (UL Uplink) et descendant (DL Downlink). Si le nombre de demandes de connexion est trop élevé, l’entité eNB gère la congestion (contrôle l’accès des mobiles UE sur l’entité eNB) en interdisant l’accès à la cellule pour des nouveaux mobiles UE.

L’entité eNB gère les ressources radio et l’attribution des ressources pour chaque utilisateur. Pour cela, l’entité eNB utilise les mesures effectuées par le mobile UE pour décider du déclenchement d’un changement de cellule en cours de session (handover). En plus de gérer la mobilité des utilisateurs en cours de session, les mesures permettent de réaliser un contrôle en puissance et d’assister l’entité eNB à ordonnancer les flux vers les mobiles UE (priorité des flux et gestion des débits entre chaque mobile UE).

Les données sont transmises sur le plan utilisateur (User Plane) et la signalisation est transmise sur le plan de contrôle (Control Plane). L’architecture du protocole radio est présentée dans le chapitre 1.2 (se référer aux figures 1.7 et 1.8). La signalisation permet d’établir ou de ré-établir un tunnel entre le mobile UE et le réseau de données PDN et de préparer les ressources (Accès radio, handover, …).

Le point de contrôle du réseau 4G est l’entité MME (Mobility Management Entity). L’entité eNB transfère la signalisation NAS (Non Access Stratum) du mobile UE vers l’entité MME et de l’entité MME vers le mobile UE via l’interface S1-MME. L’entité eNB effectue la sélection de l’entité MME du cœur de réseau à laquelle s’attache le mobile.

En qualité de point d’accès pour le plan de transport, l’entité eNB transfère les données de trafic provenant du mobile vers l’entité SGW (Serving Gateway), et celles provenant de l’entité SGW vers le mobile à travers un tunnel IP. Ce tunnel est défini par un identifiant d’acheminement nommé TEID (Tunnel End Identifier) et d’un identifiant de la classe de service QCI (QoS Class Identifier). L’identifiant TEID et l’identifiant QCI sont nécessaire pour établir l’acheminement des données et la mise en œuvre du mécanisme d’ordonnancement des données. Ces informations forment un contexte et sont stockées au niveau de l’entité SGW et l’entité PGW (PDN Gateway). L’identifiant QCI permet de marquer les champs DSCP des paquets IP afin de différencier les services proposés par ordre de priorité et de garantir les débits pour certaines applications.

En termes de sécurité, les données entre l’entité eNB et le mobile UE sont chiffrées. La signalisation est également chiffrée et un contrôle d’intégrité permet d’éviter une attaque de type Man In the Middle.

1.1.2. L’entité MME

L’entité MME contrôle le droit d’accès des mobiles UE et les services accessibles pour chaque mobile UE dans le réseau de l’opérateur (PLMN Public Land Mobile Network).

Le droit d’accès au réseau (Home HPLMN ou Visité VPLMN) s’effectue via la procédure d’attachement. Lors de l’attachement, l’entité MME récupère le profil et les données d’authentification du mobile stockés dans l’entité HSS (Home Subscriber Server) et procède à l’authentification du mobile. Cette procédure permet au mobile UE d’authentifier le réseau sur lequel il se connecte et au réseau d’authentifier le mobile UE.

Si la double authentification aboutie, l’entité MME sauvegarde le contexte du mobile UE. Le contexte contient l’abonnement du profil du mobile UE (profil récupéré auprès du HSS) ainsi qu’un ensemble d’informations sur les capacités du mobile UE, la localisation du mobile UE, son identifiant, et les clés de sécurités dérivées.

Les capacités correspondent aux caractéristiques techniques (Information Element) du mobile UE (nombre d’antennes, débit maximum, … ) alors que le profil d’abonnement récupéré au niveau du HSS permet de définir l’accès aux services de l’utilisateur (service voix sur IP, accès Internet, applications objets connectés, …). Le MME récupère également les points d’accès APN (Access Point Name) permettant de déterminer la passerelle permettant d’atteindre le PDN spécifique.

Lors de l’attachement, l’entité MME enregistre l’identité de la zone de localisation TAI (Tracking Area Identity) du mobile et lui attribue l’identité temporaire GUTI (Globally Unique Temporary Identity) qui remplace l’identité privée IMSI (International Mobile Subscriber Identity). Le GUTI devient l’identifiant unique temporaire de l’UE. Le GUTI est composé d’un identifiant du PLMN/MME suivi d’un identifiant unique de l’UE sur le MME. A partir du GUTI, il est donc possible de retrouver le MME qui gère l’UE.

L’entité MME sélectionne l’entité SGW et à partir du point d’accès APN, l’entité MME contacte l’entité PGW. La signalisation émise par l’entité MME permet de créer une entrée supplémentaire à la table de contexte de l’entité SGW et de l’entité PGW. Cette table contient les informations concernant le tunnel par défaut (default bearer) entre le mobile UE et l’entité PGW.

Une fois le mobile UE attaché, l’entité MME contrôle l’établissement et le ré-établissement des tunnels (par défaut ou dédié) pour la transmission des données de trafic pour chaque mobile UE.

Le mobile UE contacte l’entité MME via une station de base eNB. Chaque station de base eNB est connectée à une ou plusieurs entités MME. On parle alors d’un groupe de MME (pool). Afin de gérer l’équilibrage de la charge des entités MME, chaque entité MME transmet une information de facteur de charge à la station de base eNB. L’équilibrage de charge est donc réalisé par les entités eNB en fonction des informations émises par les entités MME.

En cas de mobilité, l’entité MME gère une liste de zones de localisation allouées aux mobiles, dans lesquelles le mobile, à l’état de veille, peut se déplacer sans contacter l’entité MME pour mettre à jour sa localisation. L’entité MME constitue le point d’ancrage du plan de contrôle à condition que le mobile ne change pas de groupe. Si le mobile UE se déplace vers une station de base eNB non connectée à l’entité MME qui contient le contexte du mobile UE, alors l’entité MME source sélectionne l’entité MME cible pour lui transférer le contexte.

L’entité MME fournit les informations requises pour les interceptions légales, par exemple l’état du mobile (en veille ou connecté), sa localisation TAI si le mobile est en veille ou l’identité de la cellule ECGI (E-UTRAN Cell Global Identifier) si le mobile est en session.

1.1.3. L’entité SGW

L’entité SGW constitue le point d’ancrage du plan utilisateur pour le handover intra-système (mobilité à l’intérieur du réseau 4G) à condition que le mobile ne change pas de groupe. Dans le cas contraire, l’entité PGW assure cette fonction. Les entités SGW sont également organisées en groupes (pools) et afin d’assurer l’équilibrage de la charge des entités SGW, chaque entité eNB d’un groupe doit avoir accès à chaque entité SGW du même groupe.

L’entité SGW constitue également le point d’ancrage lors du handover inter-système en mode PS (Packet-Switched), nécessitant le transfert du trafic du mobile vers un réseau de mobiles de 2^ème ou de 3^ème génération.

L’entité SGW transfère les données entrantes provenant de l’entité PGW vers la station de base eNB et les données sortantes provenant de la station de base eNB vers l’entité PGW.

L’entité SGW informe l’entité MME pour les données entrantes lorsque le mobile est à l’état de veille, ce qui permet à l’entité MME de déclencher une procédure de notification (paging) à destination de toutes les stations de bases eNB de la zone de localisation TAI.

Lorsque l’entité SGW reçoit des données des entités eNB ou PGW, elle se réfère au contexte afin de connaitre l’identifiant de la classe de service QCI pour la mise en œuvre du mécanisme d’ordonnancement des données et pour le marquage du champ DSCP des paquets IP.

Dans le cas de l’itinérance correspondant à l’architecture Home Routed (le flux est transféré vers le PGW du réseau Home), l’entité SGW du réseau visité dérive le trafic du mobile dans le cadre des interceptions légales.

1.1.4. L’entité PGW

L’entité PGW est le routeur de passerelle assurant la connexion du réseau EPS au réseau de données PDN.

Au cours de la procédure d’attachement, l’UE se voit affecter une adresse IP (IPv4 ou IPv6) attribuée par l’entité PGW. Ainsi, en cas de l’itinérance (roaming) dans le mode HR (Home Routed), le mobile obtient une adresse IP fournie par le HPLMN et est vu comme une entité du réseau Home même si le point d’ancrage du trafic (SGW) appartient au réseau visité. Si l’adresse IPv4 attribuée est une adresse privée, l’entité PGW effectue la fonction NAPT (Network Address and Port Translation) consistant à traduire l’adresse IP et du numéro de port de TCP ou UDP du flux.

Lorsque l’entité PGW reçoit des données de l’entité SGW ou du réseau PDN, elle se réfère à l’identifiant de la classe de service QCI pour la mise en œuvre du mécanisme d’ordonnancement des données et pour le marquage DSCP des paquets IP.

L’entité PGW constitue le point d’ancrage pour la mobilité inter-SGW, lorsque le mobile change de groupe.

L’entité PGW héberge la fonction PCEF (Policy and Charging Enforcement Function) qui applique les règles relatives au trafic du mobile, concernant le filtrage des paquets, la taxation et la qualité de service à appliquer au support à construire.

L’entité PCRF (Policy Charging and Rules Function), extérieure au réseau EPS, fournit à la fonction PCEF de l’entité PGW les règles à appliquer lors de l’établissement du support.

L’entité PGW dérive le trafic du mobile dans le cadre des interceptions légales, pour les cas suivants :

le mobile est attaché sur son réseau nominal ;
le mobile est attaché sur un réseau visité, pour les deux types d’architecture, HR ou LBO (Local Breakout). Dans le cas de l’architecture LBO, le mobile UE est connecté au PGW du réseau visité alors que pour l’architecture HR, le mobile UE est connecté au PGW du réseau home.

1.1.5. L’entité HSS

L’entité HSS est une base de données assurant le stockage des données propres à chaque abonné. Les principales données stockées comprennent les identités de l’abonné, les paramètres d’authentification et le profil de service.

Lors de la souscription au réseau EPS, le mobile se voit attribuer une identité privée IMSI (International Mobile Subscriber Identity) à laquelle est associée un profil de service et une clé secrète Ki.

Lors de l’attachement, l’entité MME contacte l’entité HSS pour récupérer les valeurs d’authentification calculées au niveau du HSS à partir de la clé secrète Ki. Une fois authentifiée, l’entité HSS transmet le profil de service du mobile au MME et conserve l’adresse du MME sur lequel l’abonné (IMSI) est enregistré.

1.1.6. L’entité PCRF

Les opérateurs proposent différents abonnements pour l’accès aux services du réseau mobile. Afin de contrôler l’accès au réseau pour chaque client, il est nécessaire de contrôler l’usage du réseau et des services. L’entité PCRF permet de contrôler en temps réels l’usage du client par rapport à son abonnement et son forfait restant. Ainsi, en cas de dépassement de forfait, le PCRF va imposer une règle pour réduire le débit (fair-use). De plus, dans le cadre de la VoLTE (Voix sur LTE), l’opérateur doit mettre en place de la priorité de service.

La fonction PCC (Policy and Charging Control) définit les fonctions d’autorisation et de blocage des flux IP avec la QoS associée à chaque flux (policy) et la méthode de taxation des flux IP (charging). L’entité PCRF fournit à la fonction PCEF, intégrée dans l’entité PGW, les informations nécessaires pour le contrôle et la taxation du trafic.

Ces informations sont stockées dans la base de données SPR (Subscription Profile Repository) lors de la création de l’abonnement.

Le contrôle du trafic comprend les opérations suivantes :

l’association entre un flux de données de service SDF (Service Data Flow) et un support EPS (EPS bearer) ;
le blocage ou l’autorisation des paquets IP ;
l’attribution du paramètre QCI au support EPS.

L’entité PCEF exécute les règles fournies par l’entité PCRF, pour le contrôle des flux de trafic et la taxation. En situation d’itinérance (roaming) correspondant à l’architecture LBO, l’entité PCEF localisée dans le réseau visité demande les règles à l’entité V-PCRF (Visited-PCRF), qui les obtient de l’entité H-PCRF (Home-PCRF) du réseau nominal

La fonction PCEF peut rapporter à l’entité PCRF un changement d’état d’un flux de service comme dans le cas d’une perte de couverture radioélectrique du mobile.

L’entité PCRF peut recevoir une requête de session de la part de l’entité AF (Application Function) comme dans le cas de l’établissement d’une communication téléphonique ou visiophonique initialisée au niveau du réseau IMS (IP Multimedia Sub-system).

L’entité PCRF peut fournir à l’entité AF des informations concernant des événements se produisant dans le réseau mobile comme par exemple une perte de couverture radioélectrique du mobile.

Références

1 : Livre LTE-Advanced Pro

2: Documentation ZTE

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

Posté le 15 mai 2020 by flaunay - 4 097 vues

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 km² (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

http://www.3gpp.org/ftp//Specs/archive/28_series/28.530/28530-g10.zip

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

http://www.3gpp.org/ftp//Specs/archive/23_series/23.501/23501-g40.zip*

3GPP TS 29.510 V15.1.0 : 5G System; Network function repository services; Stage 3, Release 15

https://www.etsi.org/deliver/etsi_ts/129500_129599/129510/15.01.00_60/ts_129510v150100p.pdf

3GPP TS 29.531 V15.1.0 : 5G System; Network Slice Selection Services; Stage 3, Release 15

https://www.etsi.org/deliver/etsi_ts/129500_129599/129531/15.01.00_60/ts_129531v150100p.pdf

3GPP TS 28.500 : Management concept, architecture and requirements for mobile networks that include virtualized network functions, Release 15

https://www.etsi.org/deliver/etsi_ts/128500_128599/128500/15.00.00_60/ts_128500v150000p.pdf

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

https://www.etsi.org/deliver/etsi_tr/121900_121999/121915/15.00.00_60/tr_121915v150000p.pdf

ETSI

GS NVF 003 : https://www.etsi.org/deliver/etsi_gs/NFV/001_099/003/01.04.01_60/gs_nfv003v010401p.pdf

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