SDT – Small Data Transmission (2ème)

Procédure d’accès aléatoire

La procédure d’accès aléatoire a pour objectif d’informer la station de base que le mobile souhaite être contrôlée par la station de base. Le mobile UE établit une procédure d’accès aléatoire dans les cas suivants :

  • Lorsque le mobile UE s’allume (ou en sortant du mode avion) ;
  • Lorsque le mobile UE met à jour sa localisation ;
  • Lorsque le mobile UE souhaite l’établissement d’une session PDU ou d’une connectivité PDN ;
  • En cas de H.O (procédure d’accès aléatoire sans contention).

Nous allons limiter notre étude au cas où le mobile souhaite l’établissement d’une connectivité PDN.

Figure 4 : La procédure d’accès aléatoire

Le message 1 émit par le mobile est transmis avec une puissance initiale P1 estimée à partir du signal de synchronisation reçu (mesure RSRP). En cas de non réponse, le mobile incrémente sa puissance d’émission. Le mobile transmet le préambule et l’identifiant de 16 bits RA-RNTI, lequel est calculé de la manière suivante :

Dans le cas du NB-IoT, les sous-porteuses sont espacées de 3,75 kHz ce qui permet d’avoir 48 sous-porteuses dans une RB de 180 kHz. Afin de réduire les risques de collision, le préambule est transmis sur 4 sous porteuses choisies pseudo-aléatoirement parmi 12 sous-porteuses consécutives via un motif de Frequency Hopping.

La station de base scrute dans les sous-trames correspondantes (cf. Table 3) la réception de préambules. En cas de détection d’un préambule, la station de base émet un message RAR Random Access Response dans le canal physique PDSCH en indiquant la présence du message RAR par une information de contrôle DCI_1 émise dans le canal PDCCH. L’information DCI_1 portée par le canal PDCCH est embrouillée par l’identifiant RA-RNTI. Le mobile UE attend la réponse de la station de base dans une fenêtre temporelle. La durée de la fenêtre temporelle n’est pas définie dans la norme mais est diffusée dans le message SIB via le paramètre rar-WindowLength IE.

Le RAR contient :

  • La valeur du préambule (RAPID : Random Access Preamble Id)
  • Le paramètre de Timing Advanced.
  • Les informations d’ordonnancement permettant d’indiquer au mobile UE les ressources radioélectriques que ce dernier devra utiliser pour l’émission du message subséquent ainsi que le schéma de modulation MCS.
  • L’allocation de ressource (UL Grant) pour la réponse du mobile vers la station de base
  • L’identifiant radioélectrique temporaire T-RNTI

Le mobile UE conserve la valeur T-RNTI et transmet son message 3 RRC Connection Request au niveau des ressources tempo-fréquentielles indiquées par la station de base dans le message 2 (UL Grant/RB Assignment). Le message est court (80 octets) et contient l’identité du mobile (TMSI ou une valeur aléatoire). L’identité radioélectrique T-RNTI transmis dans le message précédent est utilisé pour embrouiller le CRC du signal PUSCH montant.

Le message 4 (RRC Connection Setup) est utilisé pour lever la contention. En effet, si 2 mobiles UE ont transmis dans l’étape 3 son identifiant TMSI ou une valeur aléatoire (en estimant de droit que le message 2 lui était destiné), la station de base transmet l’allocation de ressource pour les échanges suivants à un mobile défini par son identifiant, c’est-à-dire la valeur TMSI ou la valeur aléatoire transmis dans le message 3. Le T-RNTI échangé dans le message 3 devient le C-RNTI à moins que l’UE disposait déjà d’un C-RNTI.

Le dernier message RRC Connection Setup Complete permet au mobile de valider le passage en mode connecté. Le message contient l’identité du PLMN sélectionné et un message NAS à destination du cœur de réseau.

La figure 7 présente le diagramme de machine d’état au niveau du mobile UE (figure 7a) et de la station de base (figure 7b).

Figure 5 : Le diagramme de machine d’état mobile UE (a) et station de base (b)

Les messages transmis portent les informations suivantes :

Figure 8 : L’échange de messages pour la procédure RAR

Figure 9 : Message 2 de la procédure d’accès aléatoire

La suite est récupérée sur Sharetechnote :

 

  • MAC Subheaders
    • E: The Extension field is a flag indicating if the MAC subPDU including this MAC subheader is the last MACsubPDU or not in the MAC PDU.
      • E field is set to “1” to indicate at least another MAC subPDU follows
      • E field is set to “0” to indicate that the MAC subPDU including this MAC subheader is the last MAC subPDU in the MAC PDU
    • T: The Type field is a flag indicating whether the MAC subheader contains a Random Access Preamble ID or a Backoff Indicator.
      • The T field is set to “0” to indicate the presence of a Backoff Indicator field in the subheader (BI)
      • The T field is set to “1” to indicate the presence of a Random Access Preamble ID field in the subheader (RAPID)
    • R: Reserved bit, set to “0”
    • BI: The Backoff Indicator field identifies the overload condition in the cell and its size is 4 bits to represent 16 possible index. Index value and corresponding Backoff time value is shown in below table

    • RAPID: The Random Access Preamble IDentifier field identifies the transmitted Random Access Preamble. The size of the RAPID field is 6 bits. If the RAPID in the MAC subheader of a MAC subPDU
      corresponds to one of the Random Access Preambles configured for SI request, MAC RAR is not included in the MAC subPDU.
  • MAC RAR Payload
    • R: Reserved bit, set to “0”;
    • Timing Advance Command: The Timing Advance Command field indicates the index value TA used to control the amount of timing adjustment that the MAC entity has to apply in TS 38.213 [6]. The size of the Timing Advance Command field is 12 bits
    • UL Grant: The Uplink Grant field indicates the resources to be used on the uplink i.e. Msg3. The size of the UL Grant field is 27 bits and content of UL grant is shown in below.

      • Frequency Hopping Flag
        • If the value of the frequency hopping flag is 0, the UE transmits the PUSCH without frequency hopping; otherwise, the UE transmits the PUSCH with frequency hopping.
      • MCS: The UE determines the MCS of the PUSCH transmission from the first sixteen indexes of the applicable MCS index table for PUSCH as described in 3GPP specification 38.214
      • TPC:The TPC command value is used for setting the power of the PUSCH transmission, and  is interpreted according to below table.
          • CSI request: This field a is reserved.
        •  Temporary C-RNTI: The Temporary C-RNTI field indicates the temporary identity that is used by the MAC entity during Random Access. The size of the Temporary C-RNTI field is 16 bits.

 

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 – Partie 3 : La procédure

Nous allons maintenant étudier la procédure d’accès aléatoire.

Lorsque le terminal UE est en veille, il récupère les paramètres d’accès radio transmis par la station de base à travers les différents SIB. Les informations SIB sont diffusées dans la cellule sur des canaux communs. Notamment, le terminal UE prend connaissance du SIB2 mais aucune ressource radio spécifique lui est dédiée.

Pour obtenir des ressources dédiées le terminal utilise dans un premier temps des ressources communes à l’ensemble des terminaux pour contacter l’entité radio (nous traitons le cas en 5G avec l’entité gNb mais la procédure est identique pour les autres accès radio mobiles) et l’informer de sa demande. Les ressources PRACH étant accessibles à l’ensemble des terminaux, la procédure d’accès aléatoire doit être en mesure de détecter un conflit en cas de collision.

Pour limiter les collisions, la station de base propose un ensemble de préambules (64 maximum). Le terminal tire au hasard un préambule parmi la liste proposée (on parle d’accès aléatoire). Le préambule est une séquence de Zadoff-Chu définit par son index RAPID (Random Access Preamble ID, l’index fait une correspondance avec la racine de la séquence, se référer au premier article décrivant l’accès aléatoire).

Cependant, rien n’exclut l’hypothèse que deux terminaux UE choisissent séparément le même préambule au même moment et transmettent chacun leur demande sur des ressources fréquentielles identiques. On parle alors de collision.

La procédure est décrite par les échanges suivants :

msg1 : Le terminal UE envoie sa demande d’accès aléatoire en transmettant un préambule. Une fois le préambule émis, le terminal UE écoute la réponse de la station de base entre l’instant t1 et t2= t1+ Fenêtre_reception (T300)

msg2 : La station de base répond au terminal mobile UE en indiquant l’avance de temps (TA) que le terminal UE doit appliquer, et lui alloue des ressources radios pour le prochain message montant. La réponse est diffusée sur le canal commun à l’ensemble des terminaux via le canal PDCCH. Le CRC du message DCI est embrouillé par l’identifiant RA-RNTI. Lorsque le terminal UE décode le PDCCH avec son identifiant RA-RNTI, il lit le contenu diffusé dans le canal PDSCH.

msg3 : Le terminal UE envoie une unité de donnée MAC ou un message RRC avec une identité UE. Cet identifiant va permettre de résoudre les conflits.

msg 4 : La station de base gNB diffuse sa réponse en indiquant l’identité reçu du terminal dans sa reponse. Ainsi, en cas de conflit, le terminal pour lequel la réponse du gNb correspond à son identifiant a réussi son accès aléatoire, pour les autres la réponse msg4 est attendu jusqu’à l’expiration du temporisateur. Une nouvelle demande d’accès sera alors renouvelée dans la limite des demandes autorisées dans le message SIB2.

Figure 1 : Procédure d’accès aléatoire

Le terminal UE émet ses messages et attend les réponses dans des fenêtres temporelles définies par l’accès radio.

Figure 2 : Les temporisateurs de la demande d’accès

L’objectif est maintenant de comprendre :

  • comment la station de base est en mesure de détecter plusieurs requêtes d’accès aléatoire ;
  • comment s’effectue la résolution de conflit.

Nous partons sur l’hypothèse de 3 terminaux UE A, UE B et UE C qui envoient leur demande d’accès aléatoire au même moment et sur les mêmes ressources tempo-fréquentielles. Dans ce cas l’identifiant RA-RNTI pour chaque terminal est identique. On suppose de plus que les terminaux UE A et UE B choisissent le même préambule. Dans ce cas , il y a collision.

Figure 3 : Demande d’accès UE vers gNB

Les préambules 1 et 3 sont différents, cela signifie que les séquences de Zadoff-Chu transmises par les terminaux A et C (ou B et C) ne sont pas identiques. Comme les séquences sont orthogonales, l’entité gNB est capable de les détecter. Par contre, les séquences émises par les terminaux UE A et UE B sont identiques, la station de base ne détecte donc qu’un seul message (pensant qu’il s’agit de multi-trajets).

La station de base répond aux 3 terminaux simultanément. Les terminaux sont informés d’une réponse en décodant l’information DCI dans le canal PDCCH. Les terminaux vont ensuite lire le message RAR (Random Access Response) présent dans le canal PDSCH. Le contenu du message contient les préambules décodés par la station de base gNB :

Figure 4 : La réponse du gNB vers les terminaux (message RAR)

Les terminaux A et B enregistrent l’identifiant radio temporaire TC-RNTI1 avec le Timing Advanced mesurée par la station de base. Ce TA correspond évidemment à l’un des deux terminaux. Le terminal C enregistre sont identifiant temporaire C-RNTI3.

Pour lever la collision entre les terminaux A et B, chaque terminal envoie son message 3 (RRC SetupRequest) avec l’identifiant temporaire TC-RNTI1 et leur identifiant aléatoire comme identité de l’UE (UE-identity).

Figure 5 : Les terminaux acquittent le message reçu auprès de l’entité gNB

Dans l’exemple ci-dessus, la station de base gNB reçoit la réponse des terminaux A et B avec, pour chaque UE, une identité aléatoire UE-identity. Cette réponse permet à la station de base d’identifier le terminal A et le terminal B et de faire la correspondance avec l’identifiant radio temporaire TC-RNTI1. La station de base détecte ainsi la collision. Dans la procédure, la station de base répond au terminal qui envoie le msg 3 en premier et ignore les autres messages msg3 qui portent le même identifiant temporaire TC-RNTI1. Elle reçoit également le message du terminal C avec l’identifiant temporaire TC-RNTI3. Elle fait donc une correspondance entre l’identifiant radio temporaire TC-RNTI3 et le terminal C UE-identity. Il n’y a pas de conflit.

Dans le chronogramme, on suppose que le terminal A est plus proche de la station de base gNb que le terminal B. Ainsi, la station de base reçoit d’abord le message 3 du terminal A et diffuse vers tous les terminaux un message de contrôle PDCCH DCI. Le contenu du message msg4 est transmis dans le canal PDSCH RRC_Setup avec la correspondance entre l’identifiant temporaire TC-RNTI1 et l’identité aléatoire UE-identity_A. La station de base diffuse le message qui est donc reçue par le terminal A et le terminal B. Le terminal A retrouve ainsi son identité temporaire UE-identity A dans le message de la station de base, les terminaux B et C reçoivent une réponse avec l’identité temporaire d’un autre terminal UE-identity A. Le terminal B attend la réponse du gNb (qui n’arrivera pas) jusqu’à la fin du temporisateur T300, le terminal C attend la réponse du gNB qui est transmise avant la fin du temporisateur T300.

Le message RRC_Setup permet également au terminal concerné de récupérer les informations de séquencement (attribution des ressources radio) pour la voie montante.

Les terminaux A et C vont donc pouvoir transmettre à la station de base la raison de leur demande d’accès (message NAS à destination de l’entité AMF), en encapsulant le message NAS dans la requête RRC Setup Request Complete.

Le terminal B va refaire une procédure d’accès aléatoire.

Figure 6 : Signalisation montante pour les terminaux A et C, procédure aléatoire pour l’UE B