L’accès aléatoire dans le contexte NTN

Procédure d’accès aléatoire dans un scénario non terrestre – NTN

Lorsque le mobile est à l’état de veille, il sélectionne la station de base et écoute les informations émises par celle-ci. Pour pouvoir émettre des données vers la station de base, l’UE doit être connecté à celle-ci.  La procédure d’accès aléatoire est déclenchée par l’UE pour demander cette connexion radio à la station de base que l’UE a sélectionnée. Si la station de base accepte la connexion radio, l’UE pourra échanger du trafic ou de la signalisation avec le cœur de réseau.

Suite à la procédure d’accès aléatoire, le mobile passe de l’état RRC_IDLE (4G/5G)-  ou éventuellement de l’état RRC_INACTIVE (5G) – à l’état RRC_CONNECTED. Au cours de cette procédure, la station de base estime la distance la séparant de l’UE et transmet à l’UE la valeur de Timing Advance (TA) estimée. Le TA est nécessaire pour synchroniser en temps le lien montant (Uplink Time Synchronization) reçue par la station de base avec le début de trame émise par la station de base.

Figure 1 : Synchronisation en temps du lien UL/DL au niveau du gNB [1]

Si le mobile est déjà à l’état RRC_CONNECTED, la procédure RACH est déclenchée lors de la demande de HandOver ce qui permet d’informer la station de base cible de la demande d’accès radio de l’UE.

Dans le cas d’un lien radio coupé (RLF : Radio Link Failure) ou d’un échec de HO, l’UE déclenche la procédure d’accès aléatoire dans le but de créer une nouvelle connexion radio avec la cellule (Cell Recovery).

Pour résumer les différents cas possibles, la figure 2 liste les situations pour lesquelles l’UE déclenche la procédure d’accès aléatoire.

Figure 2 : Situation ou la procédure de RA est déclenchée [2]

Concernant la procédure d’accès aléatoire, il existe deux méthodes d’accès:

  • CBRA : Contention Free Random Access. La procédure s’effectue soit en 4 messages, soit en 2 messages (exemple SDT : cf …). Dans le 1er message, l’UE choisi aléatoirement un préambule dans une liste d’au plus 64 préambules avec une probabilité non nulle qu’un autre UE choisi le même préambule, créant ainsi une collision au niveau de la station de base qui doit gérer la contention.
  • CFRA : Contention Free Random Access mise en oeuvre dans le cas du Handover. La demande s’effectue en 2 messages et le préambule utilisé par l’UE dans le 1er message appartient à une liste diffusée par la station de base cible dont les valeurs sont uniquement dédiées à l’UE. Ainsi, il n’y a pas de collision.

La demande d’accès aléatoire est émise par le mobile sur la fréquence commune et sur des sous-trames correspondant aux occasions de RA (RAO). La périodicité des occasions de RA est définie par les informations de broadcast SIB1 en 5G ou SIB2 en 4G. Ainsi, lorsque l’UE envoie sa demande dans la sous-trame correspondante, la station de base écoute les messages RA à cet instant et non en permanence. Cela suppose que la transmission UL du mobile soit synchronisée avec la transmission DL de la gNB et que le délai de propagation soit compensé par le TA.

Le mobile UE étant distant d’une distance d, il détecte le signal de synchronisation SSB avec un retard de d/c. Pour une cellule terrestre de 10 kms, le délai aller/retour (RTT : Round Trip Time) pour un UE à 10 kms de distance est de 67 µs (2*10 /300 000).

Dans le scénario NTN (figure 3), la distance entre l’UE et le satellite est de plusieurs 100aines ou milliers de kms, le délai (élevé) entre l’UE et la station de base provoque un décalage temporel entre le lien DL et UL (figure 2) et lorsque la station de base reçoit le préambule celui-ci est hors délai par rapport à la fenêtre d’écoute.

Figure 3 : Transmission Non Terrestre

On appelle interface Service Link ou SLI, l’interface du lien entre le satellite et l’utilisateur (UE/MES : Mobile Earth Station). L’interface SLI gère l’établissement des gestions de communication.

L’interface Feeder Link est l’interface entre le satellite et la passerelle terrestre (LES : Land Earth Station).

Dans la cas d’une communication satellitaire (figure 4 a), l’UE communique avec le satellite (délai UE – Satellite sur le lien de service) et le satellite transmet le signal vers la passerelle (délai Satellite – Passerelle). Dans le mode transparent, la passerelle est connectée à une station de base gNB.

Dans le mode regénérative payload (figure 4 b), le satellite héberge la station de base ou l’entité DU de la station de base. Ainsi, la passerelle est soit connectée au cœur de réseau (dans ce cas, le gNB est soit intégré dans le satellite), soit au gNB-CU.

Figure 4 : les modes de scénarios

Quel que soit le scénario choisi (transparente ou regénérative payload), la transmission a une latence élevée et supérieure à la durée d’un slot (cf. figure 5)

 

Figure 5 : Scénario de HO : a) Terrestre, b) Non Terrestre

Pour compenser le décalage, il est nécessaire de prendre en compte un TA étendu. Généralement, le TA est calculé par la station de base à partir de la demande d’accès aléatoire. Or la connaissance du  TA étendu est nécessaire pour la demande d’accès aléatoire. Le TA étendu est composé de deux valeurs :

  • Calcul du TA en boucle ouverte afin d’avoir une information du délai entre le satellite et fu point de référence (figure 6).
  • Calcul du TA en boucle fermés pour compenser l’erreur de TA qui est calculée en boucle ouverte

Figure 6 : Calcul du TA en boucle ouverte

Le calcul en boucle ouverte est réalisé au niveau de l’UE. Cela prend en compte le délai de l’interface du lien de service (UE/Satellite) et le délai sur l’interface du feeder (satellite vers la passerelle).

Concernant le lien du feeder, la station de base transmet le délai entre le satellite et un point de référence (RP : Reference Point). L’UE ne connait pas la localisation du RP. Le réseau transmet au mobile la valeur Tta_commun dans le message de diffusion SIB19 et qui correspond au temps du lien Feeder (entre le satellite et la passerelle).

Figure 7 : Exemple de RP

A partir de l’éphéméride du satellite (position et vitesse) émis dans le SIB19 et de la connaissance de la position de l’UE (issu de la mesure du GNSS), l’UE calcule la distance qui le sépare du satellite et donc estime le délai sur le lien de service (User Specific TA).

Le standard 5G a introduit un nouveau concept, demand SI Delivery, permettant à l’UE de déclencher la procédure d’accès aléatoire afin de demander à celle-ci la diffusion d’un message SIB

La nouveauté est la suivante (figures 8 et 9) :

  • En 4G, quand un UE souhaite acquérir une information diffusée par un SIB, il écoute le canal de diffusion à l’instant où le SIB est transmis (après avoir extrait les informations portées par le MIB et le SIB1)
  • En 5G, l’UE envoie une requête à la station de base en lui demandant d’émettre le SIB souhaité puis écoute la prochaine échéance (SI Window) du canal de diffusion.

Figure 8 : Demande de diffusion d’un SI

 

Figure 9 : Procédure On-Demand SI

Une fois l’offset de TA mesurée (d’une durée de plusieurs slots), le mobile pourra quasiment se synchroniser. Toutefois, une erreur en boucle fermée existe encore.

La procédure d’accès aléatoire permet de mesurer cette erreur.

La figure 10 présente ainsi le calcul du TA.

Figure 10 : La procédure de calcul du TA en boule ouverte

 

Références

[1] https://www.techplayon.com/5g-nr-timing-advance-rar-ta-and-mac-ce-ta/

[2] Oltjon Kodheli, Random Access Procedure Over Non-Terrestrial Networks: From Theory to Practice

 

 

La fonction BSF

Introduction

Le réseau 5G est un réseau natif Cloud. L’avantage est de permettre un déploiement rapide des fonctions réseaux et une mise à l’échelle pour des services dédiés (Network Slicing). La mise à l’échelle automatique (Horizontal Scaling) autorise la multiplication d’instances d’une fonction réseau pour répondre à la charge demandée.

La fonction BSF (Binding Support Function)  a été introduite dans l’architecture du réseau 5G (23.501 R.15) afin de maintenir l’association entre l’UE et une fonction PCF. Ainsi, si plusieurs fonctions PCF sont déployées par l’opérateur, la fonction BSF permet d’associer la fonction PCF qui gère la QoS d’une session PDU d’un UE. Dans le cas de la VoNR, pour un appel entrant, le réseau IMS (fonction AF) contacte le PCF, via l’interface N5/Rx, pour l’établissement d’un flux RTP pour le transport de la session. L’association au niveau du BSF permettra à l’AF de contacter le PCF correspondant à l’UE.

La fonction BSF va stocker l’identifiant du PCF et des informations concernant l’UE afin de pouvoir faire la correspondance entre l’UE et la fonction PCF.

Les informations stockées au niveau du BSF peuvent être :

  • @IP ou @MAC de l’UE
  • L’identifiant S-NSSAI
  • L’identifiant DNN
  • L’@ du PCF choisi (instance PCF)

Figure 1 : Contexte de la fonction BSF et interrogation de l’AF

 Chaque flux d’une session PDU est identifié par une valeur de flux QFI. Le flux est défini par le type de QoS (5QI), le type de bearer (GBR ou non GBR) et le débit (AMBR) qui sont gérés entièrement par la fonction SMF pour une session PDU traditionnelle (Accès Internet, une session SIP,…) ou négociés avec la fonction PCF.

SMF (Session Management Function) : Lorsque le SMF reçoit une demande de session PDU, il peut consulter une fonction PCF pour définir la politique de QoS. La fonction PCF interagit avec la fonction BSF car la fonction SMF ne communique pas directement avec la fonction BSF.

PCF (Policy Control Function) : Les fonctions BSF et PCF s’échangent des informations pour appliquer des politiques spécifiques à chaque session, telles que les règles de QoS et les autorisations d’accès.

La session demandée par la fonction AF doit être liée (Session Binding) à une seule session PDU. Ces informations d’association sont donc transmises à la fonction AF.

II) Les services de la fonction BSF

II-1) Gestion des informations de liaison (binding information)

Le BSF maintient et gère les informations de liaison entre les différentes entités de réseau et les sessions utilisateurs. Cela inclut l’association entre les identifiants des utilisateurs, les sessions actives, et les adresses IP utilisées.

Le BSF maintient une base de données des identifiants d’utilisateur et des contextes de session correspondants. Cela inclut des informations telles que :

  • L’identifiant unique de l’utilisateur (IMSI – International Mobile Subscriber Identity).
  • Les identifiants des sessions PDU actives.
  • Les adresses IP attribuées pour chaque session.
  • Les paramètres de qualité de service (QoS) pour chaque session.

II2) Support de la mobilité et proxy

La fonction BSF a un rôle comparable aux routeurs DIAMETER DRA (Diameter Routing Agent) utilisés en 4G. La fonction BSF est mis en œuvre lorsque les réseaux 4G et 5G doivent coexister.

Le rôle de la fonction BSF est alors de définir le prochain nœud de destination du paquet à transporter.

III) Les services de la fonction BSF (TS 29.521)

La fonction BSF assure l’association entre une session PDU et une fonction PCF. La fonction BSF propose des services de gestion pour enregistrer les associations entre l’UE, la session PDU et le PCF et les fournir aux fonctions concernées.

La fonction BSF peut jouer le rôle de proxy DIAMETER ou de serveur de redirection. Dans le cas du Proxy BSF, il transmet une requête DIAMETER d’une entité source vers une entité cible.

Dans le cas d’un serveur de redirection, la fonction BSF traduit une requête DIAMETER en un message http2 et inversement.

La fonction BSF dialogue avec les entités suivantes :

  • PCF
  • NEF
  • AF

III-1) Service de Gestion

Le service de Gestion Service Management permet :

  • D’enregistrer/de désenregistrer ou de mettre à jour les informations d’associations pour un UE ou une session PDU
  • De faire une découverte de la fonction PCF pour une session PDU ou un UE
  • De souscrire, se désinscrire à des évènements et de transmettre des notifications

 

Le service Nbsf Management Register permet au PCF d’enregistrer les informations de liaison de session pour un UE au niveau de la fonction BSF. La fonction BSF conserve et fournit l’identité de l’utilisateur, le nom du réseau de données (DNN), les adresses UE et l’adresse PCF pour la session PDU. Ainsi, la fonction SMF déclenche un enregistrement du PCF vers le BSF lorsque le SMF demande le service de création d’un profil de QoS au PCF.

La fonction SMF envoie la requête d’enregistrement au BSF à la réception du message Npcf_SMFPolicyControl_Create requets émis par la fonction SMF.

Le déclencheur est donc le message Npcf_SMFPolicyControm_Create requet, émis par le SMF vers le PCF et ce dernier répond au SMF Npcf_SMFPolicyControl_Create Answer avec la valeur transmise par la fonction BSF au PCF.

Figure 2 : Procédure d’enregistrement

Lorsqu’une fonction AF ou NEF a besoin de communiquer avec une fonction PCF, alors cette fonction invoque le service de découverte pour obtenir l’adresse du PCF concerné

Figure 3: Procédure de découverte

 

III-2) Proxy BSF

Lorsque le BSF reçoit une requête d’un AF, il doit vérifier s’il a déjà sélectionné un PCF pour la session Rx ; s’il dispose d’un PCF déjà sélectionné pour la session Rx, il transmettra la demande au PCF correspondant. Si le BSF n’a pas de PCF déjà sélectionné, il doit sélectionner un PCF pour gérer la session Rx, puis envoyer la demande par proxy au PCF sélectionné.

La création de la liaison est réalisée lorsque la fonction AF démarre une procédure d’enregistrement.

Figure 4 : BSF en tant que proxy

  1. La requête DIAMETER Authorization Authentication Request (AAR) est transmise par la fonction AF vers la fonction BSF. Cette requête à pour objectif d’autoriser et d’authentifier une demande d’établissement d’une session entrante vers le terminal. En 4G, cette demande était transmise à la fonction PCRF via l’interface Rx.
  2. La fonction BSF sélectionne le PCF s’il est déjà défini, sinon la fonction BSF sélectionne un PCF et fait l’association du PCF avec l’AF (liaison ou Binding).
  3. La fonction BSF transmet la requête AAR au PCF cible avec la même valeur d’AVP Session-Id.
  4. Le PCF renvoie la réponse DIAMETER AAA au BSF.
  5. BSF transmet la réponse DIAMETER AAA à l’AF avec la même valeur d’AVP Session-Id.

 

III-2) Serveur de redirection BSF

La fonction BSF peut jouer le rôle d’un agent de redirection DIAMETER. Il doit être en mesure de récupérer les informations AVP pour récupérer l’identité de la fonction PCF.

L’AF contacte la fonction BSF lors de l’établissement de la session Rx pour récupérer l’adresse PCF. La fonction de redirection du BSF n’a pas besoin de maintenir des sessions DIAMETER pour transmettre les messages DIAMETER vers le PCF sous le format http2

Ce rôle de redirection permet la coexistence de la fonction BSF et des agents de routage DIAMETER (DRA).

Figure 5: BSF en tant que serveur de redirection

  1. La fonction applicative AF envoie un message DIAMETER AAR au DRA pour établir une nouvelle session de diamètre Rx.
  2. Lors de la réception de la demande à l’étape 1, si le DRA n’a aucune information de liaison stockée dérivée d’une session Gx en cours pour l’abonné, le DRA invoque l’opération de service Nbsf_Management_Discovery au BSF pour obtenir l’ID PCF sélectionné pour une certaine session PDU.
  3. Le BSF répond au DRA avec l’ID PCF.

REMARQUE 2 : Si le DRA n’a stocké aucune information de liaison dérivée d’une session Gx en cours pour un abonné, le DRA doit demander de nouvelles informations de liaison pour chaque établissement de session Rx, car les informations du BSF pourraient avoir changé par rapport à toute information de liaison précédente. » a demandé la DRA.

IV) Exemple avec la VoNR

Lorsqu’un utilisateur se connecte au réseau 5G et initie une session de données, le BSF enregistre les informations de liaison, telles que l’adresse IP assignée et les identifiants de session. Si l’utilisateur se déplace et se connecte à une nouvelle cellule, le BSF met à jour les informations de liaison et assure que la session de données est maintenue sans interruption, en coordonnant les actions avec le SMF et le UPF.

Voici un exemple pour la VoNR ou l’UE contacte le Proxy P-CSCF du réseau IMS pour une demande d’appel. Le PCF concerné doit être connu du P-CSCF. Si le réseau IMS est déployé comme une architecture SBA et peut demander des services en utilisant le protocole HTTP2 alors voici la procédure attendue (Figure : ).

Dans le cas d’une coexistence DIAMETER/Http2, on imagine les rôles de la fonction BSF.

Figure 6 : Exemple de la VoNR

Réferences

23.501 : System architecture for the 5G System (5GS) – (3GPP TS 23.501 version 17.5.0 Release 17)

23.503 : Policy and charging control framework for the 5G System (5GS);
Stage 2 (3GPP TS 23.503 version 16.5.0 Release 16)

29.513 : 5G System; Policy and Charging Control signalling flows and QoS parameter mapping; Stage 3, R.16 – V16.6