Archives du mot-clef RACH

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 - 656 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/

 

SDT – Small Data Transmission (3ème)

Posté le by - 873 vues
Répondre

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.

 

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

Posté le by - 2 592 vues
Répondre

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.

Etablissement de la connexion radio – Partie 2 : Les ressources et l’identifiant aléatoire

Posté le by - 2 317 vues
Répondre

Avant d’émettre sa demande d’accès aléatoire, le terminal doit récupérer un ensemble d’informations transmises par la station de base via le message SIB2 :

  • la configuration du PRACH (prach-ConfigIndex) ;
  • le jeu des préambules d’accès aléatoires disponibles (la racine q et les décalages de la séquence, se référer à la partie 1) ;
  • la fenêtre temporelle pour la réponse (ra-ResponseWindowsSize) ;
  • la puissance d’émission du préambule initial (preambleInitialRecievedTargetPower) ;
  • le facteur de rampe de puissance (powerRampingStep) ;
  • en cas de non réponse, le nombre maximum de préambules pouvant être émis (preambleTransMax) ;
  • le temporisateur de résolution de contention (mac-ContentionResolutionTimer)

Figure 1 : Extrait des informations du SIB2

A partir de :

  • l’information msg1-FrequencyStart, le terminal UE calcule la position fréquentielle de la localisation du canal PRACH ;
  • l’information msg1-FDM, le terminal connait le nombre d’occasion PRACH dans le domaine fréquentiel

A titre d’exemple :

Dans la bande FR2 :

Figure 2 : La configuration de l’accès aléatoire selon la table 38.211 v15.5-Table 6.3.3.2-4

Les numéros de slot de référence sont le 19 et le 29, nous allons maintenant calculer la position du slot du RACH à partir de la référence du slot 19 :

N°slot_RACH=Starting_symbol + Numero_occassion_PRACH*Durée_PRACH+Nbre_symboles_par_slot*numero_du_slot

Avec :

  • Starting_symbol est une valeur indiquée dans le tableau, la valeur est à 7
  • Numero_occassion_PRACH correspond aux occasions du RA. L’indice démarre à 0 jusqu’à Number_of_time_domain_occasion – 1. La valeur vaut 0
  • Nbre_symboles_par_slot est de 14
  • Numero_du_slot se calcule par la formule suivante :
    • Si SCS = {1,25 kHz, 5 kHz, 15 kHz, 60 kHz} alors Numero_du_slot=1
    • Si SCS = {30 kHz, 60 kHz} et
      • si le nombre de slot RACH par sous-trame =1 alors Numero_du_slot=1
      • sinon Numero_du_slot={0,1}

Dans notre exemple, le symbole sur lequel démarre le canal PRACH est à la position : 7+0*6+14*1=21 par rapport au slot 19. Il se situe donc à la position du symbole 7 du slot 20

Figure 3 : Exemple de transmission du PRACH (FR2, format A3)

Une fois le préambule sélectionné, le terminal UE détermine la prochaine occasion pour envoyer sa demande. La puissance d’émission est estimée à partir des paramètres reçus par le SIB2 et en augmentant la puissance à chaque retransmission.

La demande d’accès est contrôlée par la station de base en indiquant par le message SIB2 les occasions du canal PRACH dans le domaine temporel et fréquentiel.

Ressources Temporelles (prach-ConfigurationIndex)

La référence temporelle est la durée d’une trame, soit 10 ms. La transmission du canal PRACH au cours de la trame est définie par les paramètres suivants :

  • PRACH configuration period : Le numéro de trame SFN utilisé pour transmettre le canal PRACH est défini par la condition suivante : x mod SFN = y.
    • A titre d’exemple x=16, alors les occasions du canal PRACH sont espacées de 160 ms
    • Si x=16, y=1, alors les numéros de trames portant le canal PRACH sont définis par le numéro de trame SFN 1,17,33,49,…
  • SubFrame Number : Indique le ou les sous-trames dans la trames qui transportent le canal PRACH
  • Slots with PRACH : La référence est un espacement entre sous-porteuses (SCS) de 60 kHz, pour laquelle on a 4 slots par sous trames soit 40 slots par trame. Le nombre d’occasion est donc de 40 lorsque l’espacement entre sous-porteuses est de 60 kHz ou 40*2 slots pour un espacement entre porteuses de 120 kHz.

Ressources Fréquentielles

  • msg1-FrequencyStart : Indique la première ressource PRACH
  • msg1-FDM : Indique le nombre de ressources fréquentielles pour le PRACH (1,2, 4 ou 8)

A partir de ces valeurs, le numéro de la sous-trame et l’index de fréquence utilisé par le terminal pour transmettre sa demande d’accès aléatoire permet de calculer l’identifiant radio RA-RNTI :

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

  • s_id : Index du premier symbole OFDM (entre 0 et 13)
  • t_id : Index du premier slot dans la trame (entre 0 et 79)
  • f_id : Index dans le domaine fréquentiel (entre 0 et 7)
  • ul_carrier_id est égal à 1 si la demande est faite dans la bande SUL, 0 sinon

Cette valeur sera utilisée par l’entité gNB pour répondre au terminal : le terminal écoute le canal PDCCH émis par l’entité gNb et recherche la réponse pour laquelle le code détecteur d’erreur CRC est mélangée par l’identifiant RA_RNTI (ou exclusif).

En fin de transmission, le terminal UE écoute (sur une durée définie) la réponse de l’entité gNB laquelle contient le numéro de référence RA-RNTI.

Références

3GPP 38.211

https://www.sharetechnote.com/html/5G/5G_RACH.html