Archives de l’auteur : flaunay

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

Posté le by - 976 vues
Répondre

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

Posté le by - 1 016 vues
Répondre

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

Posté le by - 1 143 vues
Répondre

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

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

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

Figure 1 : Applications pour l’audio professionnels

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

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

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

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

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

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

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

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

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

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

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

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

III) Le routage MESH

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

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

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

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

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

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

IV) La couche radio

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

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

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

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

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

 

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

La couche physique réalise les fonctions suivantes :

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

IV) Le cœur de réseau

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

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

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

Références :

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

La 5G Privative – NPN Non Public Network

Posté le by - 1 452 vues
6

I – Introduction

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

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

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

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

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

II – Le réseau NPN pour quelles applications?

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

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

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

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

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

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

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

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

3-1) Modèle SPNP

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

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

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

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

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

Figure 2 : Modèle SNPN

3-2) Modèle PNI-NPN

L’architecture PNI/NPN nécessite :

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

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

a) Mutualisation du RAN

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

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

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

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

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

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

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

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

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

IV – La sélection de la station de base

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

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

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

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

V – La mise en sécurité

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

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

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

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

VI – Les technologies 5GLAN, TSN et ATSSS

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

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

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

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

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

Figure 5 : La fonction TSN AF [4]

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

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

Références

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

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

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

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

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

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

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

La Mutualisation de l’accès radio : RAN SHARING

Posté le by - 1 093 vues
4

Je remercie Rafika Rezgui (responsable New Deal Bouygues Télécom ) et Hugues-Antoine ROUSSILLO (Chef de projet Programme Réglementaire Bouyues Télécom) pour la relecture et les explications fournies qui ont contribuées à l’amélioration de l’article.

I) La mutualisation du RAN – RAN SHARING

L’architecture des réseaux de mobiles fait une séparation entre le réseau d’accès radio (RAN Radio Access Network) et le cœur de réseau (CN : Core Network).

Le partage du réseau (Network Sharing) a pour objectif de réduire les coûts de déploiement en partageant une partie du réseau entre opérateurs.

Selon la définition de l’ARCEP [1]: le partage de réseaux mobiles correspond à la mise en commun entre plusieurs opérateurs de tout ou partie des équipements constituant leurs réseaux mobiles.

 On distingue ainsi plusieurs solutions sur le partage de l’accès radio :

  • Location de site (Tower Companies)  nommée partage d’infrastructure passive : chaque opérateur installe ses équipements actifs (antennes mobiles) sur une infrastructure passive partagée (pylône) ;
  • La mutualisation active des réseaux (RAN Sharing)
    • Avec partage de fréquences MOCN (Multi-Operator Core Network) : la station de base (ou le cœur d’accès radio) est connectée au cœur de réseau de plusieurs opérateurs et les porteuses de fréquence de chaque opérateur sont combinées. Les clients d’un opérateur peut donc accéder à l’ensemble des fréquences de l’ensemble des opérateurs [2]
    • MORAN (Multi-Operator RAN) : La station de base est partagée entre plusieurs opérateurs mais chaque opérateur dispose de sa propre bande de fréquence. Les équipements mis en place par un des opérateurs émettent les fréquences des autres opérateurs mais chaque client n’a accès qu’aux fréquences de son opérateur. (exemple : Accord Crozon entre SFR et Bouygues)
  • Full MVNO ou itinérance : un opérateur loue et utilise les fréquences d’un autre opérateur hôte qui accueille sur son réseau ses clients
  • L’architecture GWCN (Gateway core network) pour laquelle plusieurs opérateurs partagent l’accès RAN et l’entité MME. L’entité MME doit évidemment supporter l’option RAN Sharing et doit pouvoir délivrer une liste de restriction d’eNB pour la continuité d’appels HO (Handover).

Figure 1 : La mutualisation du réseau de mobiles [1]

II) Exemple du New Deal

L’accord New Deal est un engagement imposé par le gouvernement aux opérateurs Français pour avoir une bonne couverture du réseau mobile. Cet engagement est encadré par l’ARCEP qui définit La notion de « bonne couverture ».

Une bonne couverture permet de téléphoner et d’échanger des SMS à l’extérieur des bâtiments dans la plupart des cas, et, dans certains cas, à l’intérieur des bâtiments (cf. https://www.arcep.fr/cartes-et-donnees/nos-cartes/la-couverture-4g-en-france-par-departement.html)

Le New Deal s’appuie sur la mutualisation radio (RAN SHARING). Le « New Deal » a pris la forme d’un « gentlemen’s agreement » matérialisé dans un échange de lettres, suivies d’annonces.

Le new deal utilise la mutualisation de l’accès radio (RAN Sharing) avec partage de fréquence (MOCN) ou sans partage de fréquence (MORAN).

La mutualisation MOCN est favorisée dans les zones blanches et la mutualisation MORAN dans les zones moins denses. Toutefois, Hugues-Antoine ROUSSILLO précise : « en cas de charge, la bande passante est limitée à ¼ des ressources par opérateur en MOCN ».

III) Les évolutions du spectre radiomobile

A partir de 2024, les plans de fréquences à 900 MHz, 1800 MHz et 2100 MHz seront équilibrés entre les opérateurs (suivant [3]) :

Tableau 1 : Bande de 900 MHz

Tableau 2 : Bande de 1800 MHz

Tableau 3 : Bande de 2100 MHz

Notes 

Le NB-IoT ne supporte pas le RAN SHARING (jusqu’à la R.17)

 

Références

[1] https://www.arcep.fr/la-regulation/grands-dossiers-reseaux-mobiles/le-partage-de-reseaux-mobiles.html

[2] Rapport de la cours de comptes : Réduire la fracture numérique mobile (Juin 2021) : https://www.ccomptes.fr/sites/default/files/2021-09/20210928-58-2-reduire-fracture-numerique-mobile-4G.pdf

[3] Décision n° 2018-1306 du 23 octobre 2018 : https://www.legifrance.gouv.fr/jorf/id/JORFTEXT000038057322

Déploiement de la 5GC

Posté le by - 906 vues
Répondre
  1. Architecture du cœur de réseau 5GC

Le cœur de réseau 5GC est déployé selon l’architecture a 3 niveaux :

  • les instances des fonctions réseaux sont exécutées au sein de DataCenter central
  • un Datacenter régional avec le plan de trafic
  • un Datacenter de proximité (Edge Datacenter) avec le MEC et le CDN

Figure 1 : Architecture 3 niveaux [1]

      2. Fiabilité du réseau : Redondance

Afin de fiabiliser le cœur de réseau, le déploiement des fonctions 5G s’appuient sur la redondance de fonctions dans des Datacenter séparés (DC1/DC2) selon une approche active/active, active/passive ou sur une redondance dans un pool.

La redondance active ou passive sont mises en œuvre pour les fonctions NRF, NSSF, SMSF, UDM, et UPCF alors que la redondance par pool est utilisée pour les fonctions AMF, SMF et UPF.

II-a) La redondance active/passive

La redondance active/passive représente une paire de fonction NF et seule la fonction active apporte le service demandé, la fonction passive est vue comme un backup. Les deux NF échangent un message Heartbeat (battement de cœur) c’est-à-dire un ping envoyé à un intervalle de pulsation régulier configuré.

Figure 2 : La redondance active/passive

Le HeartBeat est un système de haute disponibilité sous Linux (LinuxHA High Availability), mettant en cluster, c’est-à-dire en groupe, plusieurs fonctions. Le processus Heartbeat se chargera de passer les communications aux serveur actif si celui-ci est vivant et au serveur passif le cas échéant.

Sous linux, installez le paquet Heartbeat (apt-get install heartbeat)
et configurez le fichier /etc/heartbeat/ha.cf de la même manière
sur les deux serveurs.

II-B) La redondance active/active

La redondance active/active chaque NF déployée sur 2 DC différents répondent aux services demandés. Les données de backup peuvent être transmises d’une NF active à une autre, mais n’est pas obligatoire.

II-C) La redondance par pool

Les fonctions NFs sont regroupées dans un pool et chaque NF répond aux services demandés. Quand une fonction NF tombe en panne, les autres prennent le relai.

Les fonctions AMF sont regroupées selon l’architecture mesh, c’est-à-dire décentralisée et par type de service à supporter.

Un pool de SMF permet de connecter plusieurs SMF pour contrôler plusieurs UPF sur une zone radio donnée

Figure 3 : Le regroupement des NF

II-D) La surveillance des états

Les fonctions NF du cœur de réseau vérifient l’état des autres fonctions NF couplées via des messages ping à travers l’interface SBI ou des notifications de souscriptions pour la fonction NRF.

Sur l’interface point à point, les fonctions NF vérifient le lien à travers des messages Heartbeat via l’association SCTP ou le lien PFCP.

Figure 4 : La surveillance des états [1]

La fonction NRF est la première instance qui est exécutée lorsqu’on souhaite démarrer un nouveau cœur de réseau. Le NRF répertorie toutes les fonctions réseaux NF. Lors de la procédure de démarrage, une fonction NF vient s’enregistrer au niveau du NRF via une requête http.

Figure 5 : L’enregistrement de la fonction SMSF [2]

Pour la fiabilité du réseau, la fonction NRF fonctionne par paire : les opérateurs copient de manière active le NRF du DC1 vers le DC2.

La fonction NSSF assure la mise en œuvre du network slicing. Pour la fiabilité du réseau, les opérateurs déploient une paire de NSSF.

 

[1] Huawei : Deploy and apply 5G Core

[2] https://nickvsnetworking.com/if-you-like-pina-coladas-and-service-the-control-plane-intro-to-nrf-in-5gc/

 

La transmission PUR (IoT – EPC/5GS)

Posté le by - 473 vues
Répondre

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Le déploiement d’un réseau 5G SA (cloud privée ou publique)

Posté le by - 1 083 vues
Répondre

I) Introduction

L’évolution de la 4G vers la 5G n’est pas uniquement une virtualisation des entités 4G (ex: DECOR ou eDECOR – Dedicated Core) mais un déploiement automatisé des fonctions réseaux sur une architecture basée sur les services (SOA).

Une application est dite « native pour le cloud », lorsqu’elle est conçue autour d’instances gérées de façon automatisée dans les clouds privés, publics et hybrides. Aujourd’hui, les entreprises adoptent le Cloud Computing  [1] pour améliorer l’évolutivité et la disponibilité de leurs applications.

Le principal avantage d’une stratégie cloud-native est qu’elle permet d’accélérer le développement des applications dont les ressources de calcul sont réparties dans différents environnements [2].

Selon [1], « le cloud computing consiste à exécuter des charges de travail dans des clouds, des environnements qui dissocient, regroupent et partagent des ressources évolutives sur un réseau. »

Les concepteurs DevOps réalisent une architecture composée de ressources en libre-service et à la demande ainsi qu’à l’automatisation du cycle de vie des applications (de la phase de développement jusqu’à la production).

La 5G est dite cloud Native, la 3GPP propose une architecture composée de fonctions réseaux (NF) faiblement couplées. Une fonction réseau peut être découpée en microservices qui communiquent entre elles via des interfaces de programmation d’application (API).

Dans une architecture de microservices, les applications sont décomposées en éléments les plus simples et indépendants.

Les interfaces de programmation d’application (API) sont des ensembles d’outils, de définitions et de protocoles qui facilitent la création de fonctions d’applications (réseau). Elles connectent les producteurs de services et les consommateurs de services sans connaître les détails de leur mise en œuvre [1].

Le modèle DevOps est une approche d’automatisation et de conception de plateformes pour une solution logicielle complexe [3].

II) Cloud Public, privé, hybride, multicloud

Selon [1] :

Cloud Public : Environnements cloud créés à partir de ressources qui n’appartiennent pas à l’utilisateur final et qui peuvent être redistribuées à d’autres clients.

Cloud Privé : Généralement décrits comme des environnements cloud réservés à l’utilisateur final, la plupart du temps à l’intérieur du pare-feu et parfois sur site.

Cloud hybride : Plusieurs environnements cloud qui offrent différents degrés de portabilité, d’orchestration et de gestion de la charge de travail.

Multicloud : Systèmes informatiques qui comprennent au moins deux clouds (privés ou publics) qui peuvent être mis en réseau ou non.

Un cloud public est un pool de ressources virtuelles, créées à partir de matériel détenu et géré par une entreprise tierce, qui sont automatiquement provisionnées et allouées à différents clients via une interface en libre-service. Il s’agit d’une méthode simple qui permet de faire évoluer les charges de travail soumises à des fluctuations imprévues de la demande.

Déploiement de la 5G SA sur un Cloud Public

Les entités du coeur de réseau 2G/3G/4G stockent des informations, nommées contextes, relatives aux utilisateurs ou à l’association de couche transport (Tunnels). Ces contextes doivent être résilientes à toutes pannes.

La 3GPP propose une architecture sans état (Stateless) pour optimiser le déploiement des fonctions réseaux, en découplant le stockage des contextes et les couches applicatives. Les données sont sauvegardées dans des fonctions UDSF (Unstructured Data Storage Function [5]).

A titre d’exemple, le Cloud Public Amazon propose Elasticache et Google propose Google Cloud Memorystore, l’un et l’autre surtout connus pour leur capacité à sauvegarder des données en mémoire rapide de type NoSQL (REDIS : Remote Dictionary Server – Serveur de dictionnaire à distance).

Le découpage du réseau en tranche (Network Slicing) s’appuie sur l’architecture Cloud Native et les technologies SDN/NFV pour apporter des services à faible latence, haut débit, …

Les microservices n’ont pas nécessité de s’appuyer sur des conteneurs, néanmoins les solutions K3s ou K8s apportent plus de la flexibilité et de la scalabilité des fonctions réseaux par rapport aux VM.

Dans le cas de l’architecture NFV [6], une solution basée sur les VM nécessite des gestionnaires spécifiques S-VNFM (vendor-specific VNF manager) ou générique (generic VNF manager) pour la gestion des durées de vie des VMs.

Une application basée sur Kubernetes permet de gérer la durée de vie des conteneurs et des fonctions réseaux NF.

Les conteneurs permettent de gérer efficacement les fonctions du cœur de réseau (AMF/SMF/…).

Par contre les fonctions UPF sont plutôt distribués sur les MEC et la localisation étant imposée, la gestion par VM est plus efficace.

L’approche Cloud Native impose également un seul protocole http2 entre les fonctions réseaux, à l’exception du protocole PFCP sur l’interface N4.

Au niveau du plan de transport, l’établissement d’une session PDU signifie que le réseau 5G transporte du trafic Ethernet, IP ou non structuré. L’utilisation de PoD multi-homed permet d’avoir plusieurs interfaces et permet aussi de gérer différents protocoles (SCTP par exemple)

[1] https://www.redhat.com/fr/topics/cloud

[2] https://www.redhat.com/fr/topics/cloud-native-apps

[3] https://www.redhat.com/fr/topics/cloud-native-apps

[4] https://d1.awsstatic.com/whitepapers/5g-network-evolution-with-aws.pdf

[5] TS 21.195

[6] https://www.etsi.org/technologies/nfv

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

Posté le by - 1 296 vues
Répondre

Introduction

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

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

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

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

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

II) L’architecture 3GPP

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

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

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

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

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

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

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

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

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

Figure 3 : Les messages en cas de HandOver

 

III) L’architecture O-RAN

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

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

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

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

Figure 4 : Architecture O-RAN [3]

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

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

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

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

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

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

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

 

[1] TS 38.401

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

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

[4] TR 38.801

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

Posté le by - 705 vues
Répondre

La couche SDAP (Service Data Adaptation Protocol)

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

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

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

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

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

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

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

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

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

Conclusion

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

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

Figure 2 : Les couches protocolaires de l’interface radio

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

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

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