Archives mensuelles : mars 2023

L’accès aléatoire pour les terminaux LTE UE et LTE-BL/CE UE et NB-IoT 4step RA et 2 Step RA

Posté le by - 678 vues
Répondre

La procédure d’accès aléatoire pour les terminaux LTE UE et la procédure d’accès aléatoire pour les terminaux LTE-BL/CE UE dans le cas de la transmission EDT sont presque identiques.

Les objectifs de l’accès aléatoire sont :

  • La connexion radioélectrique d’un terminal UE avec une station de base spécifique, c’est-à-dire l’établissement d’un support radio de signalisation SRB1 (Signaling Radio Bearer 1) sur un canal de contrôle radioélectrique dédié DCCH (Dedicated Channel Control).
  • La gestion de conflit lorsque plusieurs terminaux font une demande simultanée.
  • La synchronisation de la transmission sur le lien montant Uplink pour que le signal réceptionné au niveau de la station de base soit aligné temporellement avec la sous-trame (Timing Advanced). Le Timing Advanced TA correspond à la durée de propagation du signal de l’UE à la station de base.

A travers le signal d’information SIB2 en 4G ou SIB1 en 5G, chaque station de base transmet, par cellule, sa propre configuration de l’accès aléatoire. Ainsi, un UE souhaitant réaliser une connexion radioélectrique est ainsi paramétré par la cellule serveuse, ce qui permet à la station de base de reconnaitre si c’est à elle qu’est adressée la procédure d’accès aléatoire avec contention (CBRA : Contention Based RACH).

En cas de mobilité, lorsque l’UE passe d’une cellule à une autre cellule, il est nécessaire de synchroniser l’UE avec la station de base cible. Dans le cas du HandOver, la procédure d’accès aléatoire sans contention est préférée (CFRA : Contention Free RACH) même si la procédure d’accès aléatoire avec contention reste possible.

Dans le cas de la double connexion MR-DC, le mobile fait une demande de connexion radioélectrique avec le nœud maître MN (Master Node) selon la procédure d’accès aléatoire avec contention CBRA et une fois l’UE connecté, la demande de connexion radioélectrique avec le nœud secondaire est effectuée selon la procédure d’accès aléatoire sans contention.

La liste des paramètres transmis aux terminaux LTE UE et LTE-BL/CE UE sont [4] :

  • Prach-configIndex: indique le format de la demande d’accès aléatoire, et la localisation dans le domaine temporel de la transmission du préambule : la sous-trame dans laquelle doit être transmise la demande d’accès (numéro de la sous-trame et sur toutes les trames ou uniquement les trames paires)
  • Prach-FreqOffset: la localisation dans le domaine fréquentiel de la transmission du préambule
  • rootSequenceIndex: la liste de séquences de Zadoff-Chu parmi les 838 racines de ZC

La procédure d’accès aléatoire 4-Step RA

La procédure d’accès aléatoire traditionnelle s’effectue en 4 étapes sur le canal de contrôle commun (CCCH)

  • Msg1 : Transmission du préambule dans les occasions RACH RO (RACH Occasion) configurées par la station de base afin de séparer les ressources tempo-fréquentielles utilisées pour les terminaux UE et les terminaux MTC (NB-IoT, BL UE et non BL UE). Une liste de préambule est identifiée par station de base et par type de terminaux (UE, NB-IoT, BL UE et non BL UE). L’instant de transmission défini par le numéro de symbole et le slot utilisé, et la fréquence utilisée pour émettre la demande d’accès aléatoire permettent de calculer l’identifiant RA-RNTI.
  • Msg2 : RAR – Response Access Random. La station de base répond au mobile dans un message DCI embrouillé avec l’identifiant RA-RNTI. Le terminal UE est à l’écoute du canal PDCCH. Le message RAR contient l’allocation de ressource en UL permettant au mobile de savoir sur quelles ressources tempo/fréquentielle l’UE transmettra le Msg3 et contient un identifiant radio temporaire T-RNTI. Dans le cas de la transmission EDT, le Msg2 RAR contient de plus un champ indiquant que l’allocation de ressource (UL Grant) correspond à une transmission EDT
  • Msg3 : L’UE envoie une requête RRC avec l’identifiant radio temporaire T-RNTI et un identifiant supplémentaire pour identifier l’UE qui réponse.
    • Si le mobile est à l’état RRC_IDLE,
      • le message émis est la requête RRC Connection Request en 4G ou RRC Setup Request en 5G pour la demande d’établissement d’un bearer radio et bassculer à l’état RRC_CONNECTED
      • le message émis est la requête RRCEarlyDataTransmission Request pour la transmission d’un message EDT en restant à l’état de veille RRC_IDLE.
      • le message émis est la requête RRC ConnexionResume Request pour ré-établir le contexte AS.
    • Si le mobile est à l’état RRC_CONNECTED
      • l’UE a détecté un échec du lien radio (RLF : Radio Link Failure) ou un échec de HandOver, ou un échec sur le calcul d’intégrité MAC_I, le message émis est la requête RRC Connection Re-establishment Request en 4G ou RRC Re-establishment Request en 5G.
      • dans le cas de la 5G (SA ou NSA), si la station de base gNB a envoyé à l’UE le message RRCReconfiguration avec l’information reconfigurationWithSyncIE, alors l’UE réinitialise la couche MAC, relâchant ainsi la configuration UL et le mobile démarre la connexion d’accès aléatoire sur la cellule SpCELL.
    • Si le mobile est à l’état RRC_INACTIVE, le message émis est la requête RRC Resume Request ou requête RRC Resume Request1

Dans le cas des terminaux NB-IoT, LTE-BL/CE UE, les messages 1 et 2 peuvent être répétés plusieurs fois, le nombre de répétition dépend du niveau du puissance de réception de la couverture CE (Coverage Enhanced : CE0, CE1 ou CE2).  La durée de la fenêtre pour la réception du message 2 est également spécifique pour ces terminaux. Ces informations sont transmises dans le SIB2 (SIB2-NB) via l’information RACH-CE-LevelInfoList-r13.

L’UE mesure le niveau de configuration du CE en fonction de la puissance mesurée RSRP. Afin que la station de base prenne connaissance du niveau de CE, la liste des préambules est différente par niveau de CE.

Figure 1 : Niveau de puissance et sélection du CE [1]

La procédure d’accès aléatoire traditionnelle est présentée sur la figure 3 pour le réseau d’accès radioélectrique E-UTRAN et sur la figure 2 pour l’accès radio NG-RAN.

Figure 2 : Procédure d’accès aléatoire sur l’interface LTE

Figure 3 : Procédure d’accès aléatoire sur l’interface 5G-NR [2]

La procédure d’accès aléatoire 2-Step RA – Release R.16

La procédure d’accès aléatoire 2 step RA proposée dans la R.16 permet de réduire la latence et la signalisation en réduisant la procédure d’accès aléatoire à deux échanges. Il s’agit de combiner le message 1 et 3 dans un même message, nommé msgA et les messages 2 et 4 dans un même message nommé msgB.

Figure 5 : Procédure d’accès aléatoire 2 Step RA[2,3]

La procédure d’accès aléatoire à deux étapes 2S-RA s’applique pour les deux procédures avec et sans contention CBRA/CFRA.

Les informations concernant le paramétrage de la procédure d’accès aléatoire est transmise dans le message RRC du SIB1 en 5G. La configuration du réseau défini un seuil msgA-RSRP-Threshold permettant à l’UE de choisir entre l’accès aléatoire à 2 étapes ou 4 étapes.

Si le mobile est à l’état connecté RRC_CONNECTED, le réseau peut configurer le msgA-PUSCH-Config dans la configuration du BWP montant (UL BWP).

La procédure d’accès aléatoire à 2 étapes est plus sensible aux problèmes de ;

  • Réceptions simultanées de plusieurs utilisateurs (payload msgA)
  • Démodulation du message msgA (PUSCH) en étant non synchronisé

Pour savoir quel type de procédure est choisi par l’UE (2 step RA ou 4 Step RA), la liste de préambules pour la demande d’accès à 2 états est différente de la liste des préambules pour la demande d’accès à 4 états.

Les occasions de transmissions des préambules (RO : RACH Occasion) peuvent être spécifiques. La durée de la fenêtre d’écoute du mobile après l’émission de son premier message msgA est définie par le paramètre msgB-ResponseWindow-r16

Les paramètres pour la demande d’accès aléatoires sont définis dans l’élément d’information RACH-ConfigCommonTwoStepRA et msgA-PUSCH-Config-r16 contenu dans la structure du message MsgA-ConfigCommon-r16 (se référer à l’annexe).

Etape 1 : Transmission du message A

Le message A contient un préambule choisi parmi la liste des préambules pour la demande d’accès à 2 états et des données PUSCH (msgA-PUSCH) dans lequel le mobile transmet un message RRC

  • Si le mobile était à l’état connecté RRC_CONNECTED, l’UE transmet son identifiant C-RNTI pour la valeur de ue_identity.
  • Si le mobile était à l’état de veille RRC_IDLE ou à l’état Inactive RRC_INACTIVE, alors l’UE transmet la requête RRC correspondante aux requêtes RRC sur le bearer SRB0 :
    • RRC Setup Request
    • RRCResumeRequest
    • RRCResumeRequest1
    • RRCReestablishmentRequest

Etape 2 : Transmission du message B : msgB

L’UE attend la réponse de la station de base sur une durée définie par la valeur du champ msgB-ResponseWindow (1, 2, 4, 8, 10, 20, 40, 80, 160 ou 320 slots) à partir du symbole suivant le dernier symbole de la séquence d’occasion du PRACH.

L’UE écoute la zone de recherche CORESET et décode le message DCI format 1_0. La réponse destinée au mobile est embrouillée avec l’identifiant C-RNTI si l’UE était en mode connecté ou msgB-RNTI sinon.

L’identifiant msgB_RNTI est calculé de manière assez similaire au RA_RNTI :

MSGB-RNTI = 1 + s_id + 14 × t_id + 14 × 80 × f_id + 14 × 80 × 8 × ul_carrier_id + 14 × 80 × 8 × 2

Lorsque l’UE reçoit le msgB avec l’identifiant C_RNTI, la procédure RA est réussie et la station de base transmet dans le msgB une allocation de ressource pour la voie montante Uplink Grant ou des consignes pour le lien descendant downlink assignment.

Lorsque l’UE reçoit le msgB avec l’identifiant msgB_RNTI, plusieurs réponses sont possibles :

  • La station de base détecte un préambule et arrive à décoder la demande d’accès aléatoire. La station de base retourne à l’UE le message successRAR contenant un identifiant radioélectrique C-RNTI et la valeur du TA.
  • La station de base détecte un seul préambule mais ne parvient pas à décoder le message. A partir de l’instant de réception du préambule, la station de base envoie le message fallback RAR vers l’UE en indiquant la valeur du TA. L’UE poursuit la procédure d’accès aléatoire en 4 étapes et en reprenant au msg3.
  • Plusieurs UE ont lancé la procédure simultanément avec le même préambule, le msgA n’est pas correctement décodé au niveau de la station de base. La station de base ne trasmets pas de fallback RAR car elle ne peut pas indiquer la valeur du TA pour chaque UE. La station de base envoie un message de backoff pour que les terminaux retente la procédure d’accès aléatoire.
  • Le mobile ne reçoit pas le msgB, soit l’UE retente une demande d’accès aléatoire à 2 états ou à 4 états.

 

Références :

[1] https://www.eventhelix.com/5g/standalone-access-registration/5g-standalone-access-registration.pdf

[2] http://howltestuffworks.blogspot.com/2020/04/5g-nr-2-step-random-access-procedure.html

[3] https://www.linkedin.com/pulse/2-step-rach-5g-nr-syed-mohiuddin/

[4] https://blogs.univ-poitiers.fr/f-launay/2022/08/01/bl-ue-non-bl-ue-et-nb-iot-quelles-sont-les-differences/

 

Les supports de signalisation SRB (Signaling Radio Bearer)

Posté le by - 1 481 vues
Répondre

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

Posté le by - 1 119 vues
Répondre

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)

 

L’IoT – Evolutions R16 et R17

Posté le by - 604 vues
Répondre

Introduction

Le standard 3GPP a démarré ses travaux de normalisation pour l’IoT à partir de la R.10 pour définir une liste de spécifications pour les terminaux et le cœur de réseau afin d’éviter la congestion (Extended Access Barring), d’avoir moins d’impact sur les smartphones (LAPI), réduire la complexité (Half Duplex, réduction de la puissance, bande plus petite …), avoir une meilleure sensibilité pour une transmission à faible débit (bande plus petite).

Dans la R.11, la 3GPP propose une méthode de réveil de terminaux et une transmission de données par SMS.

Dans la R.12, la 3GPP propose des optimisations pour la réduction de la consommation énergétique (UEPCOP : mode PSM et eDRX) et une méthode de transmission de données de taille réduite (Small Data)

Figure 1 : Le standard 3GPP R10 à R12 pour l’IoT

Dans la R.13, la 3GPP une optimisation du cœur de réseau pour prendre en charge la transmission de données :

  • dans le plan de contrôle Control-Plane CIoT EPS Optimization ;
  • dans le plan de trafic User-Plane CIoT EPS Optimization.

L’optimisation CP CIoT EPS Optimization propose de transmettre des données dans un message NAS entre l’UE et le MME. Sur l’interface radioélectrique, le message NAS est encapsulé dans un message RRC, lorsque le mobile est à l’état RRC_CONNECTED, c’est-à-dire à la suite de la procédure d’accès aléatoire. Dans l’optimisation CP CIoT EPS Optimization , la mise en sécurité AS n’est pas mise en œuvre, c’est-à-dire la connexion RRC n’est ni chiffrée, ni authentifié (intégrité).

L’optimisation UP CIoT EPS Optimization permet de transmettre des données entre l’UE et le MME lorsque le mobile est à l’état RRC_CONNECTED avec la mise en sécurité AS. Cela suppose que le contexte AS soit conservé au niveau du terminal UE et de la station de base. La R.13 propose une procédure de suspension/reprise de la connexion RRC lorsque le mobile passe de l’état RRC_CONNECTED à l’état RRC_IDLE.

Figure 2 : L’optimisation du coeur de réseau

Sur l’interface LTE, l’optimisation CIoT EPS Optimization permet de transporter les données sur la couche RRC. Le MME peut ensuite transférer les données vers le plan de transport SGW ou l’entité SCEF (Service Capability Exposure Function).

La R.14 introduit les spécifications à mettre en oeuvre pour le 5G MTC.

Figure 3 : Les améliorations proposées de la spécification R.10 à la R.14

La transmission EDT

Pour réduire la signalisation, la transmission EDT (Early Data Transmission [1]) propose de transmettre les données dans un message RRC au cours de la procédure d’accès aléatoire (RACH EDT). On distingue la transmission CP-EDT s’appuyant sur l’optimisation du plan de contrôle CP-EDT (sans chiffrement) de l’optimisation du plan utilisateur UP-EDT (avec chiffrement).

L’inconvénient de la procédure EDT est la transmission du message sur le canal de contrôle commun. Celle-ci est donc interférée par les demande d’accès aléatoire pouvant simultanément avoir lieu sur les mêmes bandes de fréquences.

La transmission UP-EDT est :

    • soit à l’initiative du terminal (Mobile Originated MO-EDT) spécifiée dans la R.15
    • soit à destination du terminal (Mobile Terminated MT-EDT) spécifiée dans la R.16.

La transmission EDT a été proposée dans la R.15 pour optimiser la transmission de messages courts lors de la procédure d’accès aléatoire. Au cours de cette procédure, le mobile reste à l’état RRC_IDLE sans contexte AS (CP EDT – Contol Plane EDT) ou en ayant conservé le contexte AS (UP EDT – User Plane EDT). A l’issue de la demande d’accès aléatoire, la transmission EDT étant finalisée, le mobile rester à l’état RRC_IDLE. Si d’autres données doivent être émises ou reçues, le terminal passe à l’état RRC_CONNECTED.

Dans ce cas, le premier paquet est transmis selon la procédure EDT, les autres paquets seront transmis de manière traditionnel.

La transmission PUR (Preconfigured Uplink Resource) consiste à pré-configurer les ressources du lien montant (UL) au cours d’une première connexion radioélectrique (RRC_CONNECTED). Cela signifie que la transmission PUR nécessite qu’en amont le terminal ait été dans l’état RRC_CONNECTED afin de recevoir la pré-configuration désirée.

La transmission PUR est utilisable par le terminal à l’état RRC_IDLE sans nécessité de procédure d’accès aléatoire mais en ayant conservé un contexte AS et l’allocation UL.

Ensuite, lorsque le mobile est en mode de veille, il peut utiliser les ressources qui lui sont réservées pour transmettre ses données sans avoir à mettre en œuvre la procédure d’accès aléatoire

Sur un cœur de réseau 5GC, la 3GPP propose un nouvel état radioélectrique du mobile nommé RRC_INACTIVE dédié aux terminaux IoT.

Le cœur de réseau 5GC pouvant être connecté à l’interface radioélectrique 4G E-UTRA et 5G-NR, l’état RRC_INACTVE s’appliquera à l’UE sur chacune des interfaces.

La transmission SDT (Small Data Transmission) est une procédure permettant de transmettre des petites quantités de données entre un terminal UE et le cœur de réseau 5GC en passant soit par l’accès radioélectrique 4G E-UTRA ou l’accès radioélectrique 5G-NR lorsque le terminal UE reste à l’état RRC_INACTIVE. La transmission SDT peut se faire sur l’interface E-UTRA comme sur l’interface 5G-NR.

La transmission non SDT correspond à la transmission traditionnelle de données entre un UE et le cœur de réseau 5GC via l’établissement de bearers lorsque l’UE est à l’état RRC_CONNECTED.

La transmission SDT sur l’interface 5G-NR a été introduite dans la spécification R.16 sous le nom NR SDT. La spécification R.17 propose deux technologies nommées RA-SDT (RACH SDT) et CG-SDT (Configured Grant SDT) lorsque le mobile est à l’état RRC_INACTIVE.

Figure 4 : Les types de transmissions IoT sur les réseaux 4G et 5G

[1] 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