Les supports de signalisation SRB (Signaling Radio Bearer)

Introduction

L’établissement de bearer radioélectrique de signalisation SRB [1,2] (Signaling Radio Bearer) permettent l’échanges de messages RRC et de messages NAS (couches supérieures) entre l’UE (User Equipment) et la station de base.

Figure 1 : Les supports de signalisation SRB

Jusqu’à la spécification R.14, le réseau d’accès radioélectrique 4G E-UTRAN supporte 3 types de SRB numérotés de 0 à 2. La spécification 3GPP propose le bearer SRB4 à partir de la R.15 [3].

La 5G-NSA introduit un SRB supplémentaire (SRB3) pour l’échange de message RRC entre l’UE et le nœud radioélectrique secondaire SN (Secondary Node) et une séparation des SRB1 et SRB2 nommés respectivement Split SRB1 et Split SRB2.

L’inteface NB-IoT présente le bearer SRB1bis.

L’interface 5G reprend les notions de bearer SRB0 à SRB2.

Les messages échangés entre un UE et une station de base doivent être protégés (chiffrement), authentifiés (intégrité) et sur des allocations de ressources spécifiques (des blocs de ressources physiques PRB alloués à l’UE, éventuellement PRB alloués à plusieurs UE dans le cas d’un multiplexage d’accès non orthogonal NOMA).
Toutefois, lorsque le mobile est à l’état de veille RRC_IDLE, son interface radioélectrique est déconnectée de la station de base. L’UE écoute les informations émises par la station de base (MIB/SIB, Synchronisation, Paging) mais ne transmet aucun message dans le canal dédié PUCCH/PUSCH vers la station de base. Le mobile peut uniquement émettre un message de demande d’accès aléatoire sur le canal commun PRACH et recevoir la réponse sur le canal commun logique CCCH. Des requêtes de signalisation peuvent être émises au cours de cette procédure.

Ainsi, lorsque l’UE souhaite passer de l’état RRC_IDLE à l’état RRC_CONNECTED (cf. article précédent), il doit dans un premier temps signifier sa présence à la station de base en transmettant sa demande sur le canal de contrôle commun. Il s’agit de la procédure d’accès aléatoire RACH (Random Access Channel).

On définit ainsi l’établissement des bearers radioélectrique de signalisation SRB de la
manière suivante :

  • SRB0 correspond à l’échange de signalisation entre l’UE et la station de base lors de la procédure d’accès aléatoire. L’échange entre l’UE et la station de base se fait sur le canal de contrôle commun CCCH, en mode transparent TM-RLC. Les échanges RRC ne sont pas sécurisés (pas de chiffrement, ni d’intégrité). Le bearer SRB0 permet d’allouer des ressources radioélectriques dédiées au mobile pour basculer sur la canal dédié DCCH (Dedicated Control Channel)
  • SRB1 permet l’échange de messages RRC et de messages NAS encapsulés dans le message RRC sur le canal DCCH. Le bearer SRB1 permet l’activation du mode de sécurité entre l’UE et la station de base. Pour activer le mode de sécurité, les premiers messages RRC transmis sur le bearer SRB1 sont non chiffrés mais authentifiés par un sceau MAC. Le dernier message est quant à lui chiffré et authentifié. La transmission se fait en mode acquitté RLC-AM.
    • Pour les terminaux NB-IoT, le bearer de signalisation se nomme SRB1bis
  • SRB2 permet l’échange de message RRC sécurisés. La transmission se fait en mode acquitté RLC-AM.
    • Pour les terminaux NB-IoT, le bearer de signalisation SRB2 n’est pas
      applicable.
  • SRB4 (R.15) est configuré sur le réseau d’accès E-UTRAN pour transmettre des
    mesures au niveau de la couche applicative. Ces mesures sont portées par le canal DCCH

    • Pour les terminaux NB-IoT, le bearer de signalisation SRB4 n’est pas
      applicable

Le bearer SRB0 étant utilisé pour la procédure d’accès aléatoire, ses objectifs sont :

  • D’établir une connexion radioélectrique via le message RRC Connection Setup en 4G ou RRC Setup en 5G
  • De ré-établir la connexion radioélectrique en cas d’échec via le message RRC Connection Re-establishment Request en 4G ou RRC Re-establishment Request en 5G
  • De permettre l’échange de données pour les terminaux LTE BL/CE UE selon
    l’optimisation du plan de contrôle C-IoT EPS optimization ou l’optimisation du plan
    de données U-IoT EPS Optimization.
  • De ré-activer la connexion radioélectrique lorsque le mobile est :
    • à l’état RRC_IDLE via le message RRC Connexion Resume Request à partir de la R.13 [4] sur un cœur de réseau 4G EPC
    • à l’état RRC_INACTIVE via le message RRC Resume Request à partir de la
      R.15 sur un ceour de réseau 5GC

Le bearer SRB1 a pour objectif d’activer la sécurité AS (Access Stratum) entre l’UE et la
station de base et prépare ainsi l’établissement du bearer SRB2. Les messages émis sur le bearer SRB1 sont prioritaires par rapport aux messages émis sur le bearer SRB2.

Le bearer SRB2 est utilisé pour transporter des messages NAS encapsulés dans les requêtes RRC.

Le bearer SRB4 porte les informations sur les mesures relatives à la couche applicative QoE Measurement Collection [5].

Pour l’interface LTE, les messages RRC transmis sont présentés dans le tableau ci-dessous :

Tableau 1 : Les bearers SRB et les messages associés sur l’interface LTE [6]

Pour l’interface 5G NR, les messages RRC transmis sont présentés dans le tableau ci-dessous :

Tableau 2 : Les bearers SRB et les messages associés sur l’interface 5G NR [2]

5G NSA
Le bearer de signalisation SRB3 (R.15) est spécifique au mode MR-DC (EN-DC pour le cas de la 5G-NSA) sur le canal DCCH. La transmission se fait en mode acquitté RLC-AM.

Le support SRB3 permet un échange direct entre l’UE et la nœud radioélectrique secondaire SN (Secondary Node). Le bearer SRB3 est optionnel. L’établissement du SRB3 est décidé par le nœud secondaire.

Tableau 3 : Le bearer SRB3

Références :
[1] TS 36.331 v17
[2] TS 38.331
[3] TS 36.331v15.3.0
[4] TS 36.331, Release 13, version 13.2.0
[5] TS 26.247
[6] https://www.rfwireless-world.com/Tutorials/LTE-signalling-radio-bearers.html

Les états du terminal en 5G

Introduction

Lorsque le réseau 4G a été standardisé, le terminal UE ne pouvait être que dans deux états RRC :

  • RRC_IDLE dit en mode de veille. Ce mode est optimisé de par sa faible
    consommation de puissance
  • RRC_CONNECTED dit en mode connecté. A l’état RRC_CONNECTED, l’UE
    échange des données avec la station de base.

Ces deux états RRC_IDLE et RRC_CONNECTED sont optimisés pour le cas d’usage eMBB (Mobile BroadBand), mais ne sont pas efficace pour des transmissions fréquentes de paquets de petites tailles.

La spécification R.15 relative à la 5G apporte un état supplémentaire RRC_INACTIVE. Le passage de l’état RRC_INACTIVE à l’état RRC_CONNECTED est établi lors de la procédure d’accès aléatoire via le message RRC Connection Resume Request.

A l’instar de la 4G, le passage de l’état RRC_IDLE à l’état RRC_CONNECTED est réalisé lors de la procédure d’accès aléatoire. Dans le cas de l’interface 5G NR, voici les 3 requêtes RRC échangées pour l’établissement de la connexion (les deux premières requêtes sont transmises lors de la procédure d’accès aléatoire RACH) :

  • RRCSetupRequest initié par le terminal UE pour l’établissement d’une connexion RRC (msg 3 de la procédure RACH)
  • RRCSetup (msg4 de la procédure RACH)
  • RRCSetupComplete.

Figure 1 : Demande d’accès aléatoire en 4G

Sur un cœur de réseau 4G : le passage de l’état RRC_CONNECTED à l’état RRC_IDLE est provoqué :

  • Soit par le relâchement de la connexion RRC en fin d’un temporisateur ou par ordre du MME dans le cas où il est congestionné.
  • Soit par la suspension de la connexion RRC

Le relâchement est normalement initié par le réseau d’accès radioélectrique RAN via la requête RRCConnectionRelease. Dans certains cas, le mobile peut néanmoins relâcher sa connexion RRC et passer à l’état RRC_IDLE sans en informer le réseau d’accès radioélectrique.

La requête RRC Connection Release émise sur le bearer de signalisation SRB1 supprime le contexte AS au niveau du réseau d’accès radioélectrique et du mobile.

Figure 2 : Relâchement de la connexion RRC

Dans le cas d’usage pour l’IoT (CAT-M, NB-IoT), la spécification 3GPP propose dans la R.13 la suspension de la connexion RRC. Celle-ci est à l’initiative du réseau d’accès radioélectrique en émettant la requête RRCConnectionRelease, et le terminal revient à l’état RRC_IDLE. Cette requête contient :

  • L’identifiant resumeIdentity pour retrouver le contexte de l’UE
  • La cause de relâchement : rrc-Suspend

Lorsque le terminal est à l’état RRC_IDLE, la requête RRC ConnectionResumeRequest, est exécutée par le terminal UE pour restaurer le contexte AS. Le mobile passe ainsi à l’état RRC_CONNECTED.

Lorsque le mobile émet sa requête RRCConnectionResumeRequest alors l’UE restaure :

  • la configuration RRC
  • le contexte de sécurité à partir du contexte AS conservé au niveau de l’UE
  • l’état PDCP et le ré-établissement de l’entité PDCP pour le bearer SRB1

A la réception du message RRCConnectionResume au niveau de l’UE, celui-ci restore le SRB2 et le DRB et met à jour la clé Kenb à partir de la clé Kasme et de la valeur
nextHopChainingCount contenu dans le message RRCConnectionResume puis dérive les clés de chiffrement du lien radio.

Pour résumer, cette procédure RRCConnectionResume permet de ré-activer les bearers SRB et DRB ainsi que le contexte de sécurité AS.

Figure 3: Accès aléatoire : Mode connecté en 4G

Sur un cœur de réseau 5GC

Pour prendre en compte les cas d’usage de l’IoT et URLLC, le standard 3GPP a défini un nouvel état nommé RRC_INACTIVE dans le cas de la 5G. Un terminal UE est soit à l’état RRC_CONNECTED, soit à l’état RRC_INACTIVE à partir du moment ou une connexion RRC a été établie [1].

L’état RRC_INACTIVE a été introduit pour les terminaux IoT (R.15) dans le but de réduire le nombre de requêtes de signalisation et par conséquent la consommation énergétique.

Comme nous l’avons vu précédemment, la spécification R.13 introduisait déjà deux nouveaux messages : RRCConnectionRelease avec la cause rrc_suspend pour conserver des informations de contexte du terminal UE au niveau du mobile et de la station de base et RRCConnectionresume pour restaurer le contexte et les bearers.

La figure 4 présente les états et les passage d’un état à un autre état dans le cas d’un réseau 5G.

Dans l’état RRC_INACTIVE, le mobile et la station de base suspendent leur connexion radioélectrique mais le contexte AS est conservé au niveau du mobile et de la station de base. Le cœur de réseau considère que le mobile est toujours à l’état RRC_CONNECTED. La sélection de cellule est gérée par le mobile mais le paging est géré par la station de base.

Figure 4 : Les états du mobile UE sur un cœur 5GC

Lorsque le mobile est à l’état RRC_INACTIVE, cela permet :

  • De transmettre rapidement des petits paquets de données sans délai ;
  • De réduire les requêtes de signalisation et la latence associée
  • Réduire la consommation énergétique du mobile par rapport à l’état RRC_CONNECTED

La suspension de la connexion RRC est initiée par le réseau d’accès radioélectrique RAN via :

  • LTE : la requête RRCConnectionRelease avec pour cause rrc_suspend (pour l’UE ou pour un NB-IoT ReleaseCause-NB-r13)
  • 5G-NR : la requête RRCRelease with Suspend Config.

Le relâchement est normalement initié par le réseau d’accès radioélectrique RAN via la requête RRCRelease en 5G. Dans certains cas, le mobile peut néanmoins relâcher sa connexion RRC et passer à l’état RRC_IDLE sans en informer le réseau d’accès radioélectrique.

La requête RRCRelease supprime le contexte AS au niveau du réseau d’accès radioélectrique et du mobile.

La requête de suspension de la connexion RRC est chiffrée et protégée en intégrité. Lorsque le mobile doit suspendre sa connexion RRC, il conserve son contexte AS et l’identité associé au contexte resumeIdentity. La suspension ne peut se faire que si au moins un DRB a été établi.

A la différence du cœur de réseau 4G EPC [2]:

Sur le cœur de réseau 5GC : le passage de l’état RRC_CONNECTED à l’état RRC_IDLE est provoqué par le relâchement de la connexion RRC.

Sur le cœur de réseau 5GC : le passage de l’état RRC_CONNECTED à l’état RRC_INACTIVE est provoqué par la suspension de la connexion RRC

Sur l’interface radio 5G NR ou E-UTRA (connecté au cœur de réseau 5GC), pour passer de l’état RRC_CONNECTED à l’état RRC_INACTIVE, le réseau d’accès radioélectrique suspend la connexion radioélectrique avec l’UE. Le basculement est déclenché par la requête RRC_RELEASE_WITH_SUSPEND émise par la station de base vers le terminal sur l’interface NR et par la requpete RRC_RELEASE avec la cause rrc_suspend sur l’interface E-UTRA.

Pour passer de l’état RRC_INACTIVE à l’état RRC_CONNECTED, le terminal émet la requête RRCConnectionResumeRequest ou la requête RRCResumeRequest à la station de base.

L’état RRC_INACTIVE est proche de l’état RRC_IDLE au niveau de l’accès radioélectrique avec conservation de son contexte AS et de l’état CONNECTED pour le cœur de réseau :

  • Le contexte AS est maintenu au niveau de la station de base et de l’UE
  • Le réseau d’accès radioélectrique connait la zone de tracking radioélectrique RNA (RAN based Notification Area), zone dans laquelle l’UE peut se déplacer sans aucun échange de signalisation vers le réseau d’accès radioélectrique. Il s’agit de la zone de paging radioélectrique
  • Le cœur de réseau considère que le mobile est toujours à l’état RRC_CONNECTED. La fonction AMF conserve son contexte, lui permettant de savoir quelle fonction SMF gère le bearer entre l’UPF et le gNB.

La figure ci-dessous présente les différents états du terminal UE et le passage d’un état à un autre état pour un cœur de réseau 5GC

L’état E-UTRA RRC_INACTIVE n’est pas défini pour un cœur de réseau 4G EPC

Figure 5 : Les procédures de mobilité entre l’E-UTRA/5GC et le NG-RAN/5GC

La figure ci-dessous présente les différents états du terminal UE et le passage d’un état à un autre état pour un cœur de réseau EPC à droite.

Figure 6 : Les procédures de mobilité entre l’E-UTRA/5GC et l’E-UTRA 4G

Dans l’état NR RRC_IDLE :

  • le mode DRX peut être activé avec un temporisateur spécifique pour l’UE
  • Le terminal UE contrôle sa mobilité (re-sélection de cellule) à partir de la
    configuration réseau
  •  Le terminal UE
    • Scrute les messages de notification (paging) sur le canal de contrôle PDCCH à partir de l’identifiant radio P-RNTI embrouillant le message DCI.
    • Scrute le canal de paging avec l’identité 5G-S-TMSI
    • Réalise des mesures radioélectriques pour la (re)sélection de cellules avec les  stations de base voisines
    • Lit les informations de diffusion (SI) et peut éventuellement envoyer une requête SI (si configuré)

Dans l’état NR RRC_INACTIVE :

  •  le mode DRX peut être activé avec un temporisateur spécifique pour l’UE par le NAS ou par le gNB (upper layer or RRC layer)
  • Le terminal UE contrôle sa mobilité (re-sélection de cellule) à partir de la
    configuration réseau
  • L’UE sauvegarde le contexte AS Inactif
  • Une zone de paging RNA (RAN-Based Notification) est configuré sur la couche RRC
  • Le terminal UE :
    • Scrute les messages de notification (paging) sur le canal de contrôle PDCCH à partir de l’identifiant radio P-RNTI embrouillant le message DCI.
    • Scrute le canal de paging avec l’identité 5G-S-TMSI et les paging radio avec
      l’identifiant radioélectrique I-RNTI
    • Réalise des mesures radioélectriques pour la (re)sélection de cellules avec les stations de base voisines
    • Lit les informations de diffusion (SI) et peut éventuellement envoyer une requête SI (si configuré)

Dans l’état NR RRC_CONNECTED

  • L’UE conserve l’état du contexte AS
  • Transfère les données entre le mobile et la station de base
  • L’UE peut être configuré en mode C-DRX sur la couche MAC
  • L’accès radioélectrique contrôle la mobilité de l’UE
  • Le terminal UE :
    • Scrute les messages de notification (paging) sur le canal de contrôle PDCCH à partir de l’identifiant radio P-RNTI embrouillant le message DCI.
    • Scrute les canaux de contrôles associés au canal PDSCH pour être informé de l’ordonnancement
    • Réalise des mesures de qualité du lien radio CSI
    • Réalise des mesures radioélectriques et déclenche la transmission des données vers la station de base pour l’aider à réaliser le handover.
    • Lit les informations de diffusion (SI) et peut éventuellement envoyer une requête  SI (si configuré)

Référence : https://devopedia.org/5g-ue-rrc-states

[1] TS 38.331 : NR; Radio Resource Control (RRC); Protocol spécification (3GPP TS 38.331 version 17.0.0 Release 17)

[2] TS 36.331v15.3.0  TS 36.331 : Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Resource Control (RRC); Protocol specification (3GPP TS 36.331 version 15.0.0 Release 15)

 

Cours IUT – Chap 1 (Part 5)

L’architecture du réseau de mobiles 4G

Suite de l’article précédent

1.5. La transition vers la 5G

1.5.1 La Double Connectivité sur le NG-RAN

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

Cours IUT – Chap 1 (Part 4)

L’architecture du réseau de mobiles 4G

Suite de l’article précédent

1.4. La double connectivité

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

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

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

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

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

  • les stations de base SeNB et le MeNB établissent chacune une connexion avec l’entité SGW. Il s’agit de l’architecture MCG/SCG bearers, nommée architecture 1A, le plan utilisateur (User Plane) est séparé au niveau du cœur réseau (CN).
  • seule la station de base MeNB établit un tunnel avec l’entité SGW et le flux est partagé au niveau de la station de base MeNB vers la station de base SeNB. Il s’agit de l’architecture du Split Bearer nommée architecture 3C, le plan utilisateur (User Plane) est séparé au niveau du RAT.

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

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

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

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

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

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

1.4.1. Le plan de signalisation du DC

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

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

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

1.4.2. La description du plan utilisateur

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

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

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

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

La norme 3GPP propose deux architectures différentes :

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

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

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

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

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

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

1.4.3. Le plan de transport

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

Figure 1.21 : Backhaul CN vers les eNB

1.4.4.1 L’interface S1

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

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

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

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

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

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

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

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

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

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

1.4.4.2 L’interface X2

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

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

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

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

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

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

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

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

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

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

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

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

Etablissement de la connexion radioélectrique : Comparaison 4G et 5G

En reprenant la procédure de demande de connexion d’accès 5G SA, j’ai constaté qu’il y avait deux types de requêtes RRC différentes pour la même procédure.

Le premier échange pour l’établissement de la connexion radioélectrique est identique aux échanges entre le terminal et la station de base 4G, le deuxième échange diffère dans le type de message transmis.

La question qui se pose est donc la suivante : Pourquoi trouve t’on deux types de messages différents pour la même procédure et laquelle est correcte?

Afin de comprendre laquelle était juste, j’ai comparé plusieurs articles pour m’apercevoir qu’au final, la spécification TS 3GPP a évolué entre mars 2018 et novembre 2018. Ce qui explique les deux formalismes différents rencontrés.

Ainsi, je propose dans cet article de comparer la demande d’accès radioélectrique entre un mobile et une station de base 4G et entre un mobile et une station de base 5G en se basant sur la spécification R15 (qui est à l’état gelé).

  1. Introduction

Lorsque le mobile souhaite établir ou ré-établir la connexion radioélectrique avec la station de base, il doit dans un premier temps informer la station de base de sa présence par la procédure d’accès aléatoire avec collision. Il s’agit de la connexion initiale destinée à gérer les conflits éventuels si plusieurs mobiles font simultanément une demande d’accès.

Ensuite, la station de base sécurise le lien radioélectrique (la strate d’accès AS) par chiffrement et intégrité de la strate radioélectrique AS (Access Stratum).

Nous allons présenter dans cet article la connexion radioélectrique sur l’interface 4G et sur l’interface 5G, mettant ainsi en avant les différences et les similitudes.

2) La procédure d’accès aléatoire avec collision 4G

La procédure d’accès aléatoire avec collision, lors de l’établissement ou du rétablissement de la connexion avec un nœud radioélectrique est décrite à la figure 1.

Le mobile choisi un préambule aléatoirement parmi la liste des préambules proposées par la station de base 4G (message SIB2) et transmet sa demande via le canal physique PRACH avec une puissance initiale P.

Le signal PRACH est transmis sur une fréquence porteuse et pendant une sous-trame qui permet de calculer la valeur RA-RNTI d’émission :

En cas de non-réponse de la station de base eNB, le mobile retransmet le même canal PRACH en augmentant la puissance d’émission. Le nombre maximal de retransmission est indiqué par l’information système porté par le SIB2.

Le risque de collision est lié au fait que plusieurs mobiles peuvent transmettre le message PRACH au même instant (donc avec le même identifiant RA-RNTI). La collision ne se produit que si deux mobiles émettent simultanément avec le même préambule.

Lorsque la station de base eNB reçoit le canal physique PRACH, elle calcule l’avance de temps TA et répond au mobile. Le mobile écoute le canal physique PDCCH (Physical Downlink Control Channel) à la recherche de l’information de contrôle DCI format 1A ou 1C dont le RRC est mélangé avec l’identifiant RA-RNTI. Lorsque le mobile récupère l’information DCI correspondant à la réponse d’une demande d’accès aléatoire avec l’identifiant RA-RNTI, le mobile récupère les données correspondantes qui sont transmises par la station de base dans le canal physique PDSCH (i s’agit de la trame MAC RAR).

La trame MAC RAR (Random Access Response) contient l’indice du préambule, l’avance de temps TA, la ressource à utiliser (UL Grant) pour la transmission dans le canal montant et l’identité temporaire TC-RNTI (Tempory Cell RNTI). C’est par l’indice de préambule que le mobile est capable de savoir si la réponse lui est destinée (sauf en cas de conflit). Ainsi, si deux mobiles ont fait simultanément la demande d’accès aléatoire avec deux préambules différents, chaque mobile trouvera son identifiant dans la trame MAC RAR.

Le mobile initialise son avance de temps TA et répond avec le message RRC ConnectionRequest contenant :

  • l’identité temporaire S-TMSI (Shortened Temporary Subscriber Identity), si le mobile est déjà attaché;
  • un nombre aléatoire dans le cas contraire (40 bits).

Si deux mobiles avaient fait une demande d’accès aléatoire simultanément avec le même préambule, alors l’entité eNB reçoit les deux message RRC ConnectionRequest sur les mêmes ressources radioélectrique, elle répond au mobile pour lequel elle a pu décoder la requête par le message RRC ConnectionSetupComplete comprenant :

  • l’information DCI dans le canal physique PDCCH ;
  • l’en-tête MAC RAR contenant l’élément de contrôle UE CRI (Contention Resolution Identity). Cet élément de contrôle reproduit l’identité du message RRC ConnectionRequest, permettant ainsi de résoudre la collision.

Le mobile récupère l’information DCI à partir de l’identité TC-RNTI et récupère, à partir de l’information DCI, la description de ses données dans le canal physique PDSCH.

Si deux mobiles avaient simultanément fait une demande d’accès aléatoire avec le même préambule, seul un mobile reçoit la réponse avec l’identifiant S-TMSI ou le numéro aléatoire choisi, le conflit est ainsi résolu.

Après résolution de collision, l’identité temporaire TC-RNTI devient l’identité définitive C-RNTI attribuée au mobile.

Le mobile confirme la connexion radioélectrique en indiquant son C-RNTI dans l’élément de contrôle de la trame MAC du message RRC ConnectionSetupComplete.

Figure 1 : La demande d’accès aléatoire en 4G

 

3) La procédure de connexion radioélectrique 4G

Dans le message RRC ConnectionSetupComplete, le mobile transfère le message NAS dédié au cœur de réseau. Il peut s’agir d’une demande d’attachement et d’établissement de support, ou d’une demande de service (ServiceRequest) pour le ré-établissement d’un support.

Figure 2 : La demande de ré-établissement de support en 4G

Les 4 premiers messages  concernent la procédure d’accès aléatoire. Dans le 5ème message RRC ConnectionSetupComplete, le mobile confirme la connexion du support radioélectrique et transmet la raison de sa demande (message NAS : Non Access Stratum);

L’entité eNB transfère la requête auprès du MME via le message X2 Initial UE Message (non présenté ici). Si l’entité MME acquitte la demande, alors la station de base eNB va procéder à la sécurisation du lien radioélectrique par la requête RRC Security Mode.

Une fois la capacité de chiffrement des messages validés par le mobile (RRC Security Mode Complete), la station de base configure un nouveau support radioélectrique pour l’échange de trafic (RRC Connection Reconfiguration).

 

4) La procédure d’accès aléatoire avec collision 5G

Dans le cas de la procédure d’accès aléatoire 5G, la bande passante est découpée en partition de bande BWP. Dans chaque sous bande BWP, la station de base diffuse le bloc SSB (signal de synchronisation et le canal BCCH) permettant au mobile de se synchroniser en temps et en fréquence et de lire les informations portées par le message MIB.

Pour faire sa demande d’accès aléatoire, le mobile recherche la partition BWP d’accès initiale. La partition de bande initiale correspond à une sous-bande de fréquence dans laquelle la station de base émet le bloc SSB avec en plus un espace de recherche sur lequel le mobile pourra scruter le message d’information DCI transmise par la station de base en réponse à la requête PRACH du mobile.

Si la station de base gNB peut émettre des slots SSB dans des faisceaux différents (beam sweeping), le mobile sélectionne le faisceau de meilleure qualité.

A l’instar de la 4G, le mobile transmet la demande d’accès par le canal PRACH avec une puissance P. Néanmoins, la valeur d’identifiant RA-RNTI se calcule de la manière suivante :

Si le nœud radioélectrique reçoit le canal physique PRACH, il calcule l’avance de temps TA et il transmet la trame MAC RAR (Random Access Response) au mobile (message 2) en lui attribuant les ressources radioélectriques pour le prochain message montant (UL Grant) et l’identité temporaire TC-RNTI (Tempory Cell RNTI).

Figure 3 : La demande d’accès aléatoire en 5G

 

Pour plus d’information sur la procédure RACH, se référer à l’article suivant : http://blogs.univ-poitiers.fr/f-launay/2019/10/14/etablissement-de-la-connexion-radio-partie-3-la-procedure/

5) La procédure de connexion radioélectrique 5G

Sur le web, on trouve deux procédures de connexion radioélectrique :

  • l’une antérieure à la Release V15.4.0 (par exemple : 3GPP TS 38.401 V15.3.0 (2018-09)) où l’on retrouve les mêmes messages que la procédure de connexion radioélectrique 4G
  • la version officielle pour laquelle les messages sont dorénavant les suivants (message RRC similaire en supprimant le mot Connection)

Figure 4 : Les messages RRC pour la demande d’accès aléatoire en 5G

Ainsi, en s’appuyant sur la Figure 8.1-1: UE Initial Access procedure du document 3GPP TS 38.401 V.15.4 ou supérieure (jusqu’à V16.2), on observe le call-flow suivant.

Figure 5 : La procédure d’accès initiale en 5G

 

6) Conclusion

La procédure d’accès initiale en 4G et 5G reste assez similaire, l’approche simplifiée de cet article ne permet pas d’entrer dans les détails de la sélection de faisceau pour l’accès initial 5G. Je prendrai le temps dans un prochain article pour le détailler.

Double Connectivité (DC – Dual Connectivity) 4G/5G

La 5G arrivera en Juillet 2020, le déploiement sera un déploiement au niveau de la couche radio. Comment la 5G sera déployée? Quels services va t’elle apporter? Quelles performances? Comment la station de base 5G (gNB) sera controlée? Peut on parler de 5G si le coeur réseau est 4G?

Ces réponses seront apportées dans une série d’articles, et voici le premier article d’une longue série sur la double connectivité.

Introduction

La double connectivité implique la présence de deux stations de base pour apporter des ressources radio-électrique vers un terminal mais un seul point de terminaison de signalisation vers le coeur réseau. Dans une première phase, le coeur de réseau est le coeur de réseau 4G (EPC), le point de terminaison est donc l’interface S1-MME.

La double connexion implique soit deux stations de bases LTE (se référer à l’article suivant) soit une station de base NR et une station de base LTE (Multi-Radio DC – MR-DC aussi nommé NR-DC).

Chaque nœud radio contient plusieurs cellules (une cellule pour une antenne omni-directionnelle, trois cellules, 6 cellules pour des antennes multi-sectorielles, …), et chaque nœud gère plusieurs porteuses LTE ou NR (agrégation de porteuses).

La double connexion implique donc la gestion de groupe de cellules (GC : Group Cell) pour chaque nœud radio. L’objectif d’un groupe de cellules est de gérer les données sur une ou plusieurs porteuses pour augmenter le débit. Dans un groupe de cellules (GC), on identifie la cellule principale (SpCell) qui est en charge de contrôler toutes les cellules du groupe et optionnellement une ou plusieurs cellules secondaires (SCell).

La double connectivité définie la notion de support MCG (Master Cell Group) et SCG (Secondary Cell Group bearer). Le support MCG est géré par la station de base maitresse, le support SCG correspond aux supports de la station de base secondaire. La double connexion permet de modifier la terminaison du plan de transport (U-plane termination) vers le support MCG ou SCG via la signalisation S1-MME sans modifier le point de terminaison du nœud de contrôle S1-MME (la signalisation est toujours définie entre le cœur de réseau et la station de base maîtresse).

Ainsi, si on appelle MCG le groupe de cellule maître et SCG le groupe de cellules secondaires, le MSG et le SCG peuvent avoit un SpCELL et des SCELL.

La fonctionnalité Double Connectivité (Dual Connectivity DC) a initialement été spécifiée sur le réseau de mobiles 4G entre deux stations de bases eNB différentes (sur des porteuses différentes) avec l’objectif d’augmenter le débit ressenti par l’utilisateur en agrégeant des flux des deux eNB en dépit de la latence provoquée par le lien X2 (backhaul). Cela constitue une différence avec l’agrégation de porteuses ou l’agrégation des flux est réalisée sur la même station de base dans deux bandes radios différentes. Dans le cas de la double connexion, les stations de base n’ont pas besoin d’être synchronisées (et peuvent donc être non co-localisées).

Figure 1 : Agrégation de porteuses et Double Connexion

L’interface X2 est une interface physique, généralement en Fibre Optique. L’interface X2 peut être séparée en deux interfaces, l’interface X2-U pour l’échange de données du plan utilisateur entre la station de base maîtresse et secondaire (handover, double connexion), et l’interface X2-C permettant l’échange des informations de contrôle entre les deux stations de base.

La pile protocolaire pour le plan de transport sur l’interface X2-U utilise les couches protocolaires GTP-U, UDP, IP et la couche de niveau 2

  1. La double connectivité DC 4G-4G (se référer à l’article DC 4G/4G)

L’option DC 4G-4G a déjà été présentée dans un article précédent, on différencie le plan de contrôle et le plan de trafic. L’une des deux stations de base est responsable de la signalisation avec le cœur réseau et le terminal. Les supports (nommés bearer) de signalisation correspondent aux bearer SRB1 et SRB2 entre le terminal Ue et la station de base maîtresse (MeNB). La station de base secondaire est responsable de la connexion de données additionnelles sur le lien radio (DRB) et vers le cœur réseau.

Plan de contrôle :  La station de base maîtresse (MeNB) établie la connexion RRC avec le terminal UE et la connexion radio avec l’entité SeNB (Secondary eNB) est contrôlée par la station de base maîtresse.

Plan utilisateur : Deux options sont supportées pour la DC 4G-4G :

  • Option 1A : Le cœur de réseau établit deux supports (bearer) avec chacun des entités eNB ;
  • Option 3C : Le support est séparé par l’entité MeNB : Split Bearer

Figure 2 : Pile protocolaire DC 4G-4G

Le terminal UE ne dispose que d’une seule entité RRC.

Dans le cas de la double connexion 4G-4G, les deux options retenues parmi toutes les options possibles sont l’architecture 1A et 3C.

Pour l’option 1A, la séparation des flux est gérée au niveau du cœur réseau (SGW).

Pour l’option 3C, la séparation des données est basée sur le routage de support de données PDCP.

Figure 3 : Double Connexion 4G-4G

  1. DC 4G-5G : Déploiement NSA

Le mode de déploiement de la 5G s’appuiera en 2020 sur une double connectivité 4G-5G (mode NSA – Non Standalone Architecture). L’opérateur conserve le cœur de réseau 4G (EPC), la signalisation entre l’accès radio et le cœur de réseau est réalisée par l’entité eNB. On parle d’option 3

Remarque : si le cœur de réseau était 5G on parlerait alors d’option 7, tout chose égale par ailleurs.

Pour l’option 3, le terminal UE est sous le contrôle de la station de base 4G et lors de la demande de connexion radio avec la station de base eNB (LTE PCell), le terminal va être configuré pour monter un support radio NR avec la station de base gNB (dénommée en-gNb : E-UTRAN – NR gNB pour rappeler le mode DC).

Plan de contrôle : Sur l’interface radio, le terminal UE est contrôlé par l’entité eNB et en-gNB (par des messages RRC). La signalisation (CP : Control Plane) est échangée entre les deux stations de base via le lien backhaul X2.

L’application X2AP réalise plusieurs fonctions comme le rappelle la figure 4 :

Figure 4 : les fonctions supportées par l’application X2AP

Plan Utilisateur : Le terminal UE peut être connecté simultanément sur l’entité eNB et en-gNB pour le plan utilisateur ou uniquement avec l’entité en-gNB.

La fonction DC 4G-5G option 3 se décline en trois sous options (figure 4) en séparant le support au niveau de l’accès radio (split bearer) ou en créant un support au niveau du cœur de réseau (MCG ou SCG) :

  • option 3 : La séparation du support (split bearer) est réalisée par l’entité MeNB. Le trafic (UP : User Plane) est transmis à travers le lien X2 vers l’entité SgNB (Slave en-gNB) ;
  • option 3a : La création d’un bearer secondaire (SGC) s’effectue au niveau du cœur réseau (SGW) et le flux de données est transmis sur deux supports (bearer) complémentaires, l’un vers l’entité MeNB, l’autre vers l’entité SgNB ;
  • option 3x : La création d’un bearer est réalisée au niveau du cœur radio (SCG) et la séparation du bearer est réalisée par la station de base secondaire (SCG split bearer).

Figure 5 : Les options 3/7 vert à gauche, 3a/7a (en bleu), 3x/7x vert à droite du mode NSA

L’option 3x consiste à séparer le support DC au niveau de la station de base gNB. L’entité eNB peut conserver un ou plusieurs bearer avec le cœur de réseau (MCG bearer) ou ne gérer que la signalisation entre l’accès radio (eNB/en-gNb) et le cœur de réseau.

Dans le cas du split-bearer, les données sont distribuées ou dupliquées entre les deux nœuds radios. L’équilibrage de charge est réalisé de manière dynamique par le nœud d’ancrage (MeNB ou SgNB) en fonction du trafic, c’est-à-dire par l’entité PDCP du nœud d’ancrage (MeNB pour l’option 3 et SgNB pour l’option 3x).

Dans la suite, on appellera indifférent SgNb ou en-gNB.

Etats RRC – ECM – EMM

Dans un article précédent, Protocole RRC, j’avais conclu par « Le protocole RRC a pour but est de transférer les informations de signalisation entre l’UE et la station de base » (Le protocole S1AP permet ensuite d’acheminer la signalisation au MME), ce qui avait déjà été présenté via cette figure lors de l’article Protocole NAS et AS :

asnas4G

En s’appuyant sur l’article Protocole NAS et AS, j’avais décrit les procédures EMM, ECM et ESM dans l’article EMM, EPS Mobility Management. Il est temps maintenant de conclure cette série d’article et notamment finalisons l’étude de cette figure :

emm_1

Les états EMM et ECM ont été étudiés plus en détail dans l’article ECM, EPS Connexion Management.

Jusqu’à présent, j’avais occulté le protocole RRC alors que ce dernier porte la signalisation NAS. Mais, l’état RRC du mobile évolue de manière duale avec l’état ECM

La figure suivante montre les états de transition entre l’EMM et l’ECM/RRC. Comme on peut le constater, l’état ECM et RRC sont identiques.

Figure 2. EMM State Transition

Cette figure est expliquée dans l’article ECM EPS Connection Management, mais revenons sur les différents états :

Etat A : EMM Deregisterd, ECM/RRC Idle – L’UE vient de s’allumer pour la première fois après avoir souscrit l’abonnement ou allumé après avoir été éteint plusieurs jours. Aucun context UE n’existe sur le réseau LTE

Etat BEMM Deregisterd, ECM/RRC Idle – L’UE s’allume après avoir été éteint pendant un court laps de temps (timer non connu à la rédaction de cet article) ou l’ECM est coupé suite à une perte de la connexion radio

Etat CEMM Registerd, ECM/RRC Connected – L’UE est enregistré sur le réseau LTE et utilise des services. La mobilité est géré par un handover (cellule à cellule pour ne pas couper le trafic)

Etat DEMM Registerd, ECM/RRC Idle – L’UE est enregistré sur le réseau LTE mais n’utilise aucun service. La mobilité est géré par une procédure de reselection de cellule lorsque le mobile passe d’un TAU à un autre.

Quand l’UE s’est attaché au réseau (cf article EMM – Initial Attach), il passe à l’état EMM-Registered et construit le bearer par défaut. Ce bearer est composé de trois partis (cf article BEARER EPS) :

  • DRB : Data Radio Bearer
  • S1 Bearer
  • S5 Bearer

Ces 3 bearers sont établis et restent activés dans l’état C, ECM/RRC Connected – EMM Registered quand l’utilisateur accède à un service et donc des données doivent être échangées.

Mais, dans l’état D, EMM Registerd, ECM/RRC Idle, ou il n’y a plus de trafic utilisateur, seul le bearer S5 est établi et reste actif.

Etat_EMM_ECM

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.