Archives pour la catégorie Technique

L’interface DECT-2020 NR

Posté le by - 1 199 vues
Répondre

I) Les applications visées par le DECT-2020-NR 

L’interface radio 5G NR+ ou DECT-2020 NR utilise les principes du DECT ULE et s’intègre avec le cœur de réseau 5G. La 5G NR+ est donc une évolution de la 5G radio non cellulaire. L’objectif de cette nouvelle interface est d’apporter une autre solution que la 5G licenciée pour les applications suivantes :

  • DECT
  • Audio Professionnels (spectacles, évènementiels) – figure 1
  • IoT – Smartgrid et Compteur intelligent
  • BIM (batiment)

Figure 1 : Applications pour l’audio professionnels

La technologie DECT NR+ est conçue pour les applications de type mMTC et URLLC.

Le DECT-2020-NR s’appuie sur la modulation OFDM avec un préfixe cyclique (CP-OFDM). Le partage d’accès se fait en TDMA/FDMA dans un duplexage en temps (TDD).

A l’instar de l’interface 5G –NR, la trame est de 10 ms et l’espacement entre sous porteuses OFDM est définie selon une numérologie de 0, 1, 2, 4 et 8. Pour être compatible avec le DECT, la durée d’un slot est de 0,41677 ms. L’espacement entre sous porteuses pour la numérologie 1 est de 27 kHz.

II) Les topologies réseaux : Simple cellule, multi-cellules et MESH

Les terminaux radios peuvent communiquer en point à point ou en point à multipoints.

On définit deux modes opérationnels de connexions :

  • Le mode de connexion fixe FT (Fixed Termination Point) pour lequel le dispositif radio (RD) initie l’allocation des ressources radios locales et transmet les informations (voie balise) aux autres dispositifs radio à l’écoute de la balise. Le dispositif radio en mode FT prendrai une partie des fonctions de la station de base en 5G
  • Le mode de connexion PT (Portable Termination Point) permet à un dispositif radio de s’associer avec un autre RD qui fonctionne en mode FT

Un dispositif radio peut fonctionner en mode PT uniquement, FT uniquement ou dans les deux modes.

Une topologie réseau implique par conséquent des RD qui fonctionnent en mode FT et en mode PT.  Le type de réseau peut être de topologie à une seule station de base (un seul RD en mode FT) ou à plusieurs stations de base (plusieurs RD en mode FT)

Chaque RD apporte une couverture radio sur sa zone de couverture et peuvent se déplacement d’une aire de couverture vers une autre aire.

La topologie MESH est également supportée pour les applications mMTC. En effet, un RD pouvant fonctionner dans les deux modes FT et PT devient un nœud intermédiaire. Ce nœud apportant une latence plus importante, cette topologie n’est pas adaptée pour les services URLLC. L’intérêt principal est la réduction de la consommation énergétique sur le lien global (entre le dispositif émettant et le dispositif récepteur).

Le routage de la topologie MESH est basée sur une optimisation du cout (minimum de saut) tout en maintenant une connectivité entre les nœuds. La décision de routage est distribuée au niveau de chaque RD à partir des ressources radio.

III) Le routage MESH

Un réseau maillé DECT-NR est un réseau dans lequel les dispositifs radios sont connectés de telle sorte qu’au moins certains, et parfois tous, aient des chemins multiples vers d’autres nœuds. Les connexions multiples augmentent la résilience du réseau.

La topologie MESH nécessite donc un routage dynamique au niveau de chaque nœud afin de définir le prochain nœud. La création d’un cluster suit les étapes suivantes :

  • Définition des RD qui ont un accès à Internet : RD en mode FT émet cette information sur une fréquence balise. Cela permet aux autres RD de s’associer à ce dernier pour un accès extérieur. L’information balise contient de plus l’allocation des ressources radios
  • Chaque RD évalue la connexion radio en fonction de la puissance de réception de la voie balise (RSRI) et chaque RD décide s’il est RD FT ou RD FT et PT avec ses voisins.

Figure 2 : Mise en place du réseau MESH [1]

Dans le cas ou un RD détecte plusieurs voies balises dont le niveau de RSSI est suffisant pour une communication bidirectionnelle, le RD définit chaque RD comme prochain nœud potentiel et choisit le RD en fonction du critère de cout de routage. Ce critère est laissé libre à l’équipementier mais peut dépendre d’une réduction du nombre de nœud, du maximum de la capacité, ou du minimum d’erreurs paquets, ou de l’énergie disponible pour le prochain nœud.

A l’issu de la procédure d’association, chaque RD est en mesure de transmettre vers le prochain nœud, chaque nœud étant identifié par une adresse RD ID de 32 bits.

IV) La couche radio

La trame radio a une durée de 10 ms découpée en slot de 0,41677 ms. Chaque slot contient 10 ou 20 ou 40 ou 80 symboles.

La couche radio utilise la modulation OFDM avec un espacement entre sous porteuses (SCS) de 27 kHz (µ=1), 54 kHz (µ=2), 108 kHz (µ=4) ou 216 kHz (µ=16).

  • Pour µ=1, la trame est composée de 10 slots.
  • Pour µ=2, la trame est composée de 20 slots.

La largeur de bande dépend du facteur β et vaut 64* β*SCS. β prend pour valeur 1, 2 , 4, 8, 12 et 16

  • Si µ=1 et β =1, on utilise une IFFT de tailles 64 soit 1728 MHz. La fréquence d’échantillonnage est de 1/1728 ms soit 5,787 10-7s
  • Si µ=2 et β =1, on utilise une IFFT de tailles 64 soit 3456 MHz. La fréquence d’échantillonnage est de 1/3456 ms soit 2,893 10-7s
  • Si µ=1 et β =2, on utilise une IFFT de tailles 128 soit 3456 MHz. La fréquence d’échantillonnage est de 1/3456 ms soit 2,893 10-7s

 

La fréquence porteuse est définie dans une bande comprise entre 450 MHz et 5875 MHz.

La couche physique réalise les fonctions suivantes :

  • Détection d’erreurs CRC
  • Codage canal par un Turbo code
  • Algorithme HARQ
  • Adaptation de débit
  • Correspondance des canaux physique sur le canal radio
  • Modulation / démodulation (BPSK, QPSK, 16-QAM, 64-QAM, 256-QAM et 1024-QAM)
  • Mesures radios
  • Diversité de transmission MISO/SIMO/MIMO

IV) Le cœur de réseau

L’interface DECT-2020-NR est une interface radio non cellulaire. Comme les points d’accès WiFi, le RD FT est connecté au cœur de réseau 5G via la fonction N3IWF.

Figure 3 : Interconnexion avec le cœur de réseau 5G

Le dispositif radio RD PT et la station de base RD FT contiennent respectivement le stack 5G NAS et NGAP afin de pouvoir communiquer avec la fonction AMF.

Références :

[1] TS 103.636-1, V1.3.1, DECT-2020 New Radio Part 1: Overview https://www.etsi.org/deliver/etsi_ts/103600_103699/10363601/01.03.01_60/ts_10363601v010301p.pdf

La 5G Privative – NPN Non Public Network

Posté le by - 1 506 vues
6

I – Introduction

L’article « Déploement de la 5GC » avait pour objectif de présenter le déploiement du cœur de réseau. Il existe aujourd’hui plusieurs solutions Open Source pour tester le cœur de réseau, je présenterai les solutions Free5GC, Open5GS et OAI dans un autre article

Le cœur de réseau 5G peut être déployé pour l’usage d’une organisation, d’une entreprise, d’un ministère, d’une université, d’un hôpital … (cf. Campus 5G) pour des besoins tels que :

  • une haute exigence en QoE (très haut débit, et latence très faible),
  • une sécurité pouvant se baser sur les outils de la blockchain notamment pour la sécurisation des objets connectés et le déploiement décentralisé de la 5G et des serveurs d’applications (MEC) ,
  • une délégation de la responsabilité des performances du réseau (fiabilité, maintenance, débits, QoS, …).

Le principal attrait de la 5G privative est sa capacité à connecter le terminal à un serveur en périphérique (Datacenter MEC) pour des applications URLLC (protocole 5G TSN Time Sensitive Network), d’apporter une connectivité LAN (5GLAN) et de connecter plusieurs terminaux IoT pour des applications industrielles (IIoT).

La connectivité 5G LAN permet de plus d’interconnecter des sites distants via un modèle de déploiement hybride privée/publique.

II – Le réseau NPN pour quelles applications?

Sans être exhaustif, les marchés verticaux sont :

  • Hôpital : Des salles d’opérations équipées de systèmes d’imagerie avancées (rayons X sur arceau C-arm X ray), des tomodensodimètres CT (Computed Tomography), scanners à résonnances magnétiques MRI (magnetic resonance imaging), des caméras endoscopiques à hautes résolutions (8 k) supportant une haute résolution en couleur (10 bits par canal – HDR High Dynamic Range) et un nombre d’images par seconde élevée (120 images par seconde HFR High Frame Rate), des scanners. Couplé à l’IA (MEC), la connectivité 5G permet aux chirurgiens d’avoir des informations en temps réel avec des dispositifs médicaux comme le laparoscope.
  • Le Smart-Grid pour la régulation du réseau électrique en temps réel (cf. article CPS)
  • Application Professionnelle Audio et Video VIAPA (video, imaging and audio for professional applications) [1]. La production audiovisuelle comprend des studios de télévision et de radio, des reportages en direct, des événements sportifs, des festivals de musique, …

Tableau 1 : Les performances attendues pour les applications de productions audiovisuelles

  • IIoT : L’entreprise 4.0 et l’entreprise 5.0 (cf. vidéo : https://youtu.be/-oAgHpzm_FU)
    • Coopération Humains/Machine – robot collaboratif COBOT (URLLC)
    • Contrôle de machine à distance (URLLC)
    • Jumeaux Numériques (eMBB)
    • AR/VR (réparations ou transfert de compétences) (eMBB)
    • Maintenace prédictive d’une chaîne de production (mMTC)

Figure 1 : L’entreprise 5.0 [2] (avec l’accord de Justyna Matuszak)

III – Les modèles de déploiement de la 5G privative [6]

Différents modèles 5G privative (NPN – Non Public Network) ont été standardisées  dans la R.16 de la 3GPP :

  • le modèle SNPN (Standalone NPN) entièrement déployé chez le client (premises) ou cloud native si le client dispose de plusieurs sites.
  • un modèle hybride publique/privée (Public Network Integrated PNI/PNP) permettant au client de louer une partie de l’infrastructure de l’opérateur. Afin de répondre au besoin du client, l’opérateur vend soit une tranche de réseau (Slice PLMN) via un accord de service SLA (Service Level Agreement) soit propose un réseau dédié DNN, soit propose une mutualisation de la station de base avec un accès restreint par groupe (CAG : Closed Access Group).

3-1) Modèle SPNP

Dans le cas du modèle SNPN, le plan de contrôle 5G CN, le plan utilisateur 5G UP sont chez le client (premise). La station de base gNB est également chez le client mais deux cas se présentent : soit la station de base est entièrement dédiée pour des communications privatives, soit la station de base permet également d’accéder au réseau PLMN via le RAN Sharing MOCN (cf. article précédent). Le spectre radio peut être une bande opérateur ou une bande PMR (3,7 – 3,8 GHz) dont le prix de vente par l’ARCEP a largement été réduit pour attirer les industrielles au déploiement de la 5G privée : A titre d’exemple, alors qu’un industriel souhaitant déployer un réseau privé sur une zone de 300 m² devait s’acquitter d’une redevance annuelle à hauteur de 70 992 € pour disposer d’une bande de 20 MHz, celle-ci sera désormais réduite à 592 € depuis le 1er janvier 2023 [3]. 

Le terminal UE sélectionne une station de base en fonction de l’identifiant opérateur PLMN-ID ou du réseau privé (MNC=999) et de l’identifiant du réseau privée NID. L’identifiant PLMN ID + NID identifie le réseau SNPN.

L’identifiant NID est choisi soit de manière unique, quelque soit le PLMN ID, soit défini par un PLMN de manière unique de façon à garantir l’unicité du PLMN ID + NID.

Le réseau SNPN est séparé du réseau opérateur PLMN. Depuis la R16, le terminal peut accéder aux services de l’opérateur HPLMN à condition de s’authentifier auprès de ce dernier.

Ce point étant optionnel, la R.17 étudie les possibilités de repli (FallBack) sur le réseau IMS de l’opérateur pour la prise en charge des appels d’urgences ainsi que l’intégration des systèmes d’alerte PWS (Public Warning System). Pour le raccordement du SPNP vers le réseau PLMN, la porte d’entrée du réseau PLMN est gérée par la fonction N3IWF.

Figure 2 : Modèle SNPN

3-2) Modèle PNI-NPN

L’architecture PNI/NPN nécessite :

  • des accords de raccordement (à l’instar des offres MVNO)
  • la description des performances que l’opérateur doit mettre en œuvre (Slice ou DNN)
  • ainsi que la définition de la part de responsabilité du réseau privé 5G et ses obligations [4].

Trois modèles de déploiement sont proposés dans la R.16.

a) Mutualisation du RAN

Le modèle PNI-NPN le plus courant se base sur la mutualisation de la station de base en passive Sharing ou MOCN (RAN SHARING, cf. article précédent).

L’accès radio est apporté par l’opérateur, le cœur du réseau est isolé dans l’entreprise.

Figure 3 : Modèle PNI-NPN avec mutualisation du RAN

b) Mutualisation du RAN et du plan de contrôle

L’utilisateur est client du PLMN, ce dernier propose une tranche de réseau (Network Slicing) pour router le trafic sur le plan de transport (UP Plane) dans l’entreprise. Cette solution présente l’avantage d’une communication sans coupure (mobilité transparente : seamless mobility) entre le plan de transport interne à l’entreprise (premise) et le plan de transport de l’opérateur.

Figure 4 : Modèle PNI-NPN avec mutualisation du RAN et du CN

c) Mutualisation du RAN et du plan de contrôle et de trafic

L’opérateur met à disposition du client une tranche de son réseau (slice). Le client paye un forfait chez l’opérateur, il peut donc accéder aux services de l’opérateur et aux services de son réseau privatif via un accord de roaming.

Si le terminal dispose de plusieurs cartes SIM (multi-SIM), des procédures de sélection de PLMN sont mises en œuvre. Dans le cas du DUAL IMSI SIM, l’utilisateur ne peut pas utiliser les 2 identités SIM simultanément mais commute d’une carte à une autre manuellement. Dans le cas du Dual SIM DUAL Standby (DSDS), l’UE est enregistré sur les deux réseaux mais un est en stand-by. Dans le cas d’une eSIM, le téléphone DSDS peut être connecté sur le réseau PNP et PLMN en même temps.

IV – La sélection de la station de base

Dans le cas du réseau SNPN, le terminal UE sélectionne une station de base en fonction de l’identifiant opérateur PLMN-ID et du NID (Network IDentifier). L’identifiant NID est introduit pour identifier, découvrir, sélectionner et contrôler l’accès au réseau SNPN.

Dans le cas du réseau PNI-PNP, l’UE sélectionne le réseau via le PLMN ID. Le contrôle d’accès est défini par l’identifiant de groupe CAG ID. Cet identifiant est utilisé pour identifier un groupe d’utilisateurs autorisés à ce connecter sur une gNB publique afin d’interdire les utilisateurs non autorisés à accéder à l’accès radio.

La R.17 introduit la fonction de Join Server (cf. LoRaWAN1.1 ou 1.04) nommé 5G SDM (Subscriber Data Management) : le client dispose d’un abonnement auprès d’un titulaire d’une accréditation CH Credential Holder, entité qui peut être un autre SPNP, un opérateur PLMN (UDM) ou une entité non 3GPP (AAA). Ainsi, le réseau de l’abonné (PLMN ou NPN) peut orienter la connexion de ses UE abonnés vers un PLMN ou NPN visité particulier (autre que celui abonné) et permettant au réseau abonné d’orienter la sélection du réseau en fonction de sa priorité (par ex. , arrangements commerciaux).

La R.18 va permettre de proposer de la mobilité entre différents eSPNP (evolved SPNP) ce qui permettra au mobile de sélectionner des stations de base d’un autre eSPNP que le sien à partir de de la diffusion d’information SIB.

V – La mise en sécurité

L’accès à la 5G privative ne nécessite pas la mise en sécurité via l’application USIM (même en passant par un accès radio 3GPP). En effet, l’identifiant SUPI correspond soit à l’identifiant IMSI pour accéder au réseau opérateur, soit à un identifiant réseau NAI (Network Access Identifier). Pour éviter l’usurpation d’identité (spoofing), cet identifiant peut être transmis en étant chiffré (SUCI) ou à travers un tunnel IPSEC.

Si l’application USIM n’est pas utilisée, l’authentification est réalisée via le protocole EAP sur TLS/TTLS et les clés de chiffrement/d’intégrité sont conservés au niveau du terminal (la carte UICC n’étant pas exploitée). Pour plus d’explications se référer au RFC 7542.

Si le mobile se connecte sur un réseau SPNP et souhaite profiter des services du réseau PLMN, alors il doit s’authentifier de manière classique au réseau PLMN. La connectivité avec le réseau PLMN est assuré par le plan de transport du réseau SPNP. Celui-ci est vue comme un réseau non 3GPP pour le réseau PLMN qui propose la fonction N3IWF comme porte d’entrée au réseau PLMN.

Dans le cas du SPNP avec de nombreux IoT, la blockchain peut être une solution pour authentifier et sécuriser les échanges.

VI – Les technologies 5GLAN, TSN et ATSSS

La fonction 5GLAN permet au mobile d’accéder à l’infrastructure IT de l’entreprise à l’instar d’une connexion Ethernet mais sans câble.

L’architecture 5G LAN permet d’avoir des performances de la 5G.

La technologie LAN 5G peut être appliquée pour connecter l’entreprise avec les terminaux mobiles et les terminaux fixes.

La technologie LAN 5G permet à un groupe spécifique d’utilisateurs de communiquer entre eux, ou à un utilisateur spécifique de communiquer avec les utilisateurs du réseau privé existant. Cela permet une gestion de groupe flexible, une communication directe et un accès au cloud d’entreprise à tout moment et n’importe où

La technologie TSN (Time Sensitive Network) permet de synchroniser le mobile à l’infrastructure IT de l’entreprise à travers un pont TSN.

Figure 5 : La fonction TSN AF [4]

ATSSS [7] est une fonctionnalité optionnelle qui peut être supportée par le terminal UE et le coeur de réseau afin de router le trafiv à travers un réseau 3GPP et non 3GPP .
La fonction ATSSS (access traffic steering, switching and splitting) permet l’utilisation simultanée du plan de transport NPN et PLMN à partir des informations fournies par la fonction SMF (éventuellement sous le contrôle du PCF). Les règles ATSSS permettent différentes gestion de trafic :

  • Traffic Steering  : sélectionne un réseau d’accès 3GPP ou non 3GPP pour un nouveau flux de données selon le mode de pilotage souhaité pour équilibrer ou prioriser la charge : veille active, plus petit délai, équilibrage de charge, redondance ou priorité.
  • Traffic Switching : déplace tous les flux de données en cours d’un réseau d’accès à un autre. Ça peut être utilisé assurer la continuité du trafic de données.
  • Traffic Splitting : répartit les flux de trafic de données sur les réseaux d’accès 3GPP et non 3GPP (exemple : agrégation de trafic).

Références

[1] TS 22.263 : 5G service requirements for VIAPA, R.17

[2] https://knowhow.distrelec.com/fr/industrie/votre-entreprise-est-elle-prete-pour-lindustrie-5-0/

[3] https://presse.economie.gouv.fr/download?id=105429&pn=498%20-%20R%C3%A9seaux%20priv%C3%A9s%204G-5G%20%C3%A0%20usages%20industriels,%20r%C3%A9duction%20des%20redevances-pdf

[4] TS 23.501 : System architecture for the 5G System (5GS) Release 18

[5] GSMA –  Private 5G Industrial Networks – https://www.gsma.com/iot/wp-content/uploads/2023/06/GSMA-Private-5G-Industrial-Networks-Report-June-2023.pdf

[6] https://www.linkedin.com/pulse/5g-non-public-network-dharmesh-yadav/

[7] TS 24.193 : Access Traffic Steering, Switching and Splitting (ATSSS)

La transmission PUR (IoT – EPC/5GS)

Posté le by - 482 vues
Répondre

Cet article présente une évolution du standard R.15 pour une transmission de données montante (UPLINK) dans le cas d’une transmission de type machine MTC et pour un terminal IoT 4G.

La transmission PUR s’effectue sur une interface 4G entre deux entités qui supportent cette transmission, c’est-à-dire soit entre un UE et une eNB ou une ng-eNB.

Le cœur de réseau peut être un cœur de réseau 4 (EPC) ou un cœur de réseau 5G (5GS).

Sur un cœur de réseau 4G, l’état RRC du mobile est soit en veille (RRC_IDLE), soit en mode connecté (RRC_CONNECTED). Pour la procédure de transmission PUR, l’état du mobile est obligatoire en veille (RRC_IDLE).

En mode de veille, le terminal écoute les informations émises par la station de base. Pour transmettre des données sur des ressources tempo-fréquentielles dédiées, le smartphone doit passer en mode connecté.

La procédure d’accès aléatoire permet de passer de l’état de veille à l’état connecté, ce qui nécessite un échange de 4 messages (dont 2 messages RRC) entre le mobile et la station de base.

La transmission PUR permet de réaliser une transmission UPLINK lorsque le terminal est à l’état RRC_IDLE sans avoir besoin de réaliser de procédure d’accès aléatoire puisque le terminal est pré-configuré pour une transmission montante, c’est à dire que le terminal dispose déjà des informations sur les ressources tempo-fréquentielles UPLINK à utiliser pour transmettre ses données à la station de base.

La configuration PUR est transmise par la station de base au terminal UE lorsque celui-ci en fait la demande et à l’état RRC_CONNECTED. Cela ne peut s’appliquer que dans la cellule ou la demande a été faite. La configuration est transmise sous condition de disposer des droits (information d’inscription ou de politique local).

Figure 1 : Pré-configuration du terminal par la station de base

Le terminal UE indique à la station de base qu’il souhaite obtenir une préconfiguration PUR par la requête PURConfigurationRequest. Cette requête demande les informations suivantes :

  • Nombre d’occurrences
  • Périodicité (par fenêtre temporelle de 10,24 secondes)
  • La taille du bloc de données TBS
  • Time offset (TA)

La station de base transmet la configuration PUR au mobile lors de la libération de la connexion radioélectrique afin que le mobile soit à l’état RRC_IDLE.

Le terminal peut transmettre ses données lors d’une occurrence configurée, la station de base étant en écoute de l’éventuel message émis par le terminal. La pré-configuration revient donc à réserver une ressource tempo-fréquentielle pour permettre au terminal d’émettre ses données sur un canal radio dédiée.  Afin d’éviter de conserver cette ressource sur une durée trop longue, un nombre d’occurrence et de périodicité définie la durée de validité de la transmission PUR

La transmission PUR est déclenchée quand les couches supérieures demande l’établissement ou la reprise de la connexion RRC. Une fois le paquet émis, la configuration PUR est supprimée. Le terminal ne pourra donc pas re-transmettre tant qu’il n’aura pas une autre pré-configuration.

En mode de veille, le terminal UE peut transmettre les données selon :

  • L’optimisation du plan de contrôle CIoT EPS/5GS Optimization via la requête RRCEarlyDataRequest (Figure 2);
    • La station de base peut à son tour transmettre des données via la requête RRCEarlyDataComplete sur les ressources tempo-fréquentielles proposées dans la configuration PUR. Par contre, si la taille des données est supérieure à la taille du TBS, le mobile enverra la requête RRCConnectionRequest à la place (fall back to the legacy RRC Connection establishment procedure, a new C-RNTI can be assigned)
    • S’il n’y a pas de données, la station de base acquitte la requête PUR par une réponse HARQ et éventuellement des informations de commandes TA (message DCI).
  • L’optimisation du plan de trafic CIoT EPS/5GS Optimization via la requête RRCConnectionResumeRequest (Figure 3)

Figure 2 : La transmission PUR avec l’optimisation du plan de contrôle

Figure 2 : La transmission PUR avec l’optimisation du plan de contrôleFigure 3 : La transmission PUR avec l’optimisation du plan de trafic

Le découpage des fonctions gNB : 3GPP et O-RAN

Posté le by - 1 349 vues
Répondre

Introduction

Au cours des 5 précédents articles, nous avons vu les sous-couches protocolaires mises en œuvre au niveau de la station de base gNB.

L’entité gNB a été présentée comme une entité monolithique, le standard 3GPP présente la pile protocolaire et les interfaces entre l’UE, la station de base et le cœur de réseau.

Afin d’apporter plus de souplesse, le standard 3GPP propose de découper l’entité gNB en deux unités : une unité distribuée DU (RLC, MAC et Radio) et une unité centralisée CU (RRC et SDAP/PDCP).

Ce découpage définit de nouvelles interfaces (F1) et de nouvelles liaisons (fronthaul, midhaul et backhaul [1]) comparativement au découpage RU et BBU en 4G LTE.

Figure 1: Le découpage d’une station de base eNB et d’une station de base gNB

II) L’architecture 3GPP

L’architecture du gNB est représentée sur la figure suivante [2]

Figure 2 : Architecture gNB (Rahim Navaei) [2]

On sépare le plan de contrôle (Control Plane) et le plan utilisateur (User Plane) (CUPS : Control User Plane Separation).

Au niveau du cœur de réseau, la 3GPP défini une architecture SA en introduisant les interfaces basées sur le service (SBI) et en utilisant le protocole http2 et des API. L’architecture SBA est Cloud-native.

Au niveau de l’accès radio, la décomposition du la BBU en CU et DU et l’évolution de l’eCPRI permet de faciliter le déploiement de la virtualisation de la partie radio (O-RAN).

Dans le plan de contrôle, la figure 2 fait apparaitre un nouveau protocole F1AP entre le gNB-CU et le gNB-DU et un nouveau protocole E1AP sur l’interface E1 entre le gNB-CU du plan de contrôle et le gNB-CU du plan utilisateur.

Les fonctions sur le plan de contrôle F1AP permettent de gérer l’interface (établissement, re-initialisation, achèvement de l’interface F1) et porte les messages de contrôle RRC pour la gestion du contexte utilisateur (via le message F1AP UE Context), la gestion des systèmes d’informations MIB/SIB, le paging et l’allocation d’un numéro de tunnel TEID pour le plan d’acheminement entre le gNB-CU UP et l’UPF.

Le plan d’acheminement est injecté à travers la fonction E1AP. Les fonctions E1AP permettent de gérer l’interface (établissement, re-initialisation, achèvement de l’interface E1) et de gérer le bearer (via le message E1AP Bearer Context).

A titre d’exemple, en cas de Handover, la reconfiguration radio est déclenchée par l’unité gNB-CU de la station de base source et implique une modification du contexte entre l’unité DU source et l’unité DU cible.

Figure 3 : Les messages en cas de HandOver

 

III) L’architecture O-RAN

L’alliance O-RAN (Open Radio Access Network) propose une décomposition des fonctionnalités de la station de base en micro-services.  La première étape consiste à découper le bloc monolithique de l’entité gNB en fonctions réseaux virtualisables et inter-opérables.

La solution Cloud-Native est adoptée et plusieurs options sont possibles quand à l’implémentation RAN en micro-services : conteneurs, K8s K3s ou VM.

Amazon propose les solutions ECS (Elastic Container Service), EKS (Elastic Kubernetes Services – EKS Distro ou EKS Anywhere) [3]

L’alliance O-RAN définie (figure 1) une architecture O-RAN composée de 9 fonctions réseaux et 19 interfaces. En se basant sur l’architecture 3GPP, l’alliance O-RAN vise à définir une architecture ouverte et interopérable.

Figure 4 : Architecture O-RAN [3]

Les interfaces E2 et O1 permettent d’améliorer la gestion de l’accès radioélectrique et d’automatiser le déploiement d’instances en se basant sur des outils d’optimisation et d’automatisation radio (avec l’utilisation de l’apprentissage Machine Learning et l’optimisation par l’IA).

Le découpage des fonctions O-CU, O-DU et O-RU est standardisé par l’alliance O-RAN. La 3GPP qui propose un découpage du gNB en deux unités DU et CU est représenté par l’option 2 du standard O-RAN.

Figure 5 : Le découpage en fonction de l’architecture O-RAN [4]

L’architecture O-RAN comprend 3 niveau (three tiers) :

L’infrastructure O-Cloud contient les serveurs physiques et les fonctions réseaux.

L’orchestrateur SMO (Service Management and Orchestration Framework) fournit les services de gestion des instances, en apportant les fonctionnalités pour la gestion des slices, la gestion des services de transports de données. Le SMO peut être la plateforme ONAP (Open Network Automation Platform).

Le contrôleur RIC (non-real time and near-real time RIC) a pour objectif d’optimiser les fonctions réseaux RAN pour la gestion de la mobilité des utilisateurs (non real time RIC), le contrôle de l’admission radioélectrique (non real time RIC) et la gestion des interférences (near-real time RIC. Le contrôleur utilise les outils ML/IA pour prédire et optimiser la gestion de l’accès radioélectrique et a pour objectif de contrôler les unités O-DU et O-CU pour la gestion de la QoS.

 

[1] TS 38.401

[2] Rahim Navaei :  https://www.linkedin.com/feed/update/urn:li:activity:7018462941226098688/

[3] https://docs.aws.amazon.com/whitepapers/latest/open-radio-access-network-architecture-on-aws/open-radio-access-network-architecture-on-aws.html

[4] TR 38.801

Evolution de la pile protocolaire LTE vers NR (5/5)

Posté le by - 727 vues
Répondre

La couche SDAP (Service Data Adaptation Protocol)

La couche SDAP a pour rôle de définir la qualité de service à mettre en œuvre pour chaque support de données radios DRB (Data Radio Bearer).

La couche SDAP fait la correspondance entre la QoS de chaque flux d’une session PDU (session de données entre la station de base et le cœur de réseau) et la gestion de la QoS au niveau du DRB. Une entité SDAP gère autant de DRB qu’il y a de QoS différentes au niveau de la session PDU.

Deux sessions PDU différentes sont gérées par deux entités SDAP et même si deux flux de chaque session ont la même QoS, la station de base gère deux DRB différents, un par entité SDAP.

La QoS du flux est identifiée par l’identifiant QFI (QoS Flow Identifier) de 6 bits, ce qui limite à 64 QFI par session PDU.

Figure 1 : La gestion de la QoS et le gabarit de filtres (TFT) [1]

On parle de QoS réflective lorsque la couche SDAP rajoute l’identifiant QFI sur le lien montant. Ceci permet d’appliquer la même QoS au niveau du cœur de réseau pour le flux montant que la QoS appliquée au niveau du flux descendant. Mais, l’entité SDAP peut être configurée en mode transparent, l’absence d’en-tête SDAP ne permet plus d’ajouter l’identifiant QFI. Cela correspond au DRB UL par défaut.

La configuration du DRB est réalisée par un message RRC, la QoS est soit indiquée dans la configuration du message ou récupérée au niveau de l’identifiant QFI du paquet descendant (QoS réflective). Pour que la couche SDAP de l’UE puisse mettre en oeuvre la QoS réflective, la station de base positionne le bit RDI (Reflective QoS Flow ti DRB mapping Indication) à 1 [2]. Quand le bit RDI=1, l’UE met à jour la table de correspondance QFI -> DRB pour le lien montant.

L’identifiant QFI est standardisé et correspond à un profil de QoS. Au niveau de la station de base, le profil de QoS permet de définir comment traiter le trafic au niveau du DRB.

La couche SDAP est également configurée par la signalisation RRC pour chaque DRB.

Conclusion

La session PDU permet de connecter le terminal vers un réseau PDN, ce réseau est susceptible d’offrir plusieurs services avec des flux de QoS différentes.

La connexion radio est assurée par la station de base qui contrôle les ressources radios. Les différentes couches ont pour rôle d’apporter un service de transfert de données sécurisés en respectant la QoS établie avec le coeur de réseau.

Figure 2 : Les couches protocolaires de l’interface radio

[1] https://www.sharetechnote.com/html/5G/5G_QoS.html

[2]  TS 137 324 – V15.1.0 – LTE; 5G

[3] https://www.techplayon.com/5g-nr-sdap-service-data-adaption-protocol/

 

Evolution de la pile protocolaire LTE vers NR (4/5)

Posté le by - 556 vues
Répondre

La couche PDCP

La couche NR PDCP réalise les fonctions de la couche LTE PDCP et de nouvelles fonctions sont implémentées au niveau du NR PDCP comme la mise en ordre des paquets ce qui permet de faciliter la double connectivité et le partage des fonctions CU/DU (sur l’interface F1, les paquets peuvent être reçus dans un autre ordre).

Les fonctions réalisées par la couche LTE PDCP et la couche NR PDCP sont :

  • Chiffrement et Intégrité des supports de signalisation SRB2/SRB3;
  • Chiffrement du support de trafic DRB. La couche NR PDCP peut également apporter l’intégrité;
  • compression/décompression d’en-tête (ROHC);
  • fonction de routage dans le cas de la double connectivité (split bearer).

Parmi les nouvelles fonctionnalités, le couche NR PDPC a en charge seule :

  • la mise en ordre des paquets
  • la duplication des paquets pour les services à faible latence et fiable (typiquement URLLC)

La mise en ordre des paquets est réalisée sur une taille de fenêtre (nombre de PDCP PDU) définie par la couche RRC et qui démarre à la réception SN du paquet PDCP PDU (push-based window) et une durée d’expiration . Tout paquet PDCP PDU reçu au niveau de la couche PDCP réceptrice avec un SN en dehors de la fenêtre est considéré comme perdu contrairement à la mise en ordre de la couche LTE RLC ou tout nouveau paquet était vu comme nouveau et donnait la valeur de la fenêtre.

La fonction de mise en ordre peut être désactivée si le service n’est pas adapté.

La fonction de duplication

La duplication permet à la couche PDCP d’envoyer le même paquet PDCP PDU à deux entités RLC différentes. La duplication est contrôlée au niveau de la couche MAC (MAC CE).

Evolution de la pile protocolaire LTE vers NR (2/5)

Posté le by - 598 vues
Répondre

Suite de l’article

La couche MAC [TS 38.321]

La couche MAC transmet ou reçoit :

  • de la couche physique des canaux de transport (interface L1 : Layer 1),
  • de la couche RLC des canaux logiques

Figure 2 : Les canaux de la pile protocolaire LTE/NR

 

L’unité de données protocole de couche MAC (MAC-PDU) remplit le bloc de transport TB (Transport Block).

Le bloc de transport est défini par la signalisation L1 (L1 signaling) c’est à dire sa taille et des paramètres physique comme le schéma de modulation et de codage MCS et la longueur du slot.

La couche MAC transporte les données utilisateurs (plan de trafic) et les données de signalisation (plan de contrôle). Différentes structures de la couche MAC ont été définies et l’élément de contrôle MAC CE (Control Element) transport de la signalisation.

La structure MAC est définie par dans l’en-tête MAC (MAC Header) via l’information LCID (Logical Channel ID)

Figure 3 : Liste des MAC CE

 

La structure de la couche MAC PDU pour la transmission de données (UL-SCH et DL-SCH) est optimisée pour transporter des grandes quantités de données, en utilisant notamment la fonctionnalité de concaténation des données de la couche RLC : plusieurs MAC SDU peuvent être multiplexée dans une seule MAC PDU.

Contrairement en 4G ou l’en-tête MAC contient un ensemble de sous-entête pour chaque CE ou SDU, la MAC PDU se découpe en sous en-tête MAC suivi du CE ou du SDU. Cette structure facilite le traitement en pipeline au niveau de l’émetteur et du récepteur et le traitement démarre dès qu’une sous en-tête et le SDU ou le CE associé est reçu.

MAC PDU LTE

Figure 4a : MAC PDU LTE en DL

MAC PDU NR

MAC PDU NR

Figure 4b : MAC PDU NR en DL

La taille du SDU ou le champs LCID pour la MAC CE est dynamiquement indiquée dans l’en-tête.

Les rôles de la sous-couche MAC sont [FL2]:

  • la correspondance entre les canaux logiques et les canaux de transport;
  • le multiplexage/démultiplexage des unités de données de services MAC SDU en provenance d’un canal logique ou de plusieurs canaux de transport (TB) ou de plusieurs canaux de transport à destination des canaux logiques ;
  • La concaténation des MAC-SDU lors du multiplexage des unités de données.
  • La demande de transmission de données de la part du mobile (BSR : Buffer Status Reporting)
  • la correction d’erreur rapide HARQ ;
  • la gestion de priorité entre les mobiles ;
  • la gestion de priorité sur les canaux logiques pour un mobile ;
  • la gestion des échecs radio de faisceau

MAC

Figure 5 : La structure MAC

La gestion des faisceaux est la principale nouveauté de l’interface NR par rapport à l’interface LTE. Toutefois, pour faciliter la gestion du très haut débit, la fonction concaténation est réalisée au niveau de la couche MAC 5G (RLC en 4G)

La fonction de séquencement et la gestion de la priorité

La couche MAC priorise les données reçues de la couche RLC en fonction de la nature des données (canal logique CCCH, DCCH et DTCH).

Au niveau du terminal, la couche MAC implémente la fonction LCP afin de séquencer les données sur le lien montant. L’ordonnanceur de la fonction LCP détermine la taille des données qui seront multiplexées à partir des différents canaux logiques LCH pour former un MAC PDU. Chaque LCH est caractérisé par une priorité PBR (Prioritized Bit Rate) et une durée de la taille du paquet (BSD : Bucket Size Duration). La fonction LCP implémente également des restrictions comme la fenêtre d’acquittement selon le type de service (URLLC, eMBB, mMTC), l’espacement entre sous-porteuses (SCS : Sub Carrier Spacing), le type d’allocation de ressource (dynamique – Dynamic Scheduling ou configuré – Configured Grant [FL1]) et le type de slot (mini-slot). Enfin des restrictions sont également fournie de la part de la couche PDCP à la couche MAC dans le cas de la duplication de paquets afin de ne pas multiplexer deux paquets dupliquer dans une seule MAC PDU.

La fonction LCP est contrôlée par la couche RRC qui configure les restrictions sur chaque canal LCH (figure 6) :

  • allowedSCS-List définit les valeurs SCS proposées pour la transmission ;
  • maxPUSCH-Duration indique la durée de transmission PUSCH maximale ;
  • configuredGrantType1Allowed informe si la transmission est préconfigurée de type 1 (Configured Grant Type 1) ou dynamique;
  • allowedServingCells which indique les cellules autorisées pour la transmission ;
  • allowedCG-List qui indique les configurations autorisées (CG) pour la transmission ;
  • allowedPHY-PriorityIndex allouant les index de priorités aux transmissions allouées dynamiquement.

Le séquencement sur la voie montante (UL Scheduling) est réalisé à partir d’informations physiques fournies par la station de base gNB

Figure 6 : la configuration des canaux logiques et le paramétrage de séquencement

 Afin d’assister le gNB sur les décisions radio de l’UE, d’autres fonctions (similaires en 4G) sont implémentées au niveau de la couche MAC comme la fonction SR (Scheduling Request), BSR et PHR (Power Headroom Report).

Les procédures de la couche MAC

La couche MAC est à l’initiative des procédures suivantes :

  • l’accès aléatoire [FL3]
  • la transmission de données (DL assignments, UL scheduling request)
  • La demande de séquencement -SR procedure : l’entité MAC CE de l’UE informe le gNB de données à émettre de la part du terminal. Différentes configurations SR permettent de prioriser l’émission de canaux logique UL LCH.
  • La procédure BSR permet à la couche MAC UE d’indiquer au gNB la quantité de données stockée dans le buffer de l’UE par groupe de canaux logiques LCG (Logical Channe Group). Le BSR est transmis dans une structure MAC CE sur 2 octets (short BSR/truncated BSR) ou 4 octets (long BSR). Les valeurs du LCID sont :
    • 11100 Truncated BSR
    • 11101 Short BSR
    • 11110 Long BSR

L’Interface NR implémente 8 LCG au lieu de 4 pour le LTE (l’information LCG n’était que sur 2 bits).

La couche RRC contrôle la procédure BSR en configurant 3 temporisateurs (le déclenchement BSR peut être régulier, périodique, ou padding) :

  • periodicBSR-Timer (periodic BSR)
  • retxBSR-Timer ( (regular BSR)
  • logicalChannelSR-ProhibitTimer
  • la procédure PHR (Power Headroom Report) permet à la couche MAC UE d’envoyer un rapport au gNB lui indiquant la réserve de puissance du mobile avant d’émettre à la puissance maximale. Le PH est transmis à chaque cellule serveuse qui configure la porteuse UL (dans le cas de l’agrégation de porteuses CA). Cela permet d’assister le gNB sur la décision du MCS dans le cas du séquencement montant. Le PHR est transmis dans une structure MAC CE. Deux types de PHR sont définis : périodique ou déclenchement sur seuil (RSRP). Ces valeurs de déclenchement sont configurées par la couche RRC lors d’un message RRC Setup, RRC Reconfiguration, .. (cf. FL4) dans l’IE PHR-Config (PeriodicPHR-Timer, ProhibitPHR-TImer, dl-pathlossChange)
  • la réception discontinue DRX pour réduire la consommation énergétique du terminal. Le mode DRX contrôle le moment ou le terminal écoute le canal PDCCH (décision d’ordonnancement) à travers plusieurs temporisateur [FL5]. La différence principale par rapport au LTE est sur la gestion de différents SCS configurés sur différentes cellules.

Pour la transmission montante, la configuration Grant-Free Scheduling [FL6] permet de réduire encore davantage la consommation énergétique (selon les restrictions LCP)

  • la commutation de BWP
  • la surveillance d’inactivité
  • la gestion du faisceau : La gestion de l’échec de faisceau (Beam Failure Management) est gérée par la couche MAC à partir de mesures de la couche physique (BFI : Beam Failure Instance). Deux procédures sont impliquées :
    • Procédure BFD (Beam Failure Detection) à partir de la mesure de la couche physique L1-RSRP (en dessous d’une certaine limite).
    • Procédure BFR ( Beam Failure Recovery)

La couche RRC contrôle les paramètres des procédures BFD et BFR dans les paramètres suivants : BeamFailureRecoveryConfig, BeamFailureRecoverySCellConfig et  RadioLinkMonitoringConfig

  • beamFailureInstanceMaxCount pour la détection de la défaillance du faisceau;
  • beamFailureDetectionTimer pour la détection de la défaillance du faisceau;
  • beamFailureRecoveryTimer pour la procédure de récupération d’un faisceau au niveau de la cellule SpCell ([FL7]);
  • rsrp–ThresholdSSB: la valeur seuil du RSRPpour la procédure SpCell beam failure recovery;
  • rsrp–ThresholdBFR: la valeur seuil du RSRP pour la procédure SCell beam failure recovery;

Références

[FL1] https://blogs.univ-poitiers.fr/f-launay/2020/05/15/e2e-network-slicing-le-decoupage-du-reseau-de-bout-en-bout-partie-3/

[FL2] :  https://blogs.univ-poitiers.fr/f-launay/2022/05/13/sdt-small-data-transmission-3eme/

[FL3] : https://blogs.univ-poitiers.fr/f-launay/2023/03/22/lacces-aleatoire-pour-les-terminaux-lte-ue-et-lte-bl-ce-ue-et-nb-iot-4step-ra-et-2-step-ra/

[FL4] : https://blogs.univ-poitiers.fr/f-launay/2023/03/21/les-supports-de-signalisation-srb-signaling-radio-bearer/

[FL5] : https://blogs.univ-poitiers.fr/f-launay/2016/11/04/paging-et-mecanisme-psmdrx/

[FL6] : https://blogs.univ-poitiers.fr/f-launay/2023/03/19/liot-evolutions-r16-et-r17/

[FL7] https://blogs.univ-poitiers.fr/f-launay/2022/07/20/pcell-scell-pscell-et-spcell/

[TS 38.321] Medium Access Control (MAC) protocol specification (3GPP TS 38.321 version 16.3.0 Release 16)

L’IoT – Evolutions R16 et R17

Posté le by - 593 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

PCell, SCell, PScell et SpCell

Posté le by - 1 889 vues
Répondre

L’augmentation en débit entre le déploiement de la 4G et le déploiement de la 4G+/4G++ (UHD) a été rendue en partie possible par la technique d’agrégation de porteuses radioélectriques supplémentaires 4G. La technique d’agrégation de porteuses (ou CA : Carrier Agregation) à 2/3/4 ou 5 bandes 4G (LTE Advanced/LTE Advanced Pro) permet ainsi au mobile de disposer théoriquement jusqu’à 100 MHz de bande radioélectrique (ce qui correspond à 5 bandes de 20 MHz) [1].

La technique d’agrégation de porteuses est supportée par la couche MAC et la couche physique. On différencie la porteuse composante primaire (PCC : Primary Component Carrier) et la porteuse composante secondaire (SCC : Secondary Component Carrier). La PCC correspond à la porteuse principale LTE et les SCC correspondent aux porteuses agrégées.

On définit la cellule principale (PCell) la cellule sur la porteuse PCC. La PCell correspond à la cellule choisie par le mobile pour demander l’établissement ou le ré-établissement du lien radioélectrique. La Pcell est modifiée lors d’un handover ou libérée en fin de session. Les porteuses secondaires SCC permettent au mobile d’augmenter sa bande passante sur les cellules correspondantes aux fréquences secondaires. Les cellules secondaires (SCell) sont configurées lors d’un message RRC (RRC connection) et sont ensuite activées ou désactivées par la couche MAC via un message DCI.

Le message DCI est porté par le canal physique PDCCH. Le canal PDCCH ne porte l’allocation que d’une seule porteuse.

L’allocation de ressource via le canal PDCCH peut être transmise [2] :

  • soit sur la porteuse correspondante aux ressources désirées, on parle de self-scheduling car chaque porteuse agrégée alloue ses ressources sur le canal PDCCH de la porteuse agrégée ;
  • soit sur la porteuse principales et chaque canal PDCCH porte l’allocation de ressources de la porteuse principale ou d’une porteuse agrégée. On parle alors de cross-scheduling.

Lorsque le mobile est en mode connecté, la cellule serveuse (Serving Cell) correspond à une porteuse composante (CC : Component Carrier) c’est à dire la cellule primaire ou une cellule secondaire. La station de base gère la cellule principale ainsi que les cellules secondaires via les messages DCI de la couche MAC.

Le déploiement de la 5G-NSA met en œuvre un mécanisme de double connectivité multi-radio (MR-DC), mécanisme pour lequel on différencie le nœud maître (MN : Master Node) du nœud secondaire (SN : Secondary Node).

Le nœud maître établie la connexion de signalisation entre le mobile UE et le cœur de réseau. Dans le cas de la 5G NSA option 3, le nœud maitre est une station de base 4G. Le nœud maître correspond toujours au nœud sélectionné par l’UE en mode de veille et sur lequel l’UE fait sa demande initiale d’accès aléatoire.

Le nœud secondaire quant à lui a pour rôle de fournir des ressources radioélectriques supplémentaire et contrairement au nœud maître, il ne permet pas l’établissement d’un plan de contrôle avec le cœur de réseau. Dans le cas de la 5G-NSA, le nœud secondaire est une station de base 5G nommée en-gNB.

La technique d’agrégation de porteuses peut être mise en œuvre sur le nœud maître et/ou sur le nœud secondaire. On différencie l’agrégation de porteuses sur le nœud maître par un groupement de cellules MCG (Master Cell Group) et l’agrégation de porteuses sur le nœud secondaire par un groupement de cellules SCG (Secondary Cell Group).

Lorsque le nœud maître initie la demande d’établissement avec le nœud secondaire, le mobile recevra l’ordre via un message RRC (RRC reconfiguration) d’établir une demande d’accès aléatoire RACH avec la cellule secondaire SN et de faire des mesures radioélectriques sur le nœud secondaire et plus particulièrement sur la cellule sur laquelle le mobile aura établi sa demande d’accès aléatoire. Il s’agit donc de la cellule principale du groupe de cellules secondaires PSCell (Primary SCG Cell soit Primary Secondary Cell Group Cell).

Ainsi, lors de la double connectivité, l’UE réalise des mesures radioélectriques sur la cellule principale de la cellule serveuse maîtresse (PCell du MCG) et sur la cellule principale de la cellule serveuse secondaire PSCell ainsi que des mesures sur les cellules agrégées.

On appelle PCell la cellule principale de la station de base maîtresse et en cas d’agrégation de porteuse sur cette cellule, on appelle SCell, les cellules secondaires du MCG.

On appelle PSCell, la cellule principale de la station de base secondaire et on appelle également Scell les cellules secondaires du SCG.

La signalisation RRC n’étant émise que sur les cellules principales PCell et PSCell, le concept de Special Cell détermine la signalisation vers les cellules Maîtres et Secondaires : SpCELL = PCell + PSCELL

 

Reférences

[1] : ETSI TS 138 133 V15.2.0 (2018-07)

[2] https://www.3gpp.org/technologies/keywords-acronyms/101-carrier-aggregation-explained#:~:text=Carrier%20Aggregation%3B%20Primary%20and%20Secondary,coverage%2C%20i.e.%20different%20cell%20size.

SDT – Small Data Transmission (3ème)

Posté le by - 886 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.