Livre 5G NR – Chapitre 1 Architecture Fonctionnelle

Le réseau NG-RAN : L’architecture fonctionnelle

extrait du livre : NG-RAN et 5G NR (sortie 19 octobre 2021)

L’objectif de cet ouvrage est de présenter de manière synthétique le déploiement de la 5G-NSA et de la 5G-SA.

Le chapitre 1 présente l’architecture de déploiement 5G-NSA et 5G-SA. L’ouvrage décrit les entités de l’accès radioélectrique et les fonctions du cœur de réseau 5G-SA en présentant les fonctions supportées par l’accès radioélectrique et le cœur de réseau 5GC

Extrait
1.2.1. Le réseau d’accès radioélectrique NG-RAN

Le réseau d’accès NG-RAN fournit à la fois une interface radioélectrique LTE et une interface radioélectrique 5G-NR.

Un nœud NG-RAN est :

  • une station de base 5G (gNB) qui fournit les services du plan de contrôle et la transmission des données du plan utilisateur à travers l’interface radioélectrique 5G-NR;
  • une station de base 4G évoluée (ng-eNB) fournissant des services du plan de contrôle et la transmission des données du plan utilisateur vers les mobiles via l’interface radioélectrique LTE.

Le nœud NG-RAN est responsable de la gestion des ressources radioélectriques, du contrôle de l’établissement du plan utilisateur et la gestion de la mobilité en cours de session (handover). Le mobile se connecte à l’un des nœuds radioélectriques.

Le nœud NG-RAN transfère les données de trafic provenant du mobile vers la fonction UPF, et celles provenant de la fonction UPF vers le mobile.

Lorsque le nœud NG-RAN reçoit des données de la part du mobile ou de la part de la fonction UPF, elle se réfère à l’identifiant QFI (QoS Flow Identifier) pour la mise en œuvre du mécanisme d’ordonnancement des données.

Le nœud NG-RAN peut effectuer pour les données sortantes, à destination de la fonction UPF, le marquage du champ DSCP (DiffServ Code Point) des paquets IP (Internet Protocol) en fonction de l’identifiant QFI affecté au flux.

Le nœud NG-RAN effectue la compression, le chiffrement des données de trafic et optionnellement le contrôle d’intégrité des données avec le mobile sur l’interface radioélectrique.

Le nœud NG-RAN effectue le chiffrement et le contrôle d’intégrité des données de signalisation échangées avec le mobile sur l’interface radioélectrique.

Le nœud NG-RAN effectue la sélection de la fonction AMF du cœur de réseau sur laquelle s’enregistre le mobile UE.

Le nœud NG-RAN traite la demande de paging émise par la fonction AMF pour sa diffusion dans la cellule. La cellule est une zone de couverture radioélectrique du nœud NG-RAN.

Le nœud NG-RAN diffuse également dans la cellule des informations systèmes contenant les paramètres de l’interface radioélectrique.

Afin de gérer les services d’un mobile, le nœud NG-RAN conserve un bloc d’information UE Context relatif au mobile. Les informations sauvegardées par le nœud radioélectrique dépendent de l’état du mobile. Le mobile est soit à l’état RRC connecté (RRC_CONNECTED), soit à l’état RRC inactif (RRC_INACTIVE) soit à l’état RRC de veille (RRC_IDLE).

A l’état de veille, la station de base n’a pas connaissance de la présence des mobiles qui sont à l’écoute des informations diffusées par le nœud radioélectrique. Concernant les mobiles à l’état RRC_IDLE, il n’y a pas de contexte UE au niveau du nœud radioélectrique.

Lorsque le mobile est à l’état radioélectrique connecté RRC_CONNECTED ou à l’état RRC_INACTIVE, l’identifiant radioélectrique du mobile est connu par le nœud respectivement via l’identifiant C-RNTI ou I-RNTI (Connected/Inactive Radio Network Temporary Identifier). Un bloc d’information (le contexte du mobile UE) est rattaché à l’identifiant radioélectrique RNTI. Le contexte est enregistré au niveau du nœud NG-RAN qui gère le mobile (nœud source) et il est transmis au nœud cible en cas de handover. Le contexte UE est également créé au niveau du nœud maitre et du nœud secondaire en cas de double connectivité.

Lorsqu’un mobile est en mode connecté, le nœud NG-RAN utilise les mesures effectuées par le mobile pour décider du déclenchement d’un changement de nœud en cours de session (handover), pour activer ou désactiver des cellules secondaires.

réf : https://www.amazon.fr/dp/B09BLKD3D5/ref=dp_kinw_strp_1

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

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

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

 

Court IUT – Chap 1 – Part 3

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)

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

COURS IUT Chapitre 1 (Part 1)

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

1-1. L’architecture fonctionnelle

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

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

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

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

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

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

Figure 1.2. Le réseau EPS et le backhaul

1.1.1. L’entité eNB

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

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

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

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

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

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

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

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

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

Figure 1.4. Le découpage BBU et RRU

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

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

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

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

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

Figure 1.5. REC – CPRI – RE

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

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

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

 

Figure 1.6. La BBU centralisée

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

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

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

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

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

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

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

1.1.2. L’entité MME

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

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

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

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

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

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

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

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

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

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

1.1.3. L’entité SGW

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

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

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

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

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

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

1.1.4. L’entité PGW

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

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

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

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

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

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

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

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

1.1.5. L’entité HSS

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

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

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

1.1.6. L’entité PCRF

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

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

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

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

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

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

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

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

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

 

 

Références

1 : Livre LTE-Advanced Pro

2: Documentation ZTE

 

Quand le eNb sature t’il?

Les équipementiers qui vendent l’infrastructure 4G limitent les capacités des entités en soumettant leur solution à des licences. D’un autre coté, les licences garantissent aussi le traitement d’un nombre de sessions maximum en temps réel. A titre d’exemple, les eNB ont une capacité (en terme de licence) de 512 bearers, c’est à dire que l’eNb peut ouvrir 512 connexions (bearer) garantissant le maintien de 512 sessions avec les utilisateurs en mode actif.

A ce jour le nombre de bearers que l’eNB met en oeuvre sur certains site de Nantes et aux heures de pointe atteint ce chiffre. On parle alors de saturation de l’eNb, mais nous verrons dans cet article que le déploiement de la VoLTE peut aggraver cette limitation.

Nous allons calculer le nombre d’UE pouvant avoir des accès au cours d’un TTI (Transmission Time Interval correspond à une unité de temps de 1ms pour le LTE, c’est la plus petite unité de temps pendant laquelle un user peut recevoir ou émettre des données). Sous des hypothèses simplificatrices, nous allons calculer le nombre maximum d’utilisateur pouvant, au cours d’un TTI, transmettre ou recevoir des données. Mais, le nombre d’utilisateurs actifs peut être plus élevé puisque un user peut nécessiter des ressources à un TTI mais pas au(x) TTI(s) suivant(s).

Combien d’utilisateurs maximum sont actifs par TTI sur l’eNB ?

Nous allons nous intéresser dans cet article au nombre maximum d’UE pour lesquelles l’eNb alloue des données sur un TTI. Nous aborderons dans un premier la méthode de répartition des canaux de contrôles sur la bande LTE afin de calculer le nombre d’allocation possible.

1 – Structure de la trame.

1-a) PDCCH

Les données transmises entre l’eNb et l’UE sont séquencées de manière dynamique. L’UE est informé de l’allocation de PRB en réception et de l’attribution de PRB en émission via les informations portées par le canal PDCCH. Outre l’allocation de ressource, le PDCCH informe l’UE du type de modulation et du codage utilisés (MSC) et en cas de réception multiples (MIMO), le PDCCH transporte le type de précodage (PMI).

Ainsi, le PDCCH transporte des informations de contrôle :

  • sur la voie descendante permettant d’informer l’UE de l’existence de données à recevoir dans la trame courante et des caractéristiques de modulation
  • des informations sur les ressources que l’UE utilisera sur la voie montante pour la sous-trame émise par l’UE 4 TTI plus tard.

Il est à noter que plusieurs PDCCH peuvent être transmis dans une sous-trame, soit pour transmettre des données respectivement à plusieurs UE, soit pour un seul UE. En effet, plusieurs PDCCH peuvent être transmis à un seul UE dans le cas ou le nombre d’information est conséquent, comme par exemple pour informer l’UE de l’allocation dynamique et du schéma de codage sur la voie descendante et montante, ainsi que la commande de contrôle de puissance.

Afin de spécifier le type d’information transporté par le PDCCH, l’UE décode l’information portée par le DCI (Downlink Control Information) qui stipule le type d’information transmise par le PDCCH parmi  10 formats possibles. Les 10 formats sont récapitulés dans le tableau ci-dessous :

DCI

Les formats DCI 0, DCI 3 et DCI 3A portent des informations destinées à l’UE pour la transmission sur la voie montante. En effet le format DCI 0 alloue des PRB pour l’émission du mobile vers l’eNB, et les formats DCI3/DCI 3A portent de contrôle de puissance pour la voie montante.

Le PDCCH est transmis sur un CCE (control channel elements) ou sur plusieurs CCE (on parle d’aggrégation de CCE dont les valeurs sont 2, 4 ou 8 CCE). Un CCE est composé de 9 REG – Ressource Element Group, un REG étant constitué de 4 RE. Le PDCCH est modulé en QPSK.

PDCCH_format

1-b) PCFICH

De plus, le PDCCH est obligatoirement transmis sur les premiers symboles OFDM de chaque sous-trame (De 1 à 3 symboles voir 4 symboles au maximum si le nombre de RB est faible, ce qui correspond au cas où la bande est de 1.4 MHZ). Pour savoir sur combien de symboles est transmis le PDCCH, l’eNb transmet une information complémentaire nommée CFI (Control Format Indicator) dans le canal de control PCFICH. Le PCFICH est transmis quant à lui sur le premier symbole OFDM de chaque sous trame, réparti sur toute la bande pour profiter de la diversité en fréquence. Les 4 valeurs possibles de CFI sont encodées dans un mot de 32 bits avec une forte redondance pour assurer la détection/correction au niveau de l’UE.

PCFICH_Mot

De surcroît, le canal PCFICH est modulé en QPSK pour assurer une meilleure immunité au bruit. Le CFI étant codé sur 32 bits, 16 RE sont donc nécessaires, soit 4 REG. La position des REGs est définie en fonction de l’identité de la cellule (Cell Id), laquelle est une valeur comprise entre 1 et 504.

PCFICH_REG

1-c) PHICH

Outre le PCFICH, l’eNb transmet des informations d’acquittement (ACK/NACK) sur les trames émises par l’UE. Il s’agit du canal PHICH (HARQ), dans lequel 1 bit d’information (ACK/NACK) est répété 3 fois et étalé par un code de Walsh Hadamard (code orthogonal) et modulé en BPSK.

Ainsi, un ACK a pour valeur 111 et un NACK a pour valeur 000. Le PHICH est modulé en BPSK (signal complexe situé sur le cercle trigonométrique à +pi/4 ou 5*pi/4), il faut donc 3 symboles. Le signal modulé est ensuite étalé par un code d’étalement de facteur SF=4, permettant d’obtenir 32 combinaisons complexes et d’extraire 8 codes orthogonaux (4 codes et l’équivalent déphasé de pi/2). Grace aux 8 codes orthogonaux, il est possible de transmettre 8 PHICH simultanément.

Il est donc nécessaire de réserver 12 RE pour transmettre jusqu’à au plus 8 PHICH. On parle de groupe de PHICH, codé par des codes orthogonaux.

PHICH_Code_Orthogonaux

2 – Calcul du nombre de PDCCH.

Nous allons maintenant calculer le nombre de ressources PDCCH, permettant ainsi d’obtenir le nombre d’utilisateurs simultanés sur la bande totale de l’eNB.

Il s’agit donc de calculer le nombre de ressource disponible (RE) sur les premiers symboles (1 à 3) pouvant porter le canal PDCCH. L’objectif est donc de calculer le nombre de RE disponible sur tout la bande et retrancher les canaux PFCICH, PHICH et les signaux de références (RS).

Les signaux de références (RS) sont transmis par l’eNB à chaque RB et tous les 6 RE du premier symbole si l’eNb n’a qu’une seule antenne. Si l’eNb possède au moins deux antennes, les RS sont également transmis sur 6 RE du premier symbole pour la 2ème antenne. Le RS est nécessaire afin de mesurer la distorsion apportée par le canal de propagation et de ce fait, dans le cas ou l’eNb possède deux antennes, l’eNb ne transmet aucun signal sur le RE correspondant à la position du RS de l’autre antenne.

RS_antennes

On va donc considérer qu’il y a 2 ou 4 RS par PRB.

Nous pouvons maintenant calculer le nombre de ressources PDCCH.

Rappelons que selon la bande allouée au LTE qui s’étend de 1.4 MHz  minimum à 20 MHz, le nombre de PRB noté N_PRB est le suivant :

1,4 MHz =>  6 PRBs

3  MHz   =>  15 PRBs

5  MHz   =>  25 PRBs

10  MHz  => 50 PRBs

15  MHz  => 75 PRBs

20  MHz  => 100 PRBs

Chaque PRB est composé de 12 sous porteuses, le PDCCH est transporté sur N_pcfich symboles (canal PCFICH). Le nombre total de RE sur N_pcfich symbole est donc de :

12*N_PRB*N_pcfic

Nous allons maintenant calculer le nombre de RE à soustraire :

  • Info_PCFICH=16
  • Info HARQ. On sait qu’il est possible de transmettre un groupe de 8 ACK/NACK dans un seul PCICH. Par conséquent, sur N_PRB, le nombre de groupe de PCFICH sera de E[N_PRB/8], avec E la partie entière supérieure. Enfin, le groupe de PCICH nécessite 12 RE, donc le nombre de RE sera de 12* E[N_PRB/8].
  • RS pour une antenne : 2*N_PRB
  • RS pour deux antennes ou plus : 4*N_PRB

2 – Application et cas de la VoLTE.

2-a) Calcul sur 5 MHz, 10 MHz et 20 MHz

Nous allons faire une application pratique sur 10 MHz, puis à partir des tableaux, je fournirai les résultats sur 5 MHz et 20 MHz

10 MHz =>50  PRB soit 50 *12 RE =600 dans le premier symbole. Si le nombre de symbole utilisé par le PDCCH monte à 3, alors il y a aura 1800 RE pouvant transporter les PDCCH

On retire :

  • 16 RE pour le PCFICH
  • 12* E[50/8] = 12*7=84 RE pour le PCICH
  • 100 RE pour les RS si une antenne et 200 RE pour deux antennes

Soit un total de 200 RE ou 300 RE pour deux antennes.

Pour rappel,  le PDCCH nécessite au moins un CCE (mais peut nécessiter 2 CCE, 4CCE ou 8CCE). Un CCE est composé de 36 RE et le PDCCH est positionné sur N_pcfich symboles (canal PCFICH). Pour finir, étudions les 3 cas possibles

  1. N_pcfich=1 => 600 RE, moins 100 RE pour une antenne et 200 pour 2 antennes. Il reste donc 400 ou 300 RE. Dans le cas ou il y a 2 antennes, 300/36=8.33 soit 8 PDCCH donc 8 utilisateurs simultanés
  2. N_pcfich=2 => 1200 RE, moins 100 RE pour une antenne et 200 pour 2 antennes. Il reste donc 1000 ou 900 RE. Dans le cas ou il y a 2 antennes, 900/36=25 soit 25 utilisateurs simultanés
  3. N_pcfich=3 => 1800 RE, moins 100 RE pour une antenne et 200 pour 2 antennes. Il reste donc 1600 ou 1500 RE. Dans le cas ou il y a 2 antennes, 1500/36=41.66 soit 41 utilisateurs simultanés

Voilà une synthèse pour 3 bandes LTE différentes et deux antennes :

Nbre_PDCCH_5MHZ

Nbre_PDCCH_10MHZ

Nbre_PDCCH_20MHZ

NB : L’UE détecte le PDCCH en fonction de son identifiant RNTI – Radio Network Temporary Identifier :

  • P-RNTI si le mobile est en veille. Il écoute le canal PDCCH pour être informé d’un Paging
  • C-RNTI en mode connecté ou SPS-C-RNTI quand il reçoit des informations périodiquement (par exemple de la VoIP reçue toutes les 20 ms)

Le RNTI est codé sur 16 bits et réalise un ET logique avec le code CRC du canal PDCCH.

2-b) Impact de la VoLTE

Les eNb sont limités à 512 bearers actifs, quel sera l’impact de la VoLTE?

Nous supposons une bande de 10 MHz, si le PDCCH est codé sur 3 symboles (hypothèse de 2 antennes), le nombre maximum d’utilisateur sur une bande de 10 MHz est donc de 41 utilisateurs par TTI.

Or, la VoLTE nécessite la transmission d’information que tous les 20 TTI, donc en supposant que des utilisateurs en VoLTE, le nombre de sessions actives est de :

41 * 20 = 820 utilisateurs.

Par contre dans le cas ou la bande n’est que de 5 MHz, le nombre d’utilisateurs actifs sera limité à 400, en dessous du seuil des 512 licences.

EMM Procédure – Initial Attach (Part 2)

Dans un précédent article, j’avais présenté de manière générale la procédure d’attachement au réseau LTE. Je vous invite à relire l’article EMM Procédure – Initial Attach.

Cet article est inspiré du site www.netmanias.com

I) Principe et objectifs.

Ia) Les objectifs

En mettant le téléphone sous tension, ce dernier cherche le réseau 4G en priorité, et lorsqu’il trouve une station de base (eNb), l’UE lance une procédure d’enregistrement. Cette procédure d’enregistrement se nomme Initial ATTACH ce qui permet  d’Identifier et authentifier l’UE au niveau du réseau (cf. call flow simplifié de l’article EMM Procédure – Initial Attach)

L’objectif de cet article est donc de détailler le call flow suivant (présenté dans l’article EMM Procedure  – Initial Attach)

EMM call flow

En fait, il y a plusieurs cas d’enregistrement, nous allons aujourd’hui en lister que 3 et ne détailler que le premier cas.

  1. L’UE se connecte pour la première fois au réseau 4G, dans ce cas l’UE envoie son IMSI
  2. L’UE se reconnecte après une perte de couverture en restant sur le même MME
  3. L’UE se reconnecte en ayant changé de MME

Dans les deux derniers cas, l’UE envoie l’identifiant GUTI. Se référer à l’article IMSI, TMSI, GUMMEI, GUTI comme le montre la figure suivante :

Figure 2. Initial Attach Cases by Unknown UE

(NB : Pour être plus précis, il faut aussi différencier le cas ou le MME connait l’UE car son contexte a été sauvegardé du cas ou le MME ne reconnait pas l’UE car son contexte a été supprimé au niveau du MME).

Afin d’analyser le call flow de demande d’enregistrement, il est nécessaire d’avoir en tête les interfaces et les protocoles entre l’UE et le MME. Nous allons également exploiter dans cet articles les notions vues dans l’article protocole RRC

lte_control_plane_RRC

Ib) Généralité sur la procédure d’enregistrement

L’attachement d’un UE se déroule en 5 phases :

  1. UE ID Acquisition : L’UE s’identifie auprès du réseau en communiquant son identifiant IMSI (ou GUTI)
  2. Authentication : Authentification mutuelle par la méthode EPS-AKA
  3. NAS Security Setup : Chiffrement des données
  4. Localisation Update : Le MME informe le HSS qu’il gère l’UE et récupère les services auquel l’UE a souscrit.
  5. EPS Session Establishment : Création du Bearer par défaut

Figure 1. Summary of Initial Attach Procedures

II) Description des étapes

II-1)  UE ID Acquisition

L’UE ID acquisition a pour objectif de fournir l’identité de l’UE au réseau (MME). Mais, cette première phase se découpe elle aussi en plusieurs étapes :

  1. Synchronisation et recherche de cellule.
  2. Etablissement d’une connexion ECM

Etape 1 : Synchronisation et recherche de cellule.

Dans un premier temps, lorsque le téléphone s’allume, sa première démarche consiste à chercher le réseau pour se synchroniser et trouver les informations sur les eNb. Pour rappel (cf article Etat RRC – ECM – EMM), l’U est dans les états suivants :

  • EMM Deregistered
  • ECM Idle
  • RRC Idle

Etape 2 : Etablissement d’une connexion ECM

L’établissement de la connexion ECM a pour objectif de transmettre l’IMSI de l’UE au MME .Cela nécessite la encore plusieurs sous-étapes :

  • Synchroniser en temps et en fréquence l’eNb et l’UE pour échanger des données (TTI et PRB) nommé RRC Connection Establishment
  • Transmettre les données – Attach Request – jusqu’au MME

2a) Une première connexion RRC est nécessaire pour passer du mode RRC-Idle au mode RRC-Connected. L’UE doit impérativement passer en mode RRC Connected pour pouvoir transférer des données ou transmettre de la signalisation (Les messages NAS sont transférés comme  RRC).

Une fois l’UE en mode RRC Connected, il peut envoyer les informations NAS (requête d’attachement) et passer en mode ECM-Connected.

Figure 2. Procedure for IMSI Acquisition

2-a) RRC Connection Establishment

La connexion RRC permet d’établir un bearer radio pour la signalisation (SRB0/SRB1) et s’effectue en 3 étapes.

RRC_establishment

2-a.1) [UE → eNB] RRC Connection Request

La requête RRC Connection Request (Establishment Cause=“Mobile Originating Signaling) est transmis de l’UE vers l’eNB sur un canal aléatoire . La raison “Mobile Originating Signaling” est transmis par l’UE lorsque l’UE va faire une des demande suivante : Attach, Detach ou TAU (Tracking Area Update).

2-a.2)  [UE ← eNB] RRC Connection Setup

Le eNb contrôle les liens radios Upling et Downlink de l’UE, en lui allouant un SRB1 qui correspond au lien radio dédié à l’UE. Il porte connaissance à l’UE du lien radio dédié en envoyant cette inforamtion dans le message  RRC Connection Setup, lequel est délivré sur le SRB 0 et le CCCH..

2-a.3)  [UE → eNB] RRC Connection Setup Complete

L’UE acquitte l’eNb par le message RRC Connection Setup Complete via le lien radio dédié SRB 1 et le canal logique DCCH (Dedicated Control Channel). Pour plus d’efficacité, le message  Attach Request est transmis au eNB dans le message RRC Connection Setup Complete.

A partir de l’acquittement, l’UE est dans l’état RRC-Connected

2-b)  La requête d’attachement

L’UE envoie le message EMM – ATTACH REQUEST dans le message RRC.

2-b.1) S1 Signaling Connection Establishment

Les messages de contrôle entre l’eNb et le MME sont transmis sur l’interface S1-MME via le protocole S1AP. La connexion S1 est dédiée pour chaque utilisateur et est identifiée par la paire  (eNB UE S1AP ID, MME UE S1AP ID) allouée par l’enB et le MME, permettant à chaque entité d’identifier l’UE.

A ce stade du call flow, l’eNb a reçu de la part de l’UE une requête ATTACH-REQUEST. L’eNB va définir un identifiaint eNb UE S1AP IE pour l’établissement de la connexion S1 et envoie la requête ATTACH REQUEST au MME* avec le contenu suivant :

Initial UE message

 

La question qui se pose maintenant est la suivante : Comment l’eNb connait l’adresse du MME qui prend en charge la requête. Deux premiers cas se posent :

  • Si l’eNb n’est connecté qu’à un seul MME, il peut alors transmettre la requête d’attachement
  • Si l’eNb est raccordé à un Pool de MME (cf article précédent), et si l’UE n’a pas d’identifiant GUTI (car dans ce cas, il connait l’adresse du MME sur lequel il était précédemment connecté) alors l’eNB sélectionne le MME en fonction de sa charge. Périodiquement, les MME envoient un rapport de charge à l’eNb (weight factor).

2-c)  ECM Connection Establishment

A la réception de ce message, le MME allou l’identifiant MME S1AP UE ID pour identifier l’UE ce qui permet de finaliser la connexion entre l’eNb et le MME. Les états de l’UE sont maintenant les suivants :

  • EMM-Registered
  • ECM-Connected
  • RRC-Connected.

2-d) IMSI Acquisition 

A partir des informations contenues dans le champs Network Capability du message ATTACH REQUEST, le MME connait les algorithmes de sécurités supportés par l’UE et son IMSI.

Le MME va maintenant procédér à une authentification de l’UE et va permettre à l’UE d’authentifier le réseau EPS selon la procédure EPS-AKA (Authentication and Key Agreement).

II.2 Authentication

L’authentification est dite mutuelle car le réseau authentifie l’UE et l’UE authentifie l’EPS. La procédure se découpe en deux étapes :

  1. Acquisition des vecteurs d’authentification : Le MME récupère les vecteurs d’authentification au niveau du HSS (AuC faisant parti du HSS)
  2. Vérification des paramètres d’authentifications

Le Call Flow sur l’authentification est représentée sur la figure suivante :

Figure 3. Procedure for Authentication

1) Acquisition du vecteur d’authentification

A travers l’interface S6a, Le MME contacte le HSS via le protocole DIAMETER pour récupérer le vecteur d’authentification AV composé des éléments suivants :

  • RAND : Un nombre aléatoire
  • AUTN : Le sceau d’authentification appelé aussi jeton d’authentification. utilisé par l’application USIM pour authenfier l’EPS
  • XRES : Le résultat de l’authentification de l’UE selon la clé connue par le HSS (laquelle est aussi enregistrée sur l’UICC). XRES est le résultat calculé au niveau du réseau à partir du RAND et des paramètres connues de l’UE.
  • KASME: La clé de cryptage et de chiffrement (nommée Ki et Kc). A la différence du réseau 3G, seule Kasme est transmis permettant de dériver les clés Ki et Kc.

La récupération du vecteur d’acquisition s’effectue en trois étapes :

  1. Requête de la part du MME vers le HSS
  2. Calcule de l’AV au niveau du HSS
  3. Transmission de l’AV du HSS au MME

1-a) Demande du vecteur AV [1]

Le MME demande les vecteurs d’authentifications à chaque message ATTACH_REQUEST.

Dans sa requête, le MME envoie l’identité du mobile (IMSI) et l’identité SN ID composé du MCC et du  MNC du MME faisant la demande afin que l’opérateur HOME puisse connaitre quel opérateur fait la demande d’authentification de son client.

1-b) Génération du vecteur d’authentification AV [2]

Le HSS (en 3G il s’agissait du HLR/AuC) calcule le vecteur d’authentification AV en utilisant la clé LTE K à partir de la connaissance de l’IMSI et de l’identité SN ID.

Dans un premier temps, le HSS génère un numéro de séquence SQN incrémenté à chaque routine et un numéro aléatoire RAND, et l’algorithme de crypto utilisé ces deux paramètres et la clé privé LTE K pour générer le résultat attendu d’authentification de l’UE (XRES), et les clés de chiffrement Kc et d’intégrité Ki.

(XRESAUTN, CK, IK) = Crypto Function (LTE K, SQN, RAND)

Les valeurs  {SQN, SN ID, CK, IK} permettent de créer la clé de dérivation KASME

KASME = KDF (SQN, SN ID, CK, IK)

Figure 4. Generating Authentication Vectors

1-c) [MME ← HSS] Delivering Authentication Vectors [3]

Le HSS transmet le vectueur d’authentification AV :  Authentication Information Response au MME.

2) Authentification mutuelle

La procédure EPS-AKA est un accord mutuel d’authentification.Lorsque le MME reçoit le paramètre d’authentification AV il ne transmet que les éléments nécessaire permettant à l’UE d’authentifier le réseau (AUTN : Sceau ou jeton d’authentification) et la variable aléatoire RAND permettant à l’UE de calculer son sceau (ou jeton) d’authentification XRES.

Le MME conserve les valeurs XRES et KASME pour authentifier l’utilisateur et connaître les clés de chiffrements et d’intégrité. KASME n’est pas transmis à l’UE car ce dernier va le calculer. L’UE a néanmoins besoin de connaitre l’index KSIASME correspondant à la valeur SQN pour calculer les clés Ck et le Ci :

2-a) [UE ← MME] Request by MME for User Authentication [2]

Le MME transmet les informations  (RAND, AUTN et KSIASME) nécessaire à l’UE dans le message Authentication Request (RAND, AUTN, KSIASME).

2-b) [UE] User’s Authenticating the Network: Generating Authentication Vectors and Authenticating the Network [5]

A partir du message Authentication Request (RAND, AUTN, KSIASME), l’UE génère d’abord la valeur SQN à partir de l’AUTN,et calcule à partir de son LTE K et du SQN la valeur AUTNUE. L’UE compare ainsi la valeur AUTNUE calculée au niveau de l’USIM de la valeur AUTN envoyé par le réseau. Si les deux valeurs sont identiques, l’UE authentifie le réseau et sauvegarde la clé s KSIASME comme un index pour calculer KASME.

2-c) [UE → MME] Delivery of User RES to MME [6]

L’UE calcule ensuite les clés de chiffrement et d’intégrité et à partir de la valeur RAND, il calcule son sceau (jeton) d’authentification nommée RES (Authentication Response). Cette valeur est transmise au MME

2-d) [MME] Network’s Authenticating the UE [7]

Le MME compare le RES reçu du XRES émis par le HSS et sauvegardé au niveau de l’UE. Si les 2 valeurs correspondent, l’UE est authentifié au niveau du réseau.

D’une manière plus complète, la procédure est la suivante, nous détaillerons cette procédure EPS-AKA dans un autre article.

Authentification_4G


II-3) NAS Security Setup

A partir de l’authentification mutuelle, l’UE et le MME pourront échanger des données de signalisation. Celles-ci sont transmises dans un tunnel crypté. L’UE et le MME échange donc les algorithmes de chiffrement et d’intégrité en 4 étapes

Figure 5. Procedure for NAS Security Setup

3-a) [MME] Generating NAS Security Keys [1]

Le MME choisi l’algorithme de chiffremetne t d’intégrité qui sera appliqué à l’échange de message NAS (nous sommes toujours dans le cas de la requête ATTACH). A partir de cet algorithme et de la valeur KASME, le MME calcule la clé d’intégrité NAS integrity key (KNASint) et la clé de chiffrement (KNASenc). Ces deux clés sont appliquées au message NAS.

3-b) [UE ← MME] Security Mode Commande [2]

Le MME informe l’UE du choix de l’algorithme dans le message Security Mode Command (KSIASME, Security Algorithm, NAS-MAC) ce qui permet à l’UE de générer les clés duales.

3-c) [UE] Generating NAS Security Keys [3]

L’UE génère les clés d’intégrité et de sécurité (KNASint and KNASenc) en fonction de l’algorithme choisi par le MME.

3-d) [UE → MME] Security Mode Complete [4]

L’UE informe le MME de la génération des clés de sécurités NAS via le message Security Mode Complete (NAS-MAC).

II.4 Location Update

Le MME peut maintenant enregistrer l’utilisateur au niveau du réseau, le localiser et récupérer les services de souscriptions du client. Le MME informe le HSS qu’il gère l’UE et qu’il est enregistré au niveau du MME. Cela est réalisé au cours de la procédure de LU (Location Update Procedure), les échanges s’effectuent en utilisant le protocole DIAMETER sur l’interface S6a.

Figure 6. Procedure for Location Update

 4-a) [MME → HSS] Update Location Request  [1]

Le MME envoie la requête Update Location Request (IMSI, MME ID) vers le HSS afin de lui notifier la prise en charge de l’UE (authentifié) et pour réclamer la récupération du profil d’abonnement du client.

4-b) [HSS] Register [2]

Le HSS enregistre l’identifiant du MME afin de savoir sur quel MME gère le client en cas de terminaison de session (MT Mobile Terminated) pour ce client.

 4-c) [MME ← HSS] Update Location Answer [3]

Le HSS envoie le profilde souscription cu client au MME encapsulé dans le message Update Location Answer. A partir de cette confrmation, le MMEpeut créer une session EPS session et un bearer EPS par défaut. Le message de Update Location contient le paramètre de QoS et l’APN avec les informations sur les débits maximums autorisés pour le client

4-d) [MME] Storing Subscription Information [4]

Le MME sauvegarde les informations contenues dans le Update Location Answer dans un contexte pour l’UE.

II.5 EPS Session Establishment

A partir des informations de souscription de l’UE (QoS), le MME va créer la session et le bearer EPS par défauten satisfaisant le critère de QoS

Figure 7. Procedure for EPS Session Establishment (1)

5-a) [MME] Assigning EPS Bearer ID [1]

Un bearer EPS bearer est une connexion virtuelle entre l’UE et le P-GW permettant de délivrer le trafic utilisateur. Un EPS bearer est identifié par 4 bits nommé EPS bearer IDs dont les valeurs sont définies par le tableau suivant :

Table 2. EPS Bearer ID value assignment range

Le MME va donc attribuée une valeur EPS Bearer ID comprise entre 5 et 15.

5-b) [MME] Selecting P-GW [2]

Le MME interroge le serveur DNS pour connaitre le PDN associé à l’identifiant reçu par le HSS (ex : internet.apn.epc.mnc01.mcc208.monfai.fr) ou directement à partir de l’information P-GW ID si disponible.Le MME choisi également le SGW qui transfera les données utilisateurs au PGW

5-c) [MME → S-GW] Create Session Request [3]

Le MME demande la création de session de données auprès du SGW via le message Create Session Request (interface S11).

Le SGW contacte ensuite le PGW afin que ce dernier valide l’établissement du contexte EPS. Comme on le verra dans le 7ème point (5-g), le PGW peut aussi modifier la QoS associé au débit sur cet APN en imposant une valeur pour l’AMBR. En effet, dans sa requête au SGW, le MME inclue les informations de souscriptions reçues par le HSS permettant ainsi au P-GW d’interroger le PCRF pour les attributs de la session EPS et vérifier la concordance entre la demande et la souscription (facturation).

Voici le détail des informations transmises au cours de la requête Create Session Request :

5-d) [MME → P-GW] Create Session Request  [4]

Le S-GW transfère la requête vers le P-GW sur l’interface S5 via le protocol GTP (UP: GTP-U, CP: GTP-C). Le S-GW alloue un identifiant de tunnel DL S5 TEID (S5 S-GW TEID) au niveau du SGW. 

5-e) [S5 Bearer: Downlink] [5]

A la réception du message au niveau du PGW, ce dernier doit créer un identifiant de tunnel permettant ainsi de définir de bout en bout le bearer S5. Mais avant cela, il faut vérifier le droit d’accéder au réseau.

5-f) [P-GW] Allocating User IP Address [6]

Le P-GW invoque le serveur DHCP afin de fournir une adresse IP à l’UE pour le routage des données avec l’APN

5-g) [P-GW → PCRF] Notifying of EPS Session Setup [7]

Le P-GW et le  PCRF communique à travers l’interface Gx et utilisant le protocole Diameter pour valider si le service demandé par le client fait parti de l’offre de souscription du client. Le PCRF est en charge de contrôler les accès autorisés et le cas échéant d’appliquer les règles de QoS souscrites. Le P-GW envoie la requête DIAMETER CCR (CC-Request) : 


5-h) [PCRF → SPR] Requesting Access Profiles [8]

Le PCRF interroge le SPR pour connaître le profil d’accès du client et déterminer les règles de PCC à mettre en oeuvre.

5-i) [PCRF ← SPR] Returning Access Profiles  [9]

Le SPR renvoi le profil d’accès de l’utilisateur. Le profil peut contenir des informations sur les filtres de sessions de flux de données (SDF Filter) et les paramètres QCI, ARP, APN-AMBR (UL/DL), les méthodes de taxation (e.g. Offline), …

5-j) [PCRF] Determining Policies [10]

Le PCRF détermine la politique  PCC  à appliquer à la session EPS.

5-k) [P-GW ← PCRF] Acknowledging EPS Session Establishment [11]

Le PCRF founit les règles PCC au P-GW, dans sa réponse DIAMETER CCA (CC-Answer).

5-l) [P-GW] Policy Enforcement [12]

Le P-GW applique les règles PCC (le P-GW joue le rôle du PCEF) reçues par le PCRF. Comme les règles PCC sont définies pour chaque flux de sessions de données SDF, le P-GW fait un mapping entre le SDFs et le bearer EPS créée.

◇ 13) ~ 15) EPS Session Creation Response

Du 13ème au 15ème message, le P-GW informe le MME de son choix de QoS appliquée à la session EPS dans le message Create Session Response. Le PCRF peut avoir décidé de conserver la valeur de QoS demandé par le MME ou proposé une autre valeur.

5-m) [S-GW ← P-GW] EPS Session Creation Response [13]

Le P-GW alloue un identifiant S5 TEID (S5 P-GW TEID) pour établir le tunnel GTP sur l’interface S5 avec le  S-GW. Dans la réponse Create Session Response, le P-GW indique l’identifiant du tunnek P-GW TEID et la QoS à appliquer au bearer S5 (et par conséquent au bearer EPS par défaut).


5-n) [S5 Bearer: Uplink] S5 Bearer Established  [14]

La réponse est ensuite transmise au S-GW permettant ainsi de cérer le tunnel de bearer S5 via le protocole GTP-U .

5-o) [MME ← S-GW] EPS Session Creation Response [15]

Le SGW transfère ensuite le Create Session Response au MME en allouant un identifiant S1 TEID (S1 S-GW TEID) pour créer le tunnel S1 GTP associé au bearer S1 entre l’eNb et le SGW.

16) [MME] Le MME Conserve dans son contexte l’identifiant S5 P-GW TEID

Quand l’UE sera attaché au réseau, en cas de Handover vers un autre S-GW il faut construire le tunnel entre le nouveau SGW et le P-GW, point d’ancrage au PDN. Pour cette raison, le MME doit conserver l’identifant S5 P-GW TEID²²

5-p) [MME] Calcule le UE-AMBR [18]

Le MME envoie à l’UE le message  Attach Accept en réponse à la demande de l’UE  Attach Request.  Le MME prépare le support E-RAB (i.e. en allouant des ressources sur le lien radio et en créant le bearer S1). Pour cela, le MME calcule la valeur UE-AMBR qu’il va transmettre au eNB. Cela permet d’ajuster la valeur reçue du HSS avec la valeur réellement utilisée sur le default bearer..

Figure 8. Procedure for EPS Session Establishment (2)

19) Génération de paramètres pour l’E-RAB et le NAS Signaling

A la réception de la réponse du P-GW Create Session Response le MME est informé des ressources à mettre en oeuvre pour l’UE. Le MME à la charge de garantir la même QoS entre le S-GW et l’UE en construisant les bearer DATA et S1. La mise en place de l’E-RAB nécessite de la part du MME les informations suivantes :

  • Identitifcation de l’UE par la variable GUTI au lieu de l’IMSI
  • Détermination des paramètres pour définir la liste de TAI (TAI list allocation, TAU Timer value)
  • Calcul de l’UE-AMBR pour l’eNb
  • Définition d’un E-RAB ID

5-q) [UE ← MME] Attach Accept [20]

Les informations précédentes, l’adresse IP de l’UE, l’identification du bearer EPS (EPS Bearer ID), le débit maximum UE-AMBR et les paramètres de QoS reçus dans le message  Attach Accept de la part du S-GW est transféré jusqu’à l’UE permettant ainsi d’aboutir à la réponse de l’UE sur sa demande Attach Request .

Le message ATTACH REQUEST est encapsulé dans le message Initial Context Setup Request du protocole S1-AP et ensuite sur le lien radio via le protocole RRC  RRC Connection Reconfiguration.

[MME]  AS Security Setup : Creating KeNB  [21]

Les échanges sur la couche radio sont chiffrées selon la clé KeNB transmise par le MME à l’eNb sur la base du KASME. This is to ensure the eNB can generate AS security keys to be used for secured communication between the eNB and the UE over radio link (i.e. for AS security setup).

5-r) [eNB ← MME] Requesting E-RAB Setup [22]

Le MME commence par établir le bearer S1 via le message Initial Context Setup Request. Ce message permet de constuire le S1 bearer entre l’eNb et le S-GW, mais aussi le DRB avec kl’UE. Le message Initial Context Setup Request contient les informations suivantes :

5-s) [S1 Bearer: Uplink] [23]

A partir du message Initial Context Setup Request reçu de la part du MME, l’eNb peut construire le tunnel (identifiant TEID) et mettre en place le support E-RAB. Pour cela il envoi le message Attach Accept à l’UE et termine la mise en place du S1 bearer en incluant l’identifiant S1 TEID dans le message Initial Context Setup Response pour répondre au précédent message du MME. Le MME transfère ainsi le message vers le S-GW pour que ce dernier puisse connaitre le S1-TEID

5-t) [eNB] Generating AS Security Keys [24]

L’eNB choisit l’algorithme de chiffrement et d’intégrité à partir de la clé  KeNB afin d’assurer la confidentialité et l’intégrité des messages RRC A partir de KeNB, leNb calcule les clés KRRCint/KRRCenc,

5-u) [UE ← eNB] Helping UE to Generate AS Security Keys [25]

L’eNB informe l’UE du choix des algorithmes via la commande Security Mode Command (AS Security Algorithm, MAC-I).

5-v) [UE] Generating AS Security Keys [26]

A la réception du message Security Mode Command, l’UE génère les clés de sécurité AS  (KRRCint, KRRCenc et KUPenc)

5-w) [UE → eNB] AS Keys Generation Complete [27]

Le message  Security Mode Command permet de vérifier le chiffrement A partir de ce moment, l’ eNB établi le lien DRB sécurisé.

28) ~ 29) DRB Establishment

5-x) [UE ← eNB] Reconfiguring RRC Connection [28]

L’eNB alloue une identité DRB Id, et configure les paramètres de QoS pour pouvoir finaliser l’établissement du lien DRB. Pour ce faire, il transmet le message RRC Connection Reconfiguration à l’UE  via le connexion RRC sécurisée. Ce message RRC a pour but d’allouer les ressources radios comme cela a été négocié avec le P-GW. L’eNb transmet également dans le corps du message l’adresse IP de l’UE.

Enfin, le message  RRC Connection Reconfiguration encapsule la réponse Attach Accept

 [DRB Establishment: Uplink and Downlink] DRB Establishment Complete [29]

L’UE peut maintenant émettre et recevoir de la Data avec l’eNb

5_y) [eNB → S-GW] E-RAB Setup Response [30]

Le lien se construit entre l’eNb et le SGW. Pour ce faire, l’eNb transmet son identifiant de tynnel S1 TEID (S1 eNB TEID) pour la construction du bearer S1 et en informe le MME via le message Initial Context Setup Response, ce qui permet de répondre à la requête  Initial Context Setup Request

[eNB] Allocating a Downlink TEID for S1 Bearer [31]

Le S1 bearer, est ainsi établi via le protocole S1 GTP-U tunnel. Le S-GW attend la confirmation de la connexion de l’UE, ce dernier doit confirmer son attachement auprès du MME

5-z) [UE → MME] Sending Attach Complete Message [32]

L’UE envoi le message Attach Complete au MME, en réponse au message [20]

 [UE][MME] EMM State [33]

L’UE et le MME sont dans l’état EMM-Registered. SI le MME envoi le message Attach Reject (cela se ferai à l’étape 20) dans ce cas l’UE libère sa connexion eECM/RRC et se retrouverait dans l’état EMM-Deregistered.

5-aa) [MME → S-GW] Requesting S1 Bearer Modification [34]

Le MME transmet l’identifiant S1 TEID (S1 eNB TEID) reçu de la part de l’eNB vers le S-GW via e message Modify Bearer Request message.

5-ab) [MME ← S-GW] Responding to S1 Bearer Modification Request [35]

Le S-GW envoit un acquittement au MME ‘Modify Bearer Response’ indiquant que le S-GW est prêt pour délivrer le flux de données

5-ac) [S1 Bearer: Downlink] S1 Bearer Setup Complete [36]

La procédure de mise en place du bearer S1 est finie, l’eNb et le S-GW peuvent échanger des données sur el S1 bearer

Protocole RRC

Hérité de la 3G, le protocole RRC permet à l’UE et à l'(e)Nb d’échanger de la signalisation (messages RRC).

Au cours de l’article Protocoles NAS et Protocoles AS, je vous avais présenté le concept d’accès au réseau (NAS et AS). Dans cet article, j’avais présenté le  NAS (Non Access Stratum). Comme son nom l’indique les fonctionnalités du NAS sont indépendantes de la couches d’accès, donc de l’accès radio et par conséquent le NAS permet l’échange d’information de signalisation entre l’UE et le MME.

Le NAS a pour rôle de permettre :

  • l’enregistrement de l’UE au réseau
  • l’authentification de l’UE
  • la mise à jour de la localisation
  • la gestion des appels.

Cf. article  Protocoles NAS et Protocoles AS « La couche NAS a deux rôles essentiels (figure 2): »

  • Gestion des sessions (et des appels pour la 3G)
  • Gestion de la mobilité.

En fait, les protocoles EMM, ECM et ESM sont des protocoles de signalisation de la couche NAS, cela concerne l’UE et le MME.

lte_control_plane_RRC

L’AS regroupe les protocoles de signalisation propre au réseau d’accès (Access Stratum) c’est à dire entre l’UE-eNb et eNb-MME, eNb-SGW pour la 4G.

L’AS est transporté par les messages RRC sur l’interface LTE-Uu. Même si le NAS est indépendant de la couche d’accès, il est néanmoins transporté par la couche radio dans le cadre du LTE. Ainsi, le NAS est transporté par le protocole RRC (interface LTE-Uu) et le protocole S1-AP (interface SA-MME).

lte_protocol_layers

A titre d’exemple, pour l’EMM les messages ATTACH/DETACH REQUEST, TAU sont encapsulés dans le message RRC Connection Setup Complete, tout comme le SERVICE REQUEST de l’ECM (se référer à al’article correspondant : ECM – EPS Connection Management)

Pour la 3G, il faut rajouter le RNC comme le montre la figure ci-dessous

asnas3G

Le protocole RRC a pour but est de transférer les informations de signalisation entre l’UE et la station de base, nous allons pouvoir maintenant étudier les messages d’accès au réseau et de gestion d’appels, ainsi que les call flow dans les articles à venir.

Commentaires : Bien différencier les protocoles et les interfaces. L’interface S1-MME et le protocole S1-AP.

ECM – EPS Connection Management

La connexion ECM (EPS Connection Management) a pour but de mettre en oeuvre des ressources physique (SRB – Signaling Radio Bearer) et des ressources réseaux (S1 bearer) entre l’UE et le MME : La ressource physique génère des supports radios entre l’UE et l’eNb alors que les ressources réseaux génèrent des supports (bearer) entre l’eNb et le MME. Cela permet donc de créer une connexion entre l’UE et le MME (connexion NAS) comme le rappelle la figure ci-dessous (extrait article)

asnas4G

Les procédures de gestion de connexions sont réalisés lors des procédures suivantes :

  • Procédure d’accès aléatoire
  • Procédure d’enregistrement LTE
  • Procédure d’établissement de connexion pour le plan usage
  • Procédure de libération de connexion

L’état de l’ECM permet aussi de déterminer si l’UE est localisé à l’eNb près ou sur un zone nommée Tracking Area. Pour cela, l’ECM décrit l’existence ou non d’une connexion NAS, c’est à dire une connexion entre l’UE et l’EMM selon l’un des deux états suivants :

  • ECM-Idle
  • ECM-Connected.

I) Les états ECM

ECM_idle : L’UE est dans l’état ECM_idle lorsqu’aucune connexion de signalisation NAS existent entre l’UE et le MME, c’est à dire pas de connexion sur l’interface S1_MME. Dans l’état ECM_idle, l’UE est localisé sur une Tracking Area.

Lorsque l’UE est dans l’état ECM_idle, sa mobilité est gouvernée par  la procédure de sélection/resélection de cellules comme indiquée dans la norme 3GPP TS36.304. Dans ce cas, l’UE peut toujours être enregistré et localisé au niveau du MME (donc l’UE est EMM_ENREGISTERED) mais la connexion de signalisation est perdue (ECM_idle).

ECM_Connected : Dans cet état, une connexion NAS est établie entre l’UE et le MME. L’UE est localisé au niveau de l’eNb.

Ainsi, quand l’UE doit transmettre des paquets, l’UE envoie au MME un Service Request pour passer dans l’état ECM_Connected.

II) Les états ECM et EMM

A priori les états ECM et EMM sont indépendants l’un de l’autre, par exemple la transition de l’état EMM-REGISTERED vers EMM-DEREGISTERED peut se réaliser quelque soit l’état ECM de l’UE ou du MME. Cela signifie que l’UE peut faire une demande de détachement dans le mode ECM_idle ou ECM_Connected.

Lorsque l’UE libère la signalisation, ce dernier va dans l’état ECM_idle, mais il reste dans l’état EMM_REGISTERED.

Cependant, certaines transitions nécessitent un état particulier de l’ECM. A titre d’exemple, la transition EMM-Deregistered vers l’EMM-registered se réalise soit pendant la demande d’enregistrement (LTE Attach) soit au cours de la procédure TAU. Dans ce cas, l’UE passe simultanément dans l’état ECM-Connected State..

En combinant maintenant l’état EMM de l’UE, on peut différencier trois premiers cas  :

  • EMM-REGISTERED et ECM_idle

L’UE est localisé dans un zone TA, l’UE étant enregistré possède l’identifiant S-TMSI mais n’a plus de connexion avec le réseau, dans ce cas, l’UE

1 – Peut réaliser une mise à jour de sa localisation.

1-1) Le TAU est déclenché lorsque le TA mesuré par le téléphone est différent du précédent TA ou déclenché périodiquement à la fin du timer T3412.

 1-2) Cela permet de maintenir l’enregistrement de l’UE et d’être toujours localisé par l’EPC (notamment en cas de paging). L’UE envoie ainsi une notification à l’EPC pour l’informer de sa présence.

2 – Est à l’écoute de Paging

  • EMM-DEREGISTERED et ECM_idle

L’UE n’est pas localisé par le réseau, et doit s’attacher avec l’identifiant IMSI.

  • EMM-REGISTERED et ECM_Connected

L’UE est localisé à la cellule près, il y a des échanges de signalisation entre l’UE et le MME et des échanges de données entre l’UE et le SGW.

Sur la figure suivante, on présente les états de transitions entre les états ECM et EMM.

ECM_EMM