Archives mensuelles : février 2021

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

Posté le by - 8 997 vues
2

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.

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

Posté le by - 1 498 vues
Répondre

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

3.3. Configuration : Scénarios d’Agrégations (Déploiement)

3.3.1 : Agrégation de porteuses en FDD

Afin de s’adapter aux bandes de fréquences acquises par l’opérateur, les porteuses agrégées peuvent avoir des largeurs de bande différentes. Ainsi, l’agrégation de porteuses peut s’effectuer sur :

  • Des porteuses contiguës dans une bande : Classe A
  • Des porteuses non contiguës dans une bande : Classe B
  • Des porteuses sur des bandes différentes : Classe C

 

 

Figure 3.3. Différentes classes pour le CA

 

La spécification R.10 propose 6 classes différentes pour l’agrégation de porteuses, mais seules 3 d’entre elles (Classe A, Classe B et Classe C) sont définies. Chaque classe indique le nombre de CC dans la classe (CC est soit la PCC et/ou la/les SCC) et le nombre maximum de PRB gérés par l’UE dans cette classe.

Le tableau 3.2 résume les 6 configurations possibles :

Table 3.2. Configuration des UE pour l’agrégation de porteuses

A partir de cette table, lors de la procédure d’attachement l’UE informe le MME des bandes de fréquences et de la classe qu’il supporte pour le CA. Les bandes de fréquences sont numérotées selon le tableau 3.3 (liste non exhaustive) :

Table 3.3. Canaux de fréquences (extrait TS36.101 – Table 5.5.1)

Si l’UE supporte le CA intra-bande contigüe, il indique les porteuses supportées en ajoutant le lettre C, comme par exemple : CA_1C, CA_7C.

Si l’UE supporte le CA inter-bande sur 2 porteuses, il indique les porteuses supportées en ajoutant la lettre A comme par exemple : CA_1A_5A.

Si l’UE supporte le CA intra-bande non contigüe sur 2 porteuses, il indique les porteuses supportées en ajoutant la lettre A comme par exemple CA_1A_1A.

Les combinaisons possibles sont définies dans la 3GPP TS36.101 pour 2 bandes en classe A (R.10 et R.11), trois bandes en classe A et/ou classe C (R.12), 4 et 5 bandes (R.13). La liste des possibilités d’agrégation sur deux porteuses augmentent de la R.10 à la R.13.

Cela nécessite donc de nouvelles catégories de terminaux. La table 3.4 complète ainsi la table 3.1, en ne prenant en compte que le nombre de CC. D’autres paramètres tels que le nombre d’antennes pour le MIMO et la modulation sont à prendre en compte pour expliquer les débits annoncés.

Table 3.4. Nouvelles catégories de terminaux définies par la R.10

 

3.3.2 : Agrégation de porteuses en FDD-TDD

La spécification R.12 exploite les méthodes de multiplexage en fréquentielle et en temporelle. Ainsi, la PCell peut fonctionner en FDD avec l’UE et la SCell en TDD. Cela permet d’offrir la possibilité d’exploiter la bande des 3.5 GHz en TDD avec les autres bandes de l’opérateur. La 3GPP préconise l’utilisation des bandes en TDD sur une fréquence plus élevée que les porteuses en FDD

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

Posté le by - 1 765 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 by - 2 196 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 w0, laquelle se calcule à partir du vecteur u0.

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=W1W2  ou :

  • W1 est une matrice de précodage diagonale large bande permettant de définir la sélection de voies
  • W2 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 by - 2 223 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 by - 3 158 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 nR x nR., \Sigma la matrice diagonale de dimension nR x nT à coefficients \lambda_k réels positifs ou nul et  V* la matrice adjointe à V, V matrice unitaire de dimension nT x nT. 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 nR 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 s1, et s2 deux symboles à transmettre pendant une période 2.T. Au lieu de transmettre s1 sur l’antenne 1 et s2 sur l’antenne 2, on transmet :

  • Sur l’antenne 1 : s1 pendant T et -s2* pendant T ( est le complexe conjugé de  s2)
  • Sur l’antenne 2 : s2 pendant T et s1* 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 y1 et y2 ne dépendent respectivement que de s1 et s2. 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 by - 1 844 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 by - 1 788 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 1er 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 1er 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-KeNB 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 by - 1 757 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 – Chap 1 (Part 2)

Posté le by - 2 383 vues
2

L’architecture du réseau de mobiles 4G

Suite de l’article précédent

1.2. L’architecture protocolaire

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

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

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

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

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

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

1.2.1 L’interface LTE-Uu

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

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

Le protocole RLC opère dans trois modes :

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

La couche RLC effectue les opérations suivantes :

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

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

Le couche MAC assure les fonctions suivantes :

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Références

1 : Livre LTE-Advanced Pro