Cours IUT – Chap 1 (Part 2)

L’architecture du réseau de mobiles 4G

Suite de l’article précédent

1.2. L’architecture protocolaire

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

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

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

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

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

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

1.2.1 L’interface LTE-Uu

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

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

Le protocole RLC opère dans trois modes :

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

La couche RLC effectue les opérations suivantes :

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

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

Le couche MAC assure les fonctions suivantes :

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Références

1 : Livre LTE-Advanced Pro

Présentation de l’architecture CUPS : Control and Use Plane separation

I) L’architecture du réseau mobile 4G

Le réseau de mobiles 2G/3G/4G est rappelé sur la figure 1 :

Figure 1 : Architecture des réseaux de  mobiles

Le réseau est composé de trois accès radios complémentaires (2G/3G/4G) et de deux trois cœurs réseaux, l’un dédié à la gestion des appels téléphoniques (exploitant la technique de commutation de circuit – MSC), le second dédié à la gestion des sessions Data (exploitant la technique de commutation de paquets) en 2.5G/3G (SGSN, GGSN), le troisième est le cœur réseau tout IP pour la 4G. Ce cœur réseau est représenté sur la figure 2.

Sur la figure 2 apparaît une nouvelle entité nommée TDF (Traffic Detection Function). Son rôle est d’analyser le trafic (DPI – Detection Packet Inspector) pour détecter des flux sous surveillance de l’opérateur afin de proposer des fonctions réseaux spécifiques aux flux détectés.

Figure 2 : Evolution de l’architecture réseau 4G (R11)

Lorsque l’utilisateur souhaite établir une session Data, l’entité MME transmet à l’entité SGW et à l’entité PGW (via le protocole GTP-C) la requête de création de support avec les caractéristiques associées au support (priorité, débit, temps réel, …)

Ainsi, les entités SGW et PGW gèrent à la fois le plan de contrôle et le plan de données utilisateurs.

II) L’approche SDN : CUPS (Control User Plane Separation)

Le CUPS propose de séparer en deux parties les entités SGW et PGW. Le contrôleur se nomme SGW-C et PGW-C et le plan de données deviennent les entités SGW-U et PGW-U.

Les règles de traitement de flux sont transmises du contrôleur aux entités du plan utilisateur par une session de règle SX. Cette session permet d’injecter les règles de traitement via le protocole PFCP

Figure 3 : La séparation du plan de contrôle et du plan utilisateur (CUPS)

L’entité fonctionnelle CP s’interface avec plusieurs entités fonctionnelles UP et une entité fonctionnelle UP peut être partagée par plusieurs entités fonctionnelles CP. Le contrôle des flux reste ancré sur un unique SGW-C mais différents SGW-U peuvent être choisis pour différentes connexion PDN. L’entité fonctionnelle CP (SGW-C et PGW-C) fait une sélection (via une recherche DNS évoluée) de l’entité UP en prenant en compte :

  • la localisation de l’entité UE afin de réduire la latence si besoin
  • la capacité de l’entité fonctionnelle UP de prendre en compte les caractéristiques de l’entité UE
  • La charge (overload) de l’entité SGW-U

Pour le dernier point, l’entité SGW-C doit supporter les caractéristiques Load Control transmises sur l’interface Sx.

Localisation de l’UE

Selon la définition, l’aire de service de l’entité SGW est un ensemble de zone de suivis (Tracking Area  TAI) entiers. A chaque mise à jour de localisation, l’entité UE reçoit de la part du MME une liste de zone de suivi (TA) correspondant à la position du mobile UE couvert par le SGW. Deux mobiles UE dans la même cellule peuvent avoir des listes de TA différentes pour ne pas solliciter des ressources réseaux sur les mêmes eNB.

Dans le cas de la séparation en plan de contrôle et plan utilisateur, le SGW-C n’a pas de lien physique avec les stations de base eNB mais communiquent avec les entités fonctionnels comme le MME, le SGSN, le PGW et le SeGW (Security Gateway pour la demande de création de connexions PDN. Le lien avec les eNB est maintenu via l’interface S1-U avec l’entité SGW-U. Dans le cas du CUPS, l’aire de service du SGW-U correspond à l’aire de service du SGW.

Ainsi, en cas de relocalisation sur une entité fonctionnelle SGW-U, il est préférable de trouver l’entité  SGW-U qui couvre la liste de TA (TA1, TA2, TA3) fournit par l’entité MME au mobile UE.

Capacité de l’entité fonctionnelle UP

Les entités fonctionnelles du plan utilisateur peuvent implémenter des fonctionnalités spécifiques qui ne seront utilisées que par des nombre limités d’entités UE comme par exemple, un type de service supportant les communications à haute latence (High Latency Communication HLcom). Pour ce type de service, le SGW-U implémente des fonctionnalités spécifiques de buffer.

Ainsi, en cas de relocalisation sur une entité SGW-U, il est préférable de trouver l’entité  SGW-U qui supporte les fonctionnalités attendues, comme par exemple un buffer étendu pour les communications à latences élévées.

Les conséquences du CUPS

L’avantage de contrôler plusieurs entités SGW-U par un seul SGW-C est de simplifier la gestion de la mobilité et mieux gérer l’équilibrage de charge. De plus, avec la virtualisation du SGW-U, il est possible d’allouer plus ou moins de ressources au SGW-U.

La zone de service du SGW-C peut être plus grande que la zone de service du SGW-U. Dans ce cas, le SGW-C est partitionné et chaque SGW-C gère un SGW-U. Pour assurer la compatibilité entre les différentes évolutions du standard, le MME considère le SGW-C comme un SGW classique. L’alignement de la zone de service du SGW-C partitionné avec le SGW-U assure que la liste de TAI fournie par le MME au SGW-C partitionné permet de sélectionner les SGW-U couvrant ces zones de suivis (la liste de TAI).

Si, pour un UE donné, le SGW-C a sélectionné plusieurs entités SGW-U dans ce cas, la zone de service des SGW-Us réunis couvrent au moins la zone de service du SGW-C.

III) SDN et PFCP : les protocoles d’injections de règles

L’entité de contrôle SGW-C et PGW-C injecte les règles de traitement de flux aux SGW-U et PGW-U afin de connaître les règles d’acheminements des paquets. L’injection de règles s’effectue via l’interface Sxa ou Sxb. Le contrôleur crée une session Sx avec la fonction du plan utilisateur via le protocole d’injection PFCP (Packet Forwarding Control Plane).

Les protocoles OpenFlow, Forces n’ont pas été retenu car ils ne répondaient pas aux critères recherchés :

  • facilité d’implémentation aux fonctions du plan de contrôle (SGW-U, PGW-U) ;
  • latence faible ;
  • gestion de toutes les caractéristiques existantes 3GPP
  • facilité d’étendre ou maintenir le protocole pour supporter les fonctions 3GPP
  • Compatibilités avec les standards 3GPP précédents

Ainsi, le protocole PFCP a été retenu et propose les propriétés suivantes :

  • Une association Sx doit être établie entre la fonction CP et la fonction UP avant d’établir une session Sx (injection de règles). La fonction CP et UP sont appelés Nœuds Sx.
  • Les procédures entre les nœuds Sx sont :
    • Procédure d’établissement, de mise à jour ou de libération de l’association Sx
    • Procédure vérifiant que la session Sx est active (alive)
    • Procédure de contrôle de charge et de congestion afin d’équilibrer la charge sur d’autres fonctions du plan utilisateur (SGW-U, PGW-U) et réduire la signalisation vers l’UP en cas de congestion.
  • La session Sx provisionne les règles d’acheminements de flux du contrôleur vers l’entité du plan utilisateur. La session Sx peut correspondre aux règles d’une connexion PDN pour un UE ou pour une session TDF
  • Procédure de gestion Sx PFD pour injecter les PFD (Packet Flow Descriptions) pour chaque application.