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)

 

SDT – Small Data Transmission (3ème)

Procédure d’accès aléatoire EDT/RA-SDT

La spécification R.15 propose une évolution de la procédure d’accès aléatoire nommée EDT Early Data Transmission. En cours de procédure d’accès aléatoire, le mobile UE peut transmettre des données dans le message 3 dont la taille est comprise entre 328 et 1000 bits et le message 4 est utilisé pour la transmission descendante [4]. La taille TBS (Transport Block Size) est toutefois imposée par l’accès radioélectrique RAN dans un message 2 RAR.

La transmission des données s’effectuant pendant la phase d’accès aléatoire, le mobile est soit à l’état RRC_IDLE soit à l’état RRC_INACTIVE, mais il n’est pas encore passé à l’état RRC_CONNECTED.

Deux optimisations pour la transmission EDT sont proposées :

  • CP-EDT : Control Plane EDT lorsque le mobile est à l’état RRC_IDLE
  • UP-EDT : User Plane EDT lorsque le mobile est à l’état RRC_CONNECTED

Cela signifie d’une part que les clés de sécurités sont différentes sur le chiffrement des messages (et sur l’authentification uniquement pour le mode CP) et que le tunnel est établi via un message NAS (eNB vers MME dans le cas CP-EDT) alors que les données sont transmises vers le SGW dans le cas de la transmission UP-EDT pour transmettre des données après la procédure d’accès aléatoire (mode connecté).

La procédure MO-EDT (Mobile Originating EDT) permet au mobile UE de transmettre des données lorsque la couche haute demande l’établissement d’une connexion RRC ou l’activation de la connexion RRC (resume) pour la transmission de données (MO Data). La cause de l’établissement n’est ni un SMS, ni de la signalisation mais la transmission de données.

Pour activer la transmission EDT, le mobile UE doit informer la station de base qu’il transmettra au cours du message 3 de la procédure RACH des paquets de données. Si la station de base supporte la transmission EDT, elle propose aux terminaux UE des séquences PRACH particulières (ou NPRACH pour le NB-IoT) en diffusant cette information dans le SIB2. Le terminal choisira une séquence PRACH pour constituer le message 1.

Dans le message 3 de la procédure RACH :

  • Si le terminal est à l’état RRC_IDLE, la transmission CP-EDT est mise en oeuvre et le terminal transmet la requête RRCEarlyData Request avec le message NAS encapsulé (S-TMSI, establishmentCause, dedicatedInfoNAS);
  • Si le terminal est à l’état RRC_INACTIVE, la transmission UP-EDT est mise en oeuvre et le terminal transmet la requête RRCResumeRequest

Le message EDT est transmis en clair sur l’interface radio si le mobile était à l’état RRC_IDLE ou chiffré en utilisant le contexte de sécurité AS si le mobile était à l’état RRC_INACTIVE. Le message NAS est quant à lui chiffré selon les clés de sécurités NAS connues au niveau du mobile UE et du cœur de réseau (MME/AMF).

Figure 8 : Protocole de transmission CP-EDT

Figure 9 : Protocole de transmission UP-EDT

Procédure de transmission pré-configurée PUR (Preconfigured Uplink resource)

La spécification 3GPP R.16 PUR [5,6] propose de réduire davantage la signalisation par rapport à la procédure EDT en supprimant les messages 1 et 2 de la procédure d’accès aléatoire.

Le mobile dispose ainsi d’une pré-configuration lorsqu’il est à l’état CONNECTE lui permettant de connaître :

  • Les spécifications de ressources (UL-Grant) ;
  • Le schéma de modulation et de codage MCS ;
  • Le nombre de répétition PUSCH ;
  • L’identifiant radio RNTI à utiliser : PUR C-RNTI

La configuration du mobile par un message RRC est déclenché soit par le mobile avec une requête PUR Configuration Request ou par l’eNB ou le réseau à travers un message RRC.

Dans le cas d’étude qui nous intéresse, le mobile étant statique la valeur du Timing Advanced (TA) ne change pas, dans le cas ou le mobile conserve la même cellule de service (Serving Cell). Comme évoqué dans l’introduction, le changement de cellule peut intervenir en cas de défaillance de la station de base lorsque le mobile est en écoute.

L’allocation de ressource de type 5, uniquement applicable pour les terminaux BL/CE est configurée à partir du paramètre PUR-Config [6].

La première transmission PUSCH PUR est séquencée par un message RRC, les messages subséquents sont ordonnancés par un message DCI.

Une étude plus importante doit être menée pour connaitre les conditions de validité de cette procédure.

 Etats RRC_INACTIVE (5G)/RRC_IDLE et RRC_CONNECTED

L’état RRC INACTIVE a été introduit en 5G de manière à conserver au niveau de la station de base et du mobile UE le contexte AS (Access Stratum), dans le but de réduire la consommation énergétique et le nombre de messages échangés entre le mobile UE et la station de base.

La spécification R.13 (4G) introduit deux nouveaux messages : RRC SUSPEND et RRC RESUME pour modifier l’état du mobile UE au niveau du mobile et de la station de base.

ATTENTION, en 4G le mobile revient à l’état RRC_IDLE à la réception du message RRC SUSPEND.

L’état INACTIVE apparait avec la 5G. Le noeud radioélectrique 5G peut être une station de base 4G ou une station de base 5G. Ainsi, l’état RRC_INACTIVE apparait à partir de la R.15 sur l’accés radioélectrique E-UTRAN, à condition d’avoir un cœur de 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 10 : Les états du mobile UE 4G/5G

Figure 11 : Grafcet des états du mobile pour le 5GC

Lorsque le mobile UE est à l’état RRC INACTIVE, il dispose d’un identifiant I-RNTI permettant d’identifier le contexte AS et permettant à la station de base de s’adresser au mobile UE via les messages de signalisation RRC, mais l’identifiant I-RNTI n’est pas utilisé pour embrouiller les bits du CRC.

Dans le cas d’un coeur de réseau 4G, le mobile ayant reçu une demande de suspension passe à l’état inactif. L’identifiant I-RNTI n’existe pas en 4G mais uniquement en 5G. De ce fait, pour la 4G, c’est l’identifiant S-TMSI qui est utilisé, ce qui explique pourquoi le S-TMSI et l’I-RNTI ne servent pas à embrouiller les bits CRC mais uniquement comme un identifiant de terminal.

Il y a deux formats I-RNTI :

  • Un format court de 24 bits
  • Un format long de 40 bits

Le mobile UE utilise l’un des deux formats en fonction de l’information portée par le drapeau « useFullResumeId » porté par le message SIB1.

Figure 12 : Les informations concernant l’identifiant I-RNTI portées par le SIB1

Le format court est utilisé de préférence dans les macro-cellules, le format long pour les micro-cellules ou pico-cellule. En effet, dans le cas des macro-cellules, lorsque le terminal est situé à l’extrémité de la cellule, la connexion radio est mauvaise. La taille minimale du TBS est de 48 bits, si les conditions radios sont mauvaises alors les données pouvant être transmises sans segmentation doivent avoir une taille inférieure à 48 bits. Le Short-I-RNTI ne faisant que 20 bits est préféré au Full-I-RNTI.

L’identifiant I-RNTI est utilisé pour notifier le mobile UE d’une procédure de paging ou pour mettre à jour la localisation (RNA Update). L’identifiant I-RNTI n’est pas utilisé lors de la procédure PRACH pour embrouiller la séquence DCI, il est transmis dans un message RRC, remplaçant l’identifiant UE_Identity en 4G (S-TMSI).

Par contre, la séquence DCI est toujours embrouillée par un identifiant RA-RNTI puis TC-RNTI. A ce titre, le TC-RNTI doit remplacer l’ancien C-RNTI de la précédente transmission SDT (cf la demande de modification : https://portal.3gpp.org/ngppapp/DownloadTDoc.aspx?contributionUid=R2-2102084)

Procédure

Figure 13 : La procédure d’activation de lien RRC (Passage de l’état RRC IDLE à l’état RRC CONNECTED) pour un coeur de réseau 4G

RRCRESUMEREQUEST ou RRCRESUMEREQUEST1

Quand le mobile UE souhaite transmettre un message, il déclenche la procédure d’accès aléatoire puis demande le rétablissement de la connexion radioélectrique via le message RRCResumeRequest ou le message RRCResumeRequest1. Le mobile émet la requête RRCResumeRequest1 si le SIB1 contient l’information useFullResumeID pour transmettre l’identifiant I-RNTI sur 40 bits. Sinon, le mobile émet la requête RRCResumeRequest avec l’identifiant SHORT-IRNTI.

UE CONTEXT RESUME REQUEST

La procédure UE CONTEXT RESUME REQUEST permet à l’eNB d’indiquer au cœur de réseau (MME/AMF) que le mobile UE souhaite reprendre la connexion RRC suspendue ou pour permettre l’émission d’un message EDT.

5G-NR : RA-SDT et CG-SDT

La procédure SDT (Small Data Transmission) est définie lorsque le mobile est à l’état RRC_INACTIVE.

La procédure RA-SDT est similaire à la procédure EDT lorsque le mobile est soit à l’état de veille, soit à l’état inactif en proposant de transmettre le signal en 4 étapes ou en 2 étapes. Plus précisément, la R.16 propose une procédure d’accès aléatoire en 2 étapes nommées 2-Step RA.

La transmission EDT ou RA-SDT transmet les informations lorsque le mobiles est à l’état de veille (CP-EDT) ou à l’état RRC_INACTIVE (UP-EDT ou RA-SDT). La procédure d’accès aléatoire 2-Step RA permet donc de transmettre les données en 2 étapes seulement.

La procédure CG-SDT est similaire à la procédure PUR lorsque le mobile est à l’état inactive.

L’une et l’autre sont en cours de spécification dans la R.17 [7]. La mise en œuvre de la R.17 radio ne sera pas réalisée avant 2024/2025.

Je bloque actuellement sur le point suivant :

En reprenant la spécification TS 36.300 :

« Transmission using PUR allows one uplink transmission from RRC_IDLE using a preconfigured uplink resource without performing the random access procedure. »

Mais, la 3GPP définit la transmission PUR de la manière suivante :

« Transmission using PUR is triggered when the upper layers request the establishment or resumption of the RRC Connection »

Cela signifie donc que l’UE est à l’état RRC_INACTIVE et non à l’état de veille?

Conclusion

Pour passer du mode de veille au mode connecté, le terminal UE émet une séquence aléatoire dont les caractéristiques (racine de la séquence) et l’instant d’émission est transmise par la station de base au mobile UE.

Concernant l’émission de la séquence aléatoire, la sous-trame de transmission est définie par le message SIB2.

La transmission SDT est défini comme une transmission pour laquelle l’UE n’a pas besoin de passer à l’état RRC_CONNECTED.

La procédure de transmission de message SDT à 2 messages (EDT ou RA-SDT) consiste à transmettre les données lors de la procédure d’accès aléatoire à l’état RRC_IDLE ou RRC_INACTIVE.

La procédure de transmission PUR ou CG-SDT nécessite que le mobile soit à l’état RRC_INACTIVE suivant un état RRC_CONNECTED. Lorsque le mobile est à l’état RRC_CONNECTED, la station de base transmet la configuration des allocations de ressource à l’UE (MCS, UL Grant, TA). Cette configuration n’est valable que tant que le mobile reste sous la couverture de la même station de base (pas de modification du TA Timing Advanced).

 Pour plus d’information, n’hésitez pas à me contacter pour une formation sur les réseaux LPWAN.

Ressources Bibliographiques

[1] TS 136 211 – V14.2.0 – LTE; Evolved Universal Terrestrial Radio  Table 5.7.1-2: Frame structure type 1 random access configuration for preamble formats 0-3

[2] TS 136 211 – V14.2.0 – LTE; Evolved Universal Terrestrial Radio  Table 5.7.2-4: Root Zadoff-Chu sequence order for preamble formats 0 – 3

[3] TS 136 211 – V14.2.0 – LTE; Evolved Universal Terrestrial Radio  Table 5.7.2-2 NCS for preamble generation (preamble formats 0-3)

[4] Andreas Höglund, Dung Pham Van, Tuomas Tirronen, Olof Liberg, Yutao Sui, and Emre A. Yavuz, “3GPP Release 15 Early Data Transmission”, 2018, IEEE Communications Standards Magazine ( Volume: 2, Issue: 2, JUNE 2018), p90-96, https://doi.org/10.1109/MCOMSTD.2018.1800002

[5] Andreas Höglund, G. A. Medina-Acosta, Sandeep Narayanan Kadan Veedu, Olof Liberg, Tuomas Tirronen, Emre A. Yavuz, and Johan Bergman , 3GPP Release-16 Preconfigured Uplink Resources for LTE-M and NB-IoT

[6] 3GPP TS 36.213, R.16.8.0 : Evolved Universal Terrestrial Radio Access (E-UTRA); Physical layer procedures

[7] 3GPP TS 38.321, R.17.0.0 (mars 2022), MAC protocol Specification.