Sélection de cellules – Principes Généraux

L’objectif de cet article est de présenter comment l’UE effectue sa sélection de cellule à la mise sous tension du mobile et quels sont les critères de re-sélection de cellules. On complètera l’étude en présentant les processus sur la gestion des cellules opérant lorsque le mobile est en veille [1-2]. Nous n’étudierons ni le cas particulier des services de proximité (PROSE), ni les communications V2X.

Merci à Sébastien Picant, expert SIM Orange pour les échanges et la relecture

  1. La mise sous tension du mobile

Lorsque le mobile s’allume, sa première tâche consiste à sélectionner un réseau mobile PLMN (Public Land Mobile Network) ou un réseau privé SNPN (stand-alone non-public network). Cette sélection est réalisée par l’UE en deux étapes : l’une est effectuée au niveau de la couche AS (Access Stratum) et l’autre est réalisée par la couche NAS (Non Access Stratum) (https://blogs.univ-poitiers.fr/f-launay/2015/01/25/protocoles-nas-et-protocoles-as/):

  • La couche NAS demande à la couche AS de lui fournir la liste des réseaux PLMNs qui diffusent autour de l’UE.
  • La couche NAS sélectionne le PLMN à partir des mesures réalisées par la couche AS soit de manière automatique, soit en mode manuel si l’utilisateur choisi ce mode.

Figure 1 : Processus de sélection de cellule [1]

En mode automatique, l’objectif pour le mobile est de camper sur le réseau de son opérateur, c’est-à-dire, le réseau HOME (H-PLMN). A défaut, l’UE va favoriser un réseau équivalent. Le mobile a donc besoin de récupérer les identités des PLMNs situés autour de lui afin de comparer les identités à une liste de sélection présente sur la carte UICC [3] (L’UICC Universal Integrated Circuit Card est la carte SIM).

Définition – camper sur une cellule [1] : “The MS looks for a suitable cell of the chosen PLMN or SNPN and chooses that cell to provide available services, and tunes to its control channel

Les identités PLMN sont diffusées dans le message d’information SIB-1 (plusieurs identités peuvent être diffusées, comme c’est le cas par exemple pour la diffusion de l’identité des MVNO – Mobile Virtuel Network Operator) via le TAI (Tracking Area Identifier). Le mobile stocke les valeurs TAI autorisées et non autorisées pour éviter des tentatives d’itinérance (roaming) lorsque le signal de l’opérateur H-PLMN est faible (cas à la frontière par exemple). Le mobile constitue également une liste de PLMNs non autorisés pour des accès satellitaires NTN (Non Terrestrial Network : PLMNs not allowed to operate at the present UE location).

L’UE dispose d’une liste de PLMN qui est enregistrée sur la carte UICC. Le Mobile ME doit utiliser les informations stockées sur la carte UICC pour la sélection de PLMN en fonction du service activé et de la présence du fichier correspondant (stocké dans l’UICC par exemple EF_EHPLMN, EF_PLMNwACT, EF_OPLMNwACT, …)

Les réseaux interdits ( sur lesquels le device s’est fait jeté – event « network rejection ») sont stockés dans la carte dans le fichier Forbidenn F-PLMN.

Le H-PLMN est extrait à partir de l’identité IMSI de l’UICC.

Dans l’UICC peuvent être stockés, par ordre de priorité, des réseaux PLMN (Public Land Mobile Network) considérés comme équivalents au réseau HOME dans la liste nommée EHPLMN (Equivalent Home PLMN).

Le terminal peut sélectionner le réseau « HOME » (ou equivalent HOME) en comparant l’identité MCC-MNC de l’opérateur couvrant la cellule avec :

  • les informations MCC-MNC de l’IMSI (HPLMN)

ou

  • avec la liste des réseaux équivalents « Equivalent Home » stockés dans le fichier EF_EHPLMN (Si le fichier EHPLMN est présent, l’UE va comparer uniquement avec les PLMN listés dans ce fichier. Pour qu’il compare également avec le HPLMN de l’IMSI, ce dernier doit être présent dans ce fichier).

 

Le processus de recherche du réseau HOME (ou équivalent HOME) peut être optimisé

avec la liste des réseaux Homes en priorisant le choix du PLMN avec le type d’accès radioélectrique autorisé stockés dans le fichier EF_HPLMNwACT

 

Selon le service activé sur la carte UICC, le mobile sélectionnera une des méthodes ci-dessus. Il est donc nécessaire que le fichier EF existe et soit non vide.

 

En cas d’itinérance à l’étranger (Roaming), le terminal peut sélectionner le réseau visité « Visited » à partir du :

  • EF PLMNwact (Extended Preferred Roaming List)

ou

  • EF_OPLMNwACT 

 

Le fichier EF OPLMNwact liste les réseaux étrangers pour lesquels l’opérateur a un accord d’itinérance (roaming) afin qu’un de ces réseaux soit sélectionné en priorité.

 

Il est possible de restreindre le type d’accès radioélectrique en intégrant à la liste des opérateurs PLMNwact ou OPLMNwact le type d’accès.

A titre d’exemple, le fichier EF_OPLMWwACT est plus restrictif car il peut imposer au mobile de sélectionner un réseau d’accès d’un PLMN (exemple 2G/3G) parmi les différents types de réseau du PLMN. On peut citer comme exemple l’accord d’itinérance 2G entre Free et Orange. Il faut donc que le fichier EF_OPLMNwACT soit enregistré et non vide pour que le terminal de Free, en cas de perte de couverture Free, sélectionne l’opérateur Orange mais uniquement en 2G/3G.

Evidemment, le sélecteur ou l’activation du service va déterminer quel fichier doit être utilisé. L’opérateur devra donc s’assurer de remplir les fichiers avec la liste des opérateurs souhaités.

Si par exemple, le mobile utilise la liste EF_PLMNsel, l’opérateur devra provisionner le fichier avec sa propre identité puisque la sélection par les informations MCC-MNC de l’IMSI n’a pas été activée.

Pour résumer, les fichiers pouvant être utilisée sont les suivants [5] :

  • EF_EHPLMN: contient la liste des PLMN qui peuvent être considérés comme un H-PLMN. Les éléments sont répertoriés par ordre de priorité décroissante, ce qui signifie que le premier PLMN de la liste a la priorité la plus élevée et que le dernier élément a la priorité la plus basse. (Se référer à 31.102 4.2.84 EF_EHPLMN pour le format de données détaillé, se référer à 23.122 4.4.3.1.1 pour la détermination de la priorité dans la sélection de cellule).
  • EF_HPLMNwAcT: ce fichier stocke le nom du H-PLMN en y associant la liste des technologies d’accès disponibles par ordre décroissant de priorité, ce qui signifie que le premier PLMN a la priorité la plus élevée. Cette liste est plus restrictive que la précédente.
  • EF_PLMNwACT: les informations contenues dans ce fichier sont déterminées par l’utilisateur et définissent les PLMN préférés de l’utilisateur par ordre de priorité.
  • EF_OPLMNwACT: ce fichier est le sélecteur PLMN contrôlé par l’opérateur avec les technologie d’accès associées. C’est dans ce fichier que l’opérateur Home provisionne les PLMN pour lesquels il a un accord d’itinérance. Ce paramètre contient la liste des couples (PLMN, Access Technology).

 

Le fichier OPLMNwact liste les réseaux étrangers pour lesquels l’opérateur a un accord de roaming afin que ce réseau soit sélectionné en priorité.

Il est possible de mettre à jour les fichiers de la carte SIM à distance via une plateforme (back-end) et la technologie OTA (Over The Air) ou par message NAS.

La technologie OTA permet de télécharger des applications vers la carte UICC, de communiquer et gérer la carte UICC à distance.

Le service de back-end transmet des requêtes de service vers la passerelle OTA qui les transforme en message SMS gérés par la plateforme SMSC ou par les protocoles CAT_TP ou https.

Une fois la carte UICC mise à jour, il faut forcer le terminal pour prendre en compte les modifications apportées.

Il existe plusieurs commandes pour relire la carte UICC [4,6,7]:

  • Reset UICC
  • Refresh
  • Déclenchement du mode Steering or Roaming SoR

En cas de Roaming, le déclenchement du mode SoR (Steering of Roaming [8]) permet :

  • D’autoriser un UE enregistré sous son réseau opérateur Home HPLMN de sélectionner un réseau VPLMN qui n’est pas dans la liste des réseaux interdits
  • A l’UE de détecter si le VPLMN sélectionné est capable de transmettre des informations de contrôle SoR émise par le HPLMN.

Le plan de contrôle SoR permet au réseau opérateur Home H-PLMN de mettre à jour de manière sécurisée le ficher EF OPLMWact (c’est-à-dire la liste de sélection PLMN et l’accès radioélectrique).

Si la commande de déclenchement SoR est désactivée, il faut forcer le terminal en l’éteignant/l’allumant pour relire le fichier EF OPLMWact.

Si la commande SoR est activée, il est possible de rafraîchir des données PLMN (commande refresh). Ce mode permet à l’UICC de mettre à jour la liste de PLMNs à l’UE pour qu’il la prenne en compte dans sa sélection de réseau.

Pour cela il faut envoyer la commande USAT REFRESH [4,9] (USIM Application Toolkit) a une application sur la carte UICC qui va déclencher la mise à jour sans avoir besoin de forcer la re-sélection du réseau. Dans ce cas, le mobile remplace l’entrée prioritaire du fichier EF  OPLMNwAcT par la liste fournit lors de la commande USAT REFRESH.

En cas d’absence de réseau (ou le réseau du pays visité n’est pas déclaré dans la liste OPLMWact), l’UE fait une procédure d’attachement avec le réseau visité. Le MME interroge le HSS de l’opérateur Home, lequel donne son accord ou refuse le roaming. Si le HSS de l’opérateur Home accepte l’attachement, le réseau visité peut avoir des partenariats (réseaux équivalents) dont la liste est transmise du MME visité à l’UE. L’UE conservera cette liste, mais ne l’enregistre pas au niveau de l’UICC (il n’y a pas de mise à jour de l’USIM).

Dans le cas où le sélecteur PLMN s’appuie sur le fichier OPLMNwaCt, alors lorsque le mobile a sélectionné le réseau préféré (H-PLMN, E-PLMN ou V-PLMN), il va ensuite procéder au choix de la technologie radioélectrique associée.

Références

[1] TS 23.122 V17.7.1 (2022-06) Non-Access-Stratum (NAS) functions related to Mobile Station (MS) in idle mode

 

[2] TS 36.304 v17.1.0 (Juin 2022), Evolved Universal Terrestrial Radio Access (E-UTRA); User Equipment (UE) procedures in idle mode

[3] TS 31.121 version 16.0.0 Release 16, UICC-terminal interface; Universal Subscriber Identity Module (USIM) https://www.etsi.org/deliver/etsi_ts/131100_131199/131121/16.00.00_60/ts_131121v160000p.pdf

[4] 3GPP TS 31.111, Universal Subscriber Identity Module (USIM) Application Toolkit (USAT)

[5] https://www.sharetechnote.com/html/Handbook_LTE_USIM_Parameters.html

[6] ETSI TS 102 221 : Smart cards; UICC-Terminal interface; Physical and logical characteristics

[7] https://www.gsma.com/newsroom/wp-content/uploads/SGP.02-v4.0.pdf

[8] https://www.gsma.com/newsroom/wp-content/uploads//IR.73-v5.0.pdf

SubBand Full Duplex – SBFD

Introduction

La technique de duplexage est utilisée dans les systèmes de communication pour permettre les transmissions bidirectionnelles (montante et descendante).

Il existe deux principaux types de duplexage : le Duplexage Fréquentiel (Frequency Division Duplex – FDD) et le Duplexage Temporel (Time Division Duplex – TDD).

Pour la technique FDD, des bandes de fréquences distinctes sont allouées pour la liaison montante et la liaison descendante. Ainsi le trafic dans les deux directions utilise des fréquences différentes ce qui évite les interférences.

Pour la technique TDD, une seule bande de fréquences est utilisée, mais le temps est divisé en intervalles fixes. Ces intervalles alternent entre les liaisons montantes et descendantes. Ainsi, bien que la fréquence reste la même, le temps est utilisé de manière différente. Cela permet également une communication bidirectionnelle, mais à des moments différents.

Figure 1 : Technique FDD/TDD

Les réseaux cellulaires : FDD/TDD et SBFD/FD

En 4G, les multiplexages FDD et TDD sont tous deux utilisés pour répondre aux différents besoins des opérateurs et des déploiements spécifiques.

La technique FDD permet théoriquement une latence plus faire, la technique TDD permet un débit plus important dans le sens DL par rapport au UL.

La 5G-NR exploite la technique TDD avec une flexibilité accrue sur le sens de transmission des symboles dans un slot offrant ainsi une efficacité spectrale améliorée, une latence réduite. La réduction de la latence et l’augmentation du débit permet de prendre en charge une variété de services et d’applications, notamment l’Internet des objets (IoT), la réalité virtuelle (VR) et les communications ultra-fiables à faible latence (URLLC).

La 5G Advanced propose le multiplexage SBFD (Sub Band Full Duplex), ce qui revient à intégrer la méthode FDD dans le TDD. Le multiplexage SBFD sera exploité sur l’interface radio 6G. Il s’agit d’une étape intermédiaire avant la méthode Full Duplex FD.

Dans le cas du SBFD, la bande de fréquence utilisée en TDD est divisée en sous bande (SubBande). Le multiplexage SBFD propose de transmettre en UL et/ou DL sur chaque slot dans les sous-bandes. Ainsi, au lieu de faire du TDD sur toute la bande, on utilise des sous bandes pour transmettre en UL et/ou DL.

Figure 2 : Le multiplexage SFBD [1]

Du point de vue de l’UE, cette configuration est compatible avec l’interface 5G NR et le découpage des slots en DL, UL ou Flexible

Figure 3 : La configuration des slots en 5G NR [2]

Un terminal UE peut être configuré pour avoir des slots en Uplink ou Downlink ou flexible. La méthode SBFD est donc possible pour tout terminal 5G (exemple de terminaux embarquant le SoC Qualcom X65). La station de base doit supporter le mode FD (Full Duplex) puisqu’elle doit pouvoir émettre et recevoir en même temps.

Les défis

Le premier défi concerne la gestion de l’interférence entre deux gNB (CLI : Cross Link Interference). Cette interférence se produit lorsque un gNB est en émission et simultanément, un gNB voisin est en réception sur la même bande. Pour éviter cette interférence, toutes les stations de base 5G sont synchronisées et la configuration du schéma de transmission est fixé soit un DL, soit un UL.

Mais, la méthode de multiplexage SBFD introduit les slots flexibles. La configuration par slot est déjà prévue dans le standard 5G. Dans ce cas, la station de base utilise un temps de garde pour éviter les interférences.

Figure 4 : Temps de garde en TDD pour éviter les interférences

L’autre défi est l’auto-interférence (SI : Self Interference) lorsque le signal en émission vient polluer le signal en réception de part une isolation non totale entre la chaîne de transmission et de réception.

Figure 5 : L’auto-Interférence

Pour réduire les interférences, un saut en fréquences (GAP) est inséré dans la bande TDD pour séparer les sous bandes UL et DL.

 

L’autre défi est la conception radio qui dégrade les performances de l’émetteur de part la non linéarité de l’amplificateur de puissance. Une méthode de pré-distorsion permet de réduire les produits d’intermodulation lorsque l’amplificateur fonctionne dans sa zone non linéaire (efficacité énergétique).

 

[1] Interference Mitigation for Non-Overlapping Sub-Band Full Duplex for 5G-Advanced Wireless Network, https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=9992227

[2] https://www-zte-com-cn.translate.goog/global/about/magazine/zte-technologies/2023/1-en/3/enhancing-spectrum-flexibility-with-subband-full-duplex.html?_x_tr_sl=en&_x_tr_tl=fr&_x_tr_hl=fr&_x_tr_pto=sc

[3] https://lup.lub.lu.se/luur/download?func=downloadFile&recordOId=9111900&fileOId=9112101

L’interface DECT-2020 NR

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

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)

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

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)

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)

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)

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]);
  • rsrpThresholdSSB: la valeur seuil du RSRPpour la procédure SpCell beam failure recovery;
  • rsrpThresholdBFR: 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

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