BL UE, non BL UE et NB-IoT, quelles sont les différences?

Les procédures relatives au fonctionnement des terminaux UE différent selon le type de terminal.

A titre d’exemple, la procédure d’accès aléatoire (se référer au paragraphe 5.1.1 de la spécification TS36.321) indique :

« Before the procedure can be initiated, the following information for related Serving Cell is assumed to be available for UEs other than NB-IoT UEs, BL UEs or UEs in enhanced coverage « 

L’objectif de cet article est de préciser à quel terminal fait référence la spécification.

Dans le cadre des transmissions IoT, la spécification 3GPP a proposé plusieurs techniques :

  • d’optimisation d’énergie (eDRX, PSM, Half Duplex, réduction de la puissance d’émission)
  • de simplification des terminaux (Half Duplex/absence de duplexeur, réduction de la puissance d’émission – PA optionnel, largeur de bande réduite – moindre complexité des antennes et des filtres)
  • d’amélioration de la couverture dite aussi CE Coverage Enhanced (réduction de la bande – meilleure sensibilité, répétition – mode A ou mode B)

L’implémentation de ces optimisations a permis de définir différentes catégories de terminaux dédiés à l’IoT :

  • NB-IoT qui émet/reçoit sur une sous porteuse jusqu’à 12 sous porteuses maximums (RB)
  • BL UE (Bandwidth reduced Low Complexity) qui utilise une sous bande réduite de l’interface LTE, typiquement de :
    • 6 RB (LTE-M1) pour les liens montants et descendants
    • 24 PRB (LTE-M2) pour augmenter le débit de transmission. Ces terminaux augmentent uniquement la largeur de bande des canaux PDSCH et PUSCH
  • Non BL UE fonctionnant dans le mode CE (Coverage Enhanced) utilisant jusqu’à 24 PRB dans le lien montant et 24 PRB ou 96 PRB dans le sens descendant.

La largeur de bande pour le lien montant et descendant est configurée par la signalisation RRC.

Un terminal BL UE se synchronise sur les canaux PSS/SSS de l’interface LTE mais, le terminal ne peut camper sur la cellule seulement si l’information MIB indique la présence d’un SIB1 (nommée SIB1-BR) dédié aux terminaux UE BL La cellule est considérée comme barrée en absence de cette information.

Les informations sur la localisation du SIB1 est diffusée par le MIB via l’information schedulingInfoSIB1-BR-r13 codée sur 5 bits. Si la valeur est égale à 0, le SIB1-BR n’est pas transmise. La valeur entre 1 et 31 indique la transmission du SIB-BR et la répétition du canal PDSCH qui transporte le SIB1-BR.

Les autres SIB sont séquencés à partir du SIB1-BR. Le SIB2-BR permet au terminal BL UE d’acquérir les informations sur les préambules d’accès aléatoires.

On différence ainsi les catégories de terminaux :

  • NB-IoT
  • BL UE : LTE-M1/LTE-M2
  • Non BL UE : LTE cat.0

La taille du bloc de transport TBS (Transport Block Set) pour la diffusion d’information est limitée à 1000 bits pour les terminaux BL UE.

La taille du bloc de transport pour le canal de trafic PDSCH/PUSCH est limitée à 1000 bits pour les terminaux LTE-M1 et à 680 bits pour les terminaux NB-IoT.

.

PCell, SCell, PScell et SpCell

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.

MOOC 5G – 2022

MOOC 5G : A ne pas rater.

Xavier Lagrange est professeur à l’institut IMT Atlantique ; il est responsable de l’équipe de recherche ADOPNET du département (Réseaux, Télécommunications et Services) de l’IRISA. Dans ce Mooc M Lagrange propose de nouvelles vidéos très pédagogiques sur le fonctionnement de la 5G.

Au cours de la semaine 2, M Lagrange et son équipe présentent l’architecture du réseaux 5G et les services attendus (5G SA).

La semaine 3, l’interface radio est présentée avec un rappel de l’interface radio 4G.

La semaine 4, les protocoles et procédures de gestions de flux sont abordés

La semaine 5, les mécanismes de sécurité permettent de comprendre les protections mises en œuvre pour l’authentification (AKA), le chiffrement et l’intégrité (CIA). Une présentation détaillée du SUCI est remarquable. Bien que très complexe, M Lagrange a réussi à expliquer simplement l’échange de clé, le calcul de la clé éphémère partagée et le calcul du SUCI.

La semaine 6, l’architecture Cloud Native est présentée (SBA et SBI)

La semaine 7, on découvre l’interconnexion entre réseaux et les fonctions de sécurités.

La formation est très intéressante (il existe aussi une formation sur la 4G) et l’approche très didactique et pédagogique.

Si vous ne vous êtes pas encore inscrit, cliquez sur le lien suivant :

https://www.coursera.org/learn/5g-principes-de-fonctionnement#instructors

Et bonne formation.

Master Objets Connectés / IoT de l’université de Poitiers (ouvert à l’alternance)

Le master Objets Connectés / IoT de l’université de Poitiers a pour objectif de former les étudiants aux nouveaux métiers pluridisciplinaires d’ingénierie de l’IOT (Internet Of Things). Les compétences développées dans cette formation répondent aux besoins actuels d’architectes logiciels et matériels sur toute la chaîne de transmission et de traitement dédiée aux objets connectés et intelligents. Les modules d’acquisition, d’analyse et de traitement des données, de vision, d’intelligence artificielle, d’électronique et d’informatique embarquée, de technologies sans fil, de réseaux et de cyber sécurité illustrent cette approche. Afin d’atteindre le niveau d’expérience recherché dans ces domaines, et en lien avec les nouvelles pédagogies, une partie importante de la formation est dédiée à la mise en œuvre pratique sur des cas d’usages proposés par nos partenaires industriels et notre laboratoire de recherche support XLIM.

Vous êtes étudiants, une entreprise/structure en recherche de stagiaires ou contrats d’alternance, ou autre contactez :

Clency.perrine@univ-poitiers.fr

www.sfa.univ-poitiers.fr/objetsconnectes/

Le réseau privé mobile de radiocommunication PMR – Private Mobile Radio

I- Introduction

Le réseau privé mobile Radio (PMR) ou Réseau Mobile Privatif (RMP) est utilisé par les services publics (collectivités, ministère de l’intérieur, sécurité publique) et les entreprises pour des besoins de résilience sur leur infrastructure et leur communications.

Aujourd’hui les réseaux PMR sont utilisés pour des besoins de :

  • communications mobiles extérieures à bande étroite (TETRA, DMR, GSM-R)
  • communications sans fils intérieures (DECT)
  • communications de données (WiFi privatif)
  • communication pour l’IoT (LoRAWAN, LTE-M, NB-IoT)

Les communications mobiles TETRA ont connu un grand succès avec les communications de terrain via le mode Talkie Walkie. Toutefois, le réseau TETRA n’offre qu’un faible débit de données et un nombre limité de terminaux ce qui ne répond plus au besoin d’aujourd’hui.

Les réseaux PMR 4G et PMR 5G présentent de nombreux avantages :

  • la prise en charge de la QoS;
  • la sécurisation des échanges et de l’infrastructure (ex : Stormshield);
  • une bonne couverture par station de base;
  • des gammes de smartphones durcis 4G (encore en nombre limité en 2022 pour la 5G);
  • la gestion des appels d’urgence, dénommés Missions critiques (MCx, Push To X – PMR à bande étroite);
  • la gestion de l’IoT avec pour la 5G la prise en compte d’une faible latence.

Selon les partenariats de Roaming, l’entreprise ou l’acteur public déploie un cœur de réseau dédié et des accès radios privés pour ses propres services de DATA et de voix

Les terminaux sont gérés par une plateforme OTA (Over The Air) afin de charger le profil des cartes SIM sur l’interface radio.

Avec la 4G/5G, les nouveaux services visés pour le réseau PMR sont :

  • Les services missions critiques : MCPTT (LTE Advanced Pro : En route vers la 5G)
  • Les applications collaboratives (communications enrichies WhatsApp,..)
  • Les services industrielle (entreprise 4.0) : IoT, robotique, maintenance prédictive, VR/AR/MR,
  • les services de données haut débit (image vidéo, reconnaissance faciale, … )

Une analyse du marché [1] montre que les réseaux PMR 4G/5G devraient connaitre une croissance mondiale estimée à 35% jusqu’en 2026 (et 20% ensuite). La figure 1 compare le réseau PMR 4G par rapport aux autres technologies réseaux PMR:

Figure 1 : Comparaison des solutions technologiques PMR [1]

II – Les bandes de fréquences

Actuellement, le ministère de la défense et le ministère de l’intérieur disposent de leur propre bande de fréquence ;

  • Le ministère de la défense dispose de la bande 40 (90 MHz de bande à 2,31 GHz – 2,4 GHz).
  • Le ministère de l’intérieur dispose des bandes 28 et 68 suivantes : 698 MHz – 703 MHz, 733 MHz- 736 MHz, 753 MHz – 758 MHz, 788 MHz – 791 MHz

Jusqu’au milieu des années 2010, les bandes de fréquences se situaient dans les bandes suivantes :

  • UHF : 380-470 MHz et 900 MHz (GSM-R)
  • VHF : 50 MHz, 60 MHz, 80 MHz, 160 MHz

En 2019, l’ARCEP a ouvert la bande B38 (2575 MHz à 2615 MHz) de 40 MHz de bande en mode TDD proposée pour la 4G mais qui pourra aussi couvrir la 5G.
Figure 2 : Les bandes de fréquence PMR en France en 2021

Pour la 5G, l’ARCEP va proposer les bandes suivantes

  • Bande 3,800 à 4,200 GHz,
  • Bandes dites « millimétriques » : 26 GHz.

L’accès radio est gérée par une station de base eNB en 4G ou gNB en 5G. L’alliance OPEN-RAN devrait faciliter, à partir de 2025, le déploiement de gNB PMR 5G.

Pour la 4G, l’eNB est classiquement composée d’une tête radio déportée (RRU/RRH) et d’une unité de traitement et de contrôle BBU. L’unité BBU est connectée au cœur de réseau.

Le cœur de réseau 4G ou 5G profite de la solution de virtualisation pour être déployé sur le Cloud ou sur une VM. Pour des raisons de résilience, il est préférable de dupliquer le coeur de réseau.

III- La Mission critique  MCPTT

L’application Mission Critique Push To Talk a initialement été normalisée par le standard 3GPP pour les réseaux  4G [3] avec comme objectif de maintenir le même niveau de sécurité, de résilience que la fonctionnalité Talkie Walkie du réseau TETRA.

Le service MCPTT prend en charge la communication entre plusieurs utilisateurs (un appel de groupe), et arbitre, pour chaque utilisateur, la permission de pouvoir prendre la parole via un mécanisme de contrôle (floor control) en cas de congestion.

Le service MCPTT permet aussi les appels privés entre deux utilisateurs du groupe.

Pour permettre la gestion des utilisateurs, le service MCPTT s’appuie sur deux facilitateurs de service :

  • Le service de proximité PROSE (Proximity Service Enabler)
  • Le service de gestion d’appels de groupe GCSE (Group Communication System Enabler)

Le service de proximité permet d’étendre la couverture du réseau 4G en utilisant le téléphone comme point relais d’une station de base ou comme station de base.

Le service de gestion d’appels de groupe permet la transmission d’un flux de 1 vers N via un mécanisme de multicast pour le trafic et de broadcast pour la signalisation.

La fonction MCPTT utilise le service multimédia fourni par le réseau IMS (IP Multimedia Sub-system), le service de proximité ProSe, le service de communication de groupe GCSE fourni par le réseau eMBMS et le service de transfert des données fourni par le réseau de mobiles EPS.

Bibliographie

[1] http://ld-expertise.com/wp-content/uploads/2021/09/ETUDE-DE-MARCHE-RMP_2021.pdf

[2] Network 2020: Mission Critical Communications : https://www.gsma.com/futurenetworks/wp-content/uploads/2017/03/Network_2020_Mission_critical_communications.pdf

[3] LTE; Mission Critical Push to Talk (MCPTT) over LTE; Stage 1 : https://www.etsi.org/deliver/etsi_ts/122100_122199/122179/13.03.00_60/ts_122179v130300p.pdf

SDT – Small Data Transmission (3ème)

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_INACTIVE

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 et RRC_CONNECTED

L’état RRC INACTIVE a été introduit 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 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.

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

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.

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.

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 INACTIVE à l’état RRC Connected)

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 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.

SDT – Small Data Transmission (2ème)

Procédure d’accès aléatoire

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

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

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

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

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

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

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

Le RAR contient :

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

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

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

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

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

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

Les messages transmis portent les informations suivantes :

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

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

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

 

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

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

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

 

Ressources Bibliographiques

 

[1] TS 136 211 – V14.2.0 – LTE; Evolved Universal Terrestrial Radio  Table 5.7.1-2: Frame structure type 1 random access configuration for preamble formats 0-3

[2] TS 136 211 – V14.2.0 – LTE; Evolved Universal Terrestrial Radio  Table 5.7.2-4: Root Zadoff-Chu sequence order for preamble formats 0 – 3

[3] TS 136 211 – V14.2.0 – LTE; Evolved Universal Terrestrial Radio  Table 5.7.2-2 NCS for preamble generation (preamble formats 0-3)

[4] Andreas Höglund, Dung Pham Van, Tuomas Tirronen, Olof Liberg, Yutao Sui, and Emre A. Yavuz, “3GPP Release 15 Early Data Transmission”, 2018, IEEE Communications Standards Magazine ( Volume: 2, Issue: 2, JUNE 2018), p90-96, https://doi.org/10.1109/MCOMSTD.2018.1800002

[5] Andreas Höglund, G. A. Medina-Acosta, Sandeep Narayanan Kadan Veedu, Olof Liberg, Tuomas Tirronen, Emre A. Yavuz, and Johan Bergman , 3GPP Release-16 Preconfigured Uplink Resources for LTE-M and NB-IoT

[6] 3GPP TS 36.213, R.16.8.0 : Evolved Universal Terrestrial Radio Access (E-UTRA); Physical layer procedures

[7] 3GPP TS 38.321, R.17.0.0 (mars 2022), MAC protocol Specification.

SDT – Small Data Transmission

Introduction

L’Internet des Objets a poussé la 3GPP a imaginé des protocoles dédiés pour des transmissions à faible volumétrie de données SDT (Small Data Transmission).

Le réseau 4G propose deux solutions SDT nommées EDT (Early Data Transmission) et la PUR (Preconfigured Uplink Resource).

Le réseau 5G propose deux autres solutions SDT nommées RA-SDT et CG-SDT. La technologie RA-SDT est proche de la solution EDT et la technologie CG-SDT est proche de la solution PUR.

Cet article est la continuité de la présentation de l’IoT Cellulaire (https://blogs.univ-poitiers.fr/f-launay/2017/05/28/mtc-le-reseau-m2m-iot-sur-la-4g-1ere-partie/) et je vais reprendre l’article sur le canal PRACH  : https://blogs.univ-poitiers.fr/f-launay/2020/05/02/etablissement-de-la-connexion-radioelectrique-comparaison-4g-et-5g/

Etude du signal d’accès aléatoire

Le signal d’accès aléatoire sur l’interface radioélectrique LTE est généré par le mobile selon la formule suivante :

La séquence Xu,v est une séquence de Zadoff-Chu (ZC). La séquence de PRACH s’appuie sur une séquence de ZC dans le domaine fréquentiel et la formule précédente permet d’appliquer la transformation du signal vers le domaine temporel.

La liste des préambules est transmises à l’UE via le message d’information système SIB2. La station de base propose une liste voire deux listes par cellule, chaque liste contient 64 préambules.

Un préambule racine est une séquence pseudo-aléatoire de Zadoff-Chu (ZC) qui est définie par la valeur de la racine. Les préambules de la liste sont obtenus à partir d’un décalage cyclique Cv du préambule racine.

Un nombre fixe de 64 préambules est alloué pour chaque cellule et en fonction de la longueur de décalage cyclique NCS, une ou plusieurs séquences racine d’accès aléatoire sont nécessaires par cellule pour générer les 64 préambules.

PREAMBULE PRACH (Accès Aléatoire)

Le préambule PRACH est constitué d’un préfixe cyclique de longueur TCP et d’une séquence de longeur TSEQ.

Figure 1 : Le préambule PRACH

Les longueurs TCP et TSEQ  dépendent de la structure de la trame (type 1 : FDD ou type 2 : TDD) et de la configuration définie au niveau de la couche RRC de l’accès aléatoire selon l’un des quatre formats ci-dessous :

Table 1 : La configuration de la séquence PRACH

Il convient de noter que durée de la séquence d’apprentissage définit la couverture de la cellule pour estimer correctement l’avance de synchronisation. Si eNodeB reçoit des préambules au-delà de la plage de cellules définie, l’estimation de l’avance temporelle sera erronée et l’accès aléatoire, la procédure échouera, ce qui entraînera de nouvelles tentatives de la part de l’UE.

Table 2 : La couverture de la cellule

 Les préambules par cellule sont divisés en deux sous-ensembles

La transmission du préambule PRACH est déclenché soit par la couche MAC (demande d’accès avec contention), soit par la couche RRC de la station de base (demande d’accès sans contention). L’étude porte sur la demande d’accès avec contention.

Lorsque le préambule est déclenché par la couche MAC de l’UE, la transmission de la requête d’accès doit être transmises sur des ressources tempo/fréquentielle définies par l’eNB, c’est à dire sur des fenêtres temporelles spécifiques correspondant à un numéro de sous-trame dans une trame (trame paire, impaire ou toutes trames) et sur des emplacements fréquentiels correspondant à des blocs de ressource. Les ressources tempo-fréquentielles autorisées sont transmises de l’eNB à tous les terminaux par le message de diffusion d’information SIB2 :

  • L’instant de transmission est défini via l’index PRACH-Configuration. Le numéro d’index de configuration PRACH, sur 6 bits (valeurs 0 à 63), permet de savoir dans quelle(s) sous-trames le PRACH peut être transmis sur chaque sous trame ou uniquement sur les sous trames paires
  • Le décalage prach-FrequencyOffset détermine la position du bloc de ressource (PRB) contenant la séquence dans le domaine fréquentiel

Table 3 : Table de configuration de l’index de configuration PRACH  [1]

PREAMBULE NPRACH (Accès Aléatoire)

A l’instar du LTE, les informations sur la procédure d’accès aléatoires sont transmises via le SIB2. On trouve la périodicité des demandes d’accès aléatoires, l’instant de transmission, la première sous-porteuse et le nombre de sous-porteuses allouées à la demande NPRACH, le nombre de répétition de la transmission du préambule.

La figure suivante est extraite du site : https://www.sharetechnote.com/html/Handbook_LTE_NB_rach.html


Figure 2 : Les sous porteuses NPRACH (informations SIB2)

Le signal NPRACH est donc transmis dans les ressources tempo-fréquentielles spécifiées dans le message SIB2.

Figure 3 : La transmission du NPRACH (exemple)

Dans le cas du NB-IoT, il n’y a que deux formats de préambules. Les préambules sont toujours composées d’un préfixe cyclique CP et d’une séquence.

Figure 4 : Comparaison des préambules entre le l’interface LTE et l’interface NB-IoT [1]

 La séquence du préambule PRACH/NPRACH

La séquence du préambule PRACH/NPRACH est issue du générateur de Zadoff-Chu :

Avec u, la racine de Zadoff-Chu,  la longueur de la séquence (en général 839)

La station de base transmet au mobile un index de racine. La correspondance entre l’index et la racine de Zadoff-Chu est indiquée dans la table 4.

Les séquences cycliques sont calculées à partir de

Table 4 : La correspondance entre l’indice de la séquence RACH et la racine de Zadoff-Chu [2]

La valeur de Cv est calculée par l’équation suivante :

La valeur de NCS est définie par la table 4 à partir de la valeur ZeroCorrelationZoneConfig transmise dans le message SIB2

Figure 5 : Le message SIB2

Table 5 : Les valeurs de NCS [3]

Il y a une ou au plus deux listes de 64 séquences par cellule. Les 64 séquences d’une liste sont extraites à partir de tous les décalages cycliques possible de la séquence racine (root). La valeur racine est transmise par la station de base via le SIB2 dans le message RACH_ROOT_SEQUENCE (pour la 1ère liste de 64 séquence) et dans le message ROOT_SEQUENCE_INDEX_HI si une deuxième liste est gérée.

 

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.

La spécification O-RAN : le decoupage 7.2

Dans cet article, nous allons nous intéresser à la spécification O-RAN et plus particulièrement à la partie de découpage de la couche basse LLS (Low Layer Split) c’est-à-dire à la séparation des fonctions entre l’unité radio RU et l’unité distribuée DU. Il existe plusieurs options numérotées de 1 à 8 décrivant un découpage entre les fonctionnalités intégrées à l’unité RU (Radio Unit), DU (Distributed Unit) et CU (Central Unit) faisant ainsi apparaitre de nouvelles interfaces (fronthaul/midhaul/backhaul).

Figure 1 : Le découpage radioélectrique et les interfaces

L’option 7.2 propose un découpage de la couche physique basse (LLS ) au niveau du RU et la couche physique haute au niveau du DU. Elle est souvent associée à l’option 2 pour le CU.

 

Figure 2 : L’architecture protocolaire de la station de base et l découpage des fonctions radio

Le découpage a un impact sur les performances de transmission :

Figure 3 : Le découpage et la qualité de service

L’interface entre l’unité RU et DU est nommée fronthaul et les données utilisateurs ainsi que la manière dont les données seront émises (mode de transmission) sont transportées par un bus série eCPRI. Pour pouvoir gérer les données, le fronthaul transporte également une couche de gestion et une synchronisation.

Figure 4 : L’interface Open-Fronthaul [1]

La transmission des données du plan de contrôle et le plan utilisateur entre l’unité O-RU et l’unité O-DU est gérée au niveau de la couche 2 avec un service l2VPN VPWS ou eVPN VPWS, les données du plan de gestion sont transportées par le protocole IPv4 ou IPv6.

Figure 5 : Le transport des plans de données et de gestion entre le DU et le RU

L’unité radio converti le signal numérique en signal radio et inversement. Les fonctionnalités dédiées à l’O-RU pour le découpage O-RAN version 7.2 :

  • Synchronisation (GPS/IEEE 1588) et transport Fronthaul (eCPRI)
  • Gestion de la couche physique basse (FPGA ou ASIC)
  • Front end (radio et numérique) : Convertisseur et pre-distorsion, amplificateurs

Figure 6 : l’architecture physique de l’O-RU [2]

Pour résumer, voici les principaux avantages et inconvénient du découpage des fonctions :

Figure 7 : Les avantages et inconvénients du découpage (source CISCO)

Le découpage 7.2 présente quatre avantages :

  1. Le transfert des données du plan utilisateur correspond à des éléments de ressources ce qui permet de gérer la correspondance des données (RE Mapping) au niveau du DU et limite le nombre de message de contrôle vers le RU ;
  2. L’adaptation de la bande de transport des données est basée sur le nombre de flux (stream) et non sur le nombre d’antennes :
  3. La gestion des faisceaux peut être numérique/analogique ou hybride.
  4. La simplification de la gestion de l’interférence intercellule ICIC et de la coordination multipoint (COMP) qui est gérée au niveau de l’unité DU

De plus, concernant le découpage 7.2, deux modes distincts de fonctionnement ont été définis selon que la précodage est situé au niveau de l’O-RU ou de l’O-DU

  • O-RU catégorie A

Le précodage est réalisé au niveau du DU. L’interface fronthaul transporte des flux séparés spatialement (stream). Cela peut nécessiter une charge plus élevée par rapport au transport d’une couche. Le Beamforming Numérique et analogique sont optionnels

  • O-RU catégorie B

Le précodage est réalisé au niveau du RU. L’interface fronthaul transport une couche réduisant ainsi la charge de la payload par rapport à la cat A mais le codeur est plus complexe. Le Beamforming Numérique et analogique sont optionnels

Pour comprendre la différence entre les deux catégories, il est intéressant de reprendre le schéma d’une chaîne de transmission MIMO :

Figure 7 : le synoptique d’une chaîne de transmission MIMO

Une couche est définie comme un chemin d’entrée de codage et de modulation vers le codeur MIMO. Un flux est défini comme la sortie de l’encodeur MIMO qui est ensuite traitée via la formation de faisceau ou le bloc de précodeur.

Figure 8 : Les deux catégories A/B du découpage radio fonctionnelle 7.2 [3]

La catégorie A permet de simplifier la conception de la partie radio (figure 8), laquelle n’a pas à gérer la matrice de précodage sur les flux.

L’exemple suivant (figure 4) présente la cas du MIMO. Figure 9: Découpage fonctionnel 7.2

A travers le plan de contrôle C-plane, l’unité O-DU informe l’unité O-RU du traitement à accomplir en transmettant le précodage a effectuer.

Figure 10 : La gestion du BeamForming selon la matrice de précodage calculée au niveau de l’unité O-DU[3]

 A partir de la solution XILINX [2], nous allons voir le découpage fonctionnel de l’unité O-RU cat B connectée à une antenne massive MIMO 64T64R.

L’unité O-RU est composée de 5 sous unités :

  • Une sous unité d’interface ISU (Interface SubUnit)
  • Quatre sous unité radio RSU (Radio SubUnit)

L’unité ISU reçoit des trames eCPRI via l’interface ethernet, et récupère la payload, c’est-à-dire les symboles I/Q. Les symboles sont multipliés par la matrice de précodage H18×64 permettant de générer 64 flux qui seront répartis sur les 4 sous unités radio RSU.

Chaque RSU traite en parallèle les 16 flux en réalisant l’IFFT sur le signal I/Q et en ajoutant le préfixe cyclique, puis une calibration, et un premier convertisseur en fréquence (DUC : Digital Up Converter) et une pré-distorsion (PDP) et/ou une réduction du facteur crête (CPR Crest Factor Reduction) est effectuée avant amplification.

Figure 11 : Le synoptique et l’implémentation Xilinx du O-RU

La partie antennaire est composée de brin rayonnants avec deux polarités, chaque RSU gère un panneau antennaire. L’antenne est constituée de 4 panneaux.

Sur la figure 12, il y a 128 éléments d’antennes pour 64 émetteurs/récepteurs (transceiver 64T64R) en connectant deux éléments d’antennes de même polarité au même port d’antenne.

Figure 12 : Antenne Massive MIMO avec 128 éléments rayonnants

 

[1] https://www.youtube.com/watch?v=KAW4LHK31Ek
[2] https://www.techplayon.com/o-ran-open-radio-unit-o-ru-reference-architecture/
[3] https://online-events.keysight.com/keysight-technologies7/Massive-MIMO-O-RAN-Radio-Units-O-RU-Design-and-Conformance-Test-Challenges?show_live_page=true&add_to_calendar=true&bmid=4f5ae43d7e8c

 

 

Du Maillage de service au Service Communication Proxy SCP

  1. Introduction : du SOA aux micro-services

L’évolution majeure entre le réseau 4G-CUPS et le réseau 5G repose sur le choix d’une architecture orientée service (demandeur de services/fournisseur de services). Les fonctions réseaux sont des composantes logicielles (NF : Network Function) ré-utilisables, qui échangent des informations les unes vers les autres à travers une interface de service SBI (Service Based Interface).

Les services sont exposés en utilisant des protocoles standards (SOAP, Thrift, JSON) permettant d’imposer le format des messages échangés. Dans le cas de la 5G, le format des données est le JSON et le protocole d’échange se fait en HTTP2. Chaque service récupère, crée ou modifie une ressource. L’écriture se fait en utilisant les commandes POST ou PUT et la lecture en utilisant la commande WGET.

 

Une composante réseau logicielle (NF) est une unité autonome qui réalise une ou plusieurs tâches.

 

Chaque fonction est conçue pour réaliser une tâche ou des tâches précises comme récupérer des informations (exemple : l’identité du mobile lors de son attachement) ou exécuter une opération (exemple : mettre en œuvre un tunnel). Une fonction contient le code logiciel et les données nécessaire pour réaliser la liste des tâches associées à cette fonction.

 

Dans une architecture orientée services, les services communiquent entre eux via un système de couplage faible. Le couplage faible permet de réduire la dépendance entre les éléments du réseau, ce qui permet d’accélérer les mises à jour de fonctionnalité du réseau pour répondre à de multiples cas d’usages (Segments verticaux du marché).

Ainsi, par rapport aux entités fonctionnelles monolithiques du cœur de réseau 4G (cf. https://blogs.univ-poitiers.fr/f-launay/2021/02/26/architecture-sba-du-reseau-5g-microservices-et-soa/), l’architecture basée sur les services permet :

  • Une plus grande flexibilité et une innovation plus rapide : la ré-utilisation des fonctions accélère la mise en production d’une application car les développeurs utilisent des lignes de codes déjà exploitables
  • Une ouverture vers des nouveaux segments (agriculture, entreprise, …) par le biais d’exposition de service (API ouvertes)
  • Une maintenance et une évolution facile : les services étant autonomes (couplage lâche), il est plus facile de les modifier sans impacter le réseau, ou de créer des fonctions évoluées pour des solutions innovantes tout en maintenant les précédentes versions.

Le concept SOA est un des pilier du Cloud Computing. Le Cloud Computing porte l’architecture SOA à une échelle plus importante (en comparaison, le Cloud Computing est au WAN ce que le SOA est au LAN).

Plus précisément, le Cloud Computing exploite des composantes logicielles pouvant communiquer entre eux sans états (stateless) nommées micro-services. Le langage de programmation d’un micro-service est indépendant des autres micro-services.

L’usage des micro-services est grandement facilité par les techniques de conteneurisation. Les micro-services faiblement couplés sont déployés dans des conteneurs et connectés via des API ou via un réseau de services maillé (MESH Service) pour le routage des messages.

Lorsque le nombre de micro-service augmente, la gestion des communications entre chaque micro-service se complexifie. Le premier rôle du maillage de service (MESH Service) est de gérer l’échange très important des données entre les micro-services.

L’architecte 5G est une architecture basée sur le service (SBA : Service Base Architecture). L’architecture SBA fournit une architecture orientée services (SOA) pour héberger des composants de plan de contrôle distincts de différents fournisseurs avec des cycles de développement disparates qui pourraient facilement inter fonctionner et interagir pour fournir un sous-système 5G complet ou une offre de services.

Avec l’architecture SOA et SBA, de nombreuses fonctions réseaux sont lancées, avec un nombre d’instances permettant de prendre en charge le trafic de signalisation. A la différence du SOA, l’architecture SBA introduit la fonction NRF qui est un annuaire listant les instances déployées : chaque instance d’une fonction de réseau annonce sa disponibilité à la fonction NRF avant d’initier une connexion est-ouest et participer à la livraison d’une application ou d’un service plus important.

Figure 1 : L’architecture SBA et la fonction de découverte NRF

Toutefois, à l’instar du SOA, la difficulté est la répartition de charge de trafic de signalisation entre les fonctions.

 

2. Le maillage de service – Service MESH

Un service MESH a pour objectif de contrôler l’échange des données de services partagées entre les instances logicielles (micro-service ou fonctions NF).

Un micro-service est conçu pour échanger des données au niveau applicatif. Le service MESH introduit une couche d’infrastructure dédiée en intégrant dans l’application des PROXYS nommés SIDECAR (imaginez le sidecar d’une moto pour prendre en charge non pas une personne mais un service) afin d’optimiser l’échange de données.

Avec le maillage de service, les requêtes s’effectuent à travers des PROXYS implémentés en sortie des micro-services.

Figure 2 : Modèle SideCar [1]

Sans Sidecar, la composante logicielle devait compiler une bibliothèque de communication spécifique au langage pour gérer la découverte de services, les routages et les exigences de communication non fonctionnelles au niveau applicatif (couche 7).

Figure 3 : De kubernetes au Maillage de services [2]

Le maillage de service permet de plus de réaliser de la surveillance réseau en fournissant des statistiques sur les performances des communications entre les services. Ces performances permettent ainsi de mettre en œuvre des fonctionnalités d’équilibrage de charge, de modification de route (exemple : la réponse d’une instance à un service met trop de temps par rapport à une autre instance pour le même service, le proxy va donc choisir cette dernière instance).

La solution de maillage de service OpenSource ISTIO [3,4] permet ainsi :

  • La gestion de trafic par une configuration des règles de services entre les micro-services
  • La sécurité en introduisant des fonctions d’authentification, d’autorisation (OAuth2) et de chiffrement des communications
  • Observabilité

Figure 4 : La journalisation des messages

3. SCP : Service Communication Proxy

Le service side-car ne fait pas nécessairement partie de l’application, mais il est connecté à celle-ci. Il est présent partout où l’application parente est présente.

Figure 5 : Le principe du maillage de service [5]

Le service n’a pas connaissance du réseau, mais ne connait que le proxy sur lequel il est connecté.

Le proxy réalisant les fonctions suivantes :

  • La découverte de services
  • Le routage
  • L’équilibrage de charges
  • L’authentification et l’autorisation
  • L’observabilité (statistique, log, traces)
  • Le bon fonctionnement (et éventuellement le transfert via une réponse 3XX ou une erreur de service 5XX)

Le standard 3GPP a introduit le proxy SCP dans la R16 [6]. De ce fait, l’architecture SBA n’a pas besoin du proxy SCP dans son principe de fonctionnement. Mais dans le cas de fonction NF multi-distribués, le SCP va résoudre les problématiques de trafic de signalisation en fournissant un point d’entrée unique pour un groupe de fonctions réseau (qui sont enregistrées dans la fonction NRF). Cela permet au SCP de devenir le point de découverte délégué dans un centre de données, déchargeant le NRF des nombreux maillages de services distribués. Les règles de routage du SCP peuvent s’appuyer sur une ressource, un numéro de téléphone ou un identifiant IMSI. Dans le monde des Télécom, par comparaison (et abus de langage), le SCP joue un rôle similaire au proxy et routeur DIAMETER. Il s’agit d’une simple comparaison, le SCP permet l’échange de signalisation dans le réseau d’un opérateur, les agents DIAMETER DRA permettaient de mettre en relation tous les HSS/MME inter-opérateurs (et auparavant, le routage de la signalisation était géré par le réseau SS7 et les points sémaphores STP).

Figure 6 : SS7 -> DIAMETER -> HTTP2 – SCP

Le SCP est un sidecar centralisé, il a pour rôle de gérer la communication de services à services s’il est impliqué. En ce sens le SCP est attaché à chaque NF. Le rôle du SCP inclut l’interfonctionnement entre NF, la segmentation des services, le contrôle d’accès centré sur les services et l’équilibrage de charge. Le SCP apporte donc une abstraction réseau ce qui permet aux développeurs d’applications d’être indépendants de l’infrastructure.

Le SCP n’est pas une fonction réseau, il n’expose pas de service contrairement aux NF. Deux fonctions NF peuvent s’échanger des services directement ou indirectement en passant par le proxy SCP.

Figure 7 : Communication directe/indirecte de deux NF [6 – Fig 7.1.1.1]

Les rôles du SCP sont :

  • D’apporter une fiabilité des services NF.

[6] 5.21.3.4 Reliability of NF Services Si une défaillance de l’instance de service NF est détectée ou notifiée par la NRF (exemple plus disponible), le consommateur de service NF ou SCP sélectionne un autre NF Service Instance de service du même ensemble de services NF dans l’instance NF.

  • De sélectionner la fonction NF adéquate : une fonction NF (consommateur de service) interroge le SCP en transmettant les attributs souhaités de la fonction NF (producteur de service). A partir de ces informations suivantes permettent au SCP de trouver la fonction SMF (DNN, capacité UE, localisation)
  • Le transfert et le routage de message de signalisation
  • Les services de sécurités (ex : autorisation qu’un consommateur de service puisse accéder à l’API d’un producteur de service)
  • L’équilibrage de charge et contrôle de surcharge de trafic
  • Surveillance du réseau
  • Optionnellement interagit avec la base de donnée unifiée UDR pour la résolution de nom (IMSI, IMPI/IMPU, Identité UDM/HSS

 

Figure 8 : Implémentation du maillage de service via le SCP

Le maillage de service et le proxy SCP ajoute de la latence. Dans le cas du service MESH, au moins deux sauts de réseau supplémentaires sont ajoutés lorsqu’un service communique avec un autre service (le premier provient du proxy qui gère la connexion sortante de la source et le second provient du proxy qui gère la connexion entrante de la destination).

Pour l’architecture SBA, la communication entre service peut être directe ou indirecte, c’est-à-dire en passant par le SCP. Quoiqu’il en soit, la latence est sur le plan de contrôle et non le plan de transport.

 

Pour en savoir plus :

  • Linkerd, Istio, Consul, Kuma et Maesh.
  • https://www.infoq.com/fr/articles/service-mesh-ultimate-guide/
  • https://carrier.huawei.com/~/media/cnbgv2/download/products/core/strategy-analytics-5g-signaling-en.pdf

Références :

[1] https://docs.microsoft.com/fr-FR/azure/architecture/patterns/sidecarTS23.501 – System architecture

[2] https://jimmysong.io/en/blog/service-mesh-the-microservices-in-post-kubernetes-era/

[3] https://istio.io/

[4]  https://www.redhat.com/fr/topics/microservices/what-is-istio

[5] https://blog.envoyproxy.io/service-mesh-data-plane-vs-control-plane-2774e720f7fc

[6]  TS 23.501(3GPP  version 16.6.0)  System Architecture for the 5G System.

[7] https://www.metaswitch.com/blog/the-service-communication-proxy-5g-caught-up-in-a-service-mesh