Archives de l’auteur : flaunay

NAE Network Automation Enabler : mécanismes d’automatisation et d’intelligence artificielle intégrés au cœur du réseau 5G

Posté le by - 96 vues
Répondre

La fonction NWDAF et les évolution pour l’automatisation intelligente du cœur de réseau

Introduction : vers un réseau qui se pilote lui-même

Cet article présente un ensemble de mécanismes et fonctions (NAE) que le 3GPP a standardisé pour permettre l’automatisation et l’intelligence du réseau 5G.

L’objectif est de permettre au réseau de :

  • détecter, en temps réel, qu’une zone est surchargée,
  • prédire les comportements anormaux d’équipements compromis,
  • ajuster automatiquement la qualité de service d’un flux vidéo selon les conditions radio du moment

sans intervention humaine

Cet article présente l’évolution de cette architecture d’automatisation, telle que décrite dans la publication Highlights du 3GPP (décembre 2024), rédigée par les responsables du groupe de travail CT3 (Core Network and Terminals, Working Group 3). Nous couvrirons l’évolution de la Release 15 à la Release 19, en explicitant les concepts clés.

Figure 1 : Évolution de l’architecture d’automatisation des réseaux et définition des cas d’utilisation typiques [1]

1. Pourquoi automatiser le réseau 5G ?

La 5G est conçue pour supporter une diversité de scénarios dont les KPI sont différents : communications ultra-fiables à faible latence (URLLC), connexions massives d’objets connectés (mMTC), et débits très élevés pour le grand public (eMBB). Cette diversité implique un volume de données d’exploitation et de supervision considérable, que les opérateurs ne peuvent plus gérer manuellement pour respecter les accords SLA.

L’enjeu est triple :

  • Optimiser l’expérience utilisateur en temps réel (qualité de service perçue, MOS — Mean Opinion Score)
  • Améliorer l’efficacité des ressources réseau (charge des fonctions réseau, sélection des nœuds les moins chargés)
  • Détecter et prévenir les comportements anormaux (UE compromis, attaques, anomalies de signalisation)

C’est pour répondre à ces besoins que le 3GPP a introduit, dès la Release 15, une fonction dédiée à l’analyse des données réseau : la NWDAF.

2. La NWDAF : le cerveau analytique du cœur 5G

2.1 Principe général

La NWDAF (Network Data Analytics Function) est une fonction du cœur de réseau 5G (5GC) spécifiée dans TS 29.520. Elle joue le rôle d’un moteur d’analytiques centralisé : elle collecte des données provenant de multiples sources, les traite, et fournit des informations analytiques aux autres fonctions réseau qui en ont besoin pour prendre leurs décisions.

La NWDAF s’inscrit dans l’architecture orientée services (SBA — Service-Based Architecture) propre à la 5G : elle expose ses services via des interfaces HTTP/2 standardisées, exactement comme l’AMF, le SMF ou le PCF.

2.2 Fonctionnement : collecte, traitement, analytiques

Le cycle de fonctionnement de la NWDAF suit trois étapes :

  1. Collecte de données : la NWDAF récupère des données auprès de diverses sources — les fonctions réseau du cœur (NFs : AMF, SMF, UPF…), les fonctions applicatives (AF), et les systèmes d’exploitation et maintenance (OAM). Elle peut aussi collecter des métriques de performance radio (débit montant/descendant depuis l’OAM RAN) et des données de qualité d’expérience (QoE) depuis les fonctions applicatives.
  2. Traitement et modélisation : la NWDAF traite les données brutes, applique des algorithmes statistiques ou d’apprentissage automatique (ML), et produit des informations analytiques structurées.
  3. Exposition des analytiques : les consommateurs (PCF pour les politiques, NSSF pour la sélection de tranche réseau, AMF pour la mobilité…) souscrivent aux analytiques pertinentes et les utilisent pour leurs décisions.

Les analytiques produites peuvent être de deux natures :

  • Statistiques : description d’événements passés (que s’est-il passé ?)
  • Prédictives : anticipation d’événements futurs (que va-t-il se passer ?)

3. L’évolution release par release : de Rel-15 à Rel-19

Release 15 (2019) — La fondation

La NWDAF est introduite dans sa forme initiale. Elle est capable de collecter des données réseau et de produire des analytiques élémentaires. C’est une architecture monolithique : une seule entité logique gère à la fois la collecte, le traitement et l’exposition des résultats.

Cas d’usage type : analytiques de charge des tranches réseau (network slice load level), utilisées par le PCF pour affiner ses décisions de politique QoS, ou par le NSSF pour orienter la sélection de tranche.

Release 16 (2020) — Élargissement des sources de données

Le 3GPP étend les sources de données accessibles par la NWDAF : désormais, elle peut interroger n’importe quelle NF du cœur 5G, les fonctions applicatives (AF), et les systèmes OAM. Cette extension permet de couvrir des scénarios plus complexes.

Cas d’usage ajouté : détection de comportements anormaux des équipements utilisateurs (UE). Par exemple, la NWDAF peut détecter un phénomène de ping-pong handover (un UE oscillant entre deux cellules), ou identifier un UE compromis (piraté) et déclencher des mesures de protection — blocage des communications ou alerte — en quasi-temps-réel.

Release 17 (2022) — Décomposition fonctionnelle et nouvelles fonctions d’infrastructure

C’est la release charnière pour la maturité de l’architecture d’automatisation. Deux évolutions majeures :

a) Décomposition de la NWDAF en deux fonctions logiques :

  • MTLF (Model Training Logical Function) : chargée d’entraîner les modèles d’apprentissage automatique (ML). Elle expose des services d’entraînement aux consommateurs.
  • AnLF (Analytics Logical Function) : chargée de l’inférence, c’est-à-dire d’utiliser les modèles entraînés pour dériver des analytiques et les exposer aux consommateurs.

Cette séparation est importante : elle permet de spécialiser les ressources de calcul (les phases d’entraînement ML sont très gourmandes en ressources, différentes des phases d’inférence en production), et d’organiser la chaîne ML de façon modulaire.

b) Nouvelles fonctions d’infrastructure d’automatisation :

Fonction Spécification Rôle
DCCF (Data Collection Coordination Function) TS 29.574 Coordonne et optimise la collecte de données entre les sources et les consommateurs d’analytiques, évitant les collectes redondantes
MFAF (Messaging Framework Adaptor Function) TS 29.576 Adaptateur de framework de messagerie, facilitant la distribution des données entre fonctions via des mécanismes de publish/subscribe
ADRF (Analytics Data Repository Function) TS 29.575 Stockage persistant des données analytiques, permettant de les réutiliser sans recollecte

Ces trois fonctions renforcent l’efficacité de toute la chaîne : collecte moins redondante, distribution plus flexible, réutilisation des données.

Figure 2 : Architecture NAE

Release 18 (2024) — Intelligence augmentée et apprentissage fédéré

La Release 18 (première release de la 5G-Advanced) apporte plusieurs enrichissements substantiels :

Analytiques pour la description des flux applicatifs (PFD Determination) : la NWDAF peut analyser le trafic du plan utilisateur et les descriptions de flux de paquets (PFD — Packet Flow Description) pour en déduire de nouvelles PFDs, permettant une classification applicative plus fine et dynamique.

Métriques de précision des modèles ML : la NWDAF peut désormais calculer et exposer des indicateurs de fiabilité de ses modèles ML et de ses analytiques. Cela permet aux consommateurs d’évaluer la confiance accordée à une prédiction avant de l’utiliser pour une décision critique.

Apprentissage fédéré (Federated Learning) : plusieurs instances NWDAF (déployées dans différents domaines réseau, ou chez différents partenaires) peuvent entraîner collaborativement un modèle ML sans partager leurs données brutes locales. Chaque instance entraîne localement et ne partage que les mises à jour de modèle (les gradients ou poids). C’est une approche préservant la confidentialité des données, particulièrement utile dans des scénarios d’itinérance (roaming) ou de fédération d’opérateurs.

Analytiques en situation d’itinérance : la gestion des analytiques et des échanges de données en contexte roaming est formalisée, permettant à un opérateur visité de bénéficier de l’intelligence analytique de l’opérateur domicile.

Release 19 (en cours) — Vers l’IA au service des cas d’usage verticaux

La Release 19, activement développée par le groupe CT3 au moment de la publication de cet article, étend encore les capacités vers de nouveaux cas d’usage :

  • Amélioration du positionnement assistée par IA : la NWDAF peut contribuer à l’amélioration de la précision de localisation des UEs en exploitant des données analytiques complémentaires aux techniques radio classiques (TDOA, AoA…).
  • Apprentissage fédéré vertical : extension du Federated Learning à des scénarios impliquant des acteurs verticaux (industrie, santé, transport) au-delà des seuls opérateurs.
  • Recommandation de politique QoS : la NWDAF peut suggérer proactivement au PCF des ajustements de politique QoS basés sur ses prédictions d’usage et d’expérience.
  • Atténuation et prévention de comportements anormaux réseau : évolution des mécanismes de détection vers une posture plus proactive, avec des actions préventives automatisées.

4. Cas d’usage illustratifs

Cas 1 : L’expérience de service (MOS)

Un opérateur souhaite mesurer en continu la qualité perçue (Mean Opinion Score) d’un service de streaming vidéo sur ses tranches réseau. La NWDAF collecte les métriques QoE depuis la fonction applicative (délai moyen de paquets, taux de perte, débit), les données de flux QoS depuis les NFs du cœur, et les métriques radio (débit RAN) depuis l’OAM. Elle produit des analytiques à différentes granularités : par UE individuel, par groupe d’UEs, par application, par type d’accès, par tranche réseau. L’opérateur identifie ainsi les goulots d’étranglement et les opportunités d’optimisation réseau ciblées.

Cas 2 : Analytiques de charge des fonctions réseau (NF Load)

Un AMF doit sélectionner un SMF pour gérer une nouvelle session PDU. Plutôt que de choisir au hasard parmi les SMFs disponibles, l’AMF interroge la NWDAF pour connaître la charge actuelle et prévisionnelle de chaque SMF (usage CPU virtuel, mémoire, disque, charge de trafic). La NWDAF collecte ces informations auprès du NRF (registre des NFs) et de l’OAM, et produit un résultat structuré incluant le statut, la charge courante et la charge de pointe de chaque SMF. L’AMF sélectionne ainsi le SMF le moins sollicité, améliorant l’efficacité globale du réseau. Le même principe s’applique à la sélection de l’UPF par le SMF.

5. Points clés à retenir

L’architecture NAE illustre une tendance de fond dans la normalisation 5G : l’intégration native de l’intelligence artificielle et de l’apprentissage automatique dans les protocoles cœur, et non plus comme une surcouche externe. Quelques points structurants :

  • La NWDAF est une NF standardisée du 5GC, pas un produit propriétaire ni une surcouche OAM. Elle s’intègre via les mêmes interfaces SBI (HTTP/2) que toutes les NFs.
  • La décomposition MTLF/AnLF (Rel-17) est une architecture ML-native : séparation entraînement/inférence pour permettre flexibilité et spécialisation des ressources.
  • L’apprentissage fédéré (Rel-18) répond à des contraintes de souveraineté et de confidentialité des données, particulièrement importantes dans les contextes multi-opérateurs et multi-domaines.
  • L’évolution de Rel-15 à Rel-19 suit une progression cohérente : collecte → enrichissement des sources → décomposition ML → qualité des modèles → apprentissage distribué → cas d’usage verticaux.

 

Références normatives

  • TS 29.520 — 5G System; Network Data Analytics Services; Stage 3 (NWDAF)
  • TS 29.574 — 5G System; Data Collection Coordination Services; Stage 3 (DCCF)
  • TS 29.575 — 5G System; Analytics Data Repository Services; Stage 3 (ADRF)
  • TS 29.576 — 5G System; Messaging Framework Adaptor Services; Stage 3 (MFAF)
  • TS 23.501 — System Architecture for the 5G System (architecture SBA globale)
  • TS 23.288 — Architecture enhancements for 5G System to support network data analytics services (stage 2 NWDAF)

Source principale :

[1] 3GPP Highlights Issue 09 (décembre 2024) — « Network Automation Enablers in 5GS », Yali Yan (CT3 Chair), Zhenning Huang (China Mobile), Xuefei Zhang (Huawei). https://www.3gpp.org/technologies/nae-5gs-ct3

 

IMT-2030 : de la vision aux objectifs de conception — les exigences techniques de performance pour la 6G

Posté le by - 119 vues
Répondre

En novembre 2023, l’UIT-R officialisait la Recommandation ITU-R M.2160 [1], socle de la vision IMT-2030 (autrement dit la 6G). Ce document fondateur définit six scénarios d’usage et quinze capacités cibles pour la prochaine génération de systèmes mobiles. Mais une vision, aussi ambitieuse soit-elle, ne suffit pas à guider les ingénieurs qui devront concevoir les interfaces radio de demain. Il faut des chiffres : des valeurs mesurables, comparables, opposables.

C’est précisément l’objet du rapport ITU-R M.[IMT-2030.TECH PERF REQ], finalisé par le Groupe de travail WP 5D de l’UIT-R en février 2026 [2][3]. Ce document — actuellement en attente d’approbation formelle par le Groupe d’étude 5 (SG 5) lors de sa réunion de décembre 2026 — spécifie les Exigences Techniques de Performance (Technical Performance Requirements, TPR) minimales que toute technologie d’interface radio (RIT) devra satisfaire pour se voir reconnaître la désignation IMT-2030.

Cet article en propose une synthèse des cas d’usages et des indicateurs de performances.

Du scénario d’usage à l’environnement de test

Les six scénarios d’usage IMT-2030

IMT-2030 prolonge et étend les trois scénarios d’IMT-2020 (eMBB, URLLC, mMTC) en les réorganisant et en ajoutant trois nouveaux :

Scénario IMT-2030 Équivalent / Évolution IMT-2020
IC — Immersive Communication Évolution de eMBB
HRLLC — Hyper-Reliable and Low-Latency Communication Évolution de URLLC
MC — Massive Communication Évolution de mMTC
UC — Ubiquitous Connectivity Nouveau
AIAC — AI and Communication Nouveau
ISAC — Integrated Sensing and Communication Nouveau

L’introduction de UC, AIAC et ISAC marque un tournant : la 6G n’est plus seulement une radio plus rapide, c’est un système intégrant nativement la localisation, la détection d’environnement, et l’intelligence artificielle dans l’interface radio elle-même.

Les exigences héritées d’IMT-2020 et renforcées

IMT-2030 reprend quatorze items TPR d’IMT-2020 avec des niveaux relevés. La Figure 1 (ci-dessous) en donne le détail complet.

[Figure 1 — Exigences techniques minimales IMT-2030 — à insérer ici]

Performances du scénario IC (Immersive Communication)

Débit crête et efficacité spectrale crête. Le débit de données théorique en crête est fixé à 36 Gbit/s en voie descendante (DL) et 18 Gbit/s en voie montante (UL), pour une bande agrégée de 600 MHz. L’efficacité spectrale crête correspondante atteint 60 bit/s/Hz (DL) et 30 bit/s/Hz (UL). Ces valeurs constituent un plafond théorique, évalué dans des conditions idéales sans erreur de transmission.

Efficacité spectrale au 5e percentile. Cet indicateur caractérise l’expérience des utilisateurs en bordure de cellule. En environnement Dense Urban-IC, le débit au 5e percentile est exigé à 300 Mbit/s (DL) et 50 Mbit/s (UL). En Indoor Hotspot-IC, l’efficacité spectrale au 5e percentile atteint 0,9 bit/s/Hz (DL) et 0,63 bit/s/Hz (UL).

Efficacité spectrale moyenne et capacité de trafic surfacique. En Indoor Hotspot-IC, la capacité de trafic surfacique doit dépasser 40 Mbit/s/m². L’efficacité spectrale moyenne atteint 27 bit/s/Hz (DL) et 20,25 bit/s/Hz (UL) dans ce même environnement.

Mobilité. Le système doit maintenir la qualité de service jusqu’à 500 km/h (scénario Rural-IC, avec un débit normalisé de 0,675 bit/s/Hz à cette vitesse). Le temps d’interruption de mobilité doit être minimisé : il est fixé à 0 ms pour les transitions entre TRxP d’une même station de base.

Efficacité énergétique. L’exigence est exprimée en consommation relative par rapport à un cas de référence à pleine charge. Elle doit être évaluée au minimum pour le cas déchargé (L = 0 %) et un cas partiellement chargé (0 % < L ≤ 30 %).

Performances des scénarios HRLLC et MC

Latence du plan utilisateur. La latence en plan utilisateur (aller simple, interface radio, conditions non chargées) est fixée à 1 ms pour HRLLC (comme en 5G) et 4 ms pour IC. La latence du plan de contrôle (transition depuis l’état le plus économe en énergie vers le transfert continu) est fixée à 20 ms pour HRLLC et IC.

Fiabilité. En environnement Indoor Factory-HRLLC, la probabilité de succès de transmission d’une PDU de 32 octets dans une latence de 1 ms doit atteindre 1 – 10⁻⁵ (soit 99,999 %) comme en 5G.

Densité de connexions. Le scénario MC exige 10⁶ dispositifs par km² en maintenant un niveau de qualité de service spécifié (comme en 5G).

Bande passante. La bande passante agrégée minimale requise pour l’évaluation IMT-2030 est de 400 MHz.

Les six nouvelles exigences spécifiques à IMT-2030

En plus des quatorze items renforcés, IMT-2030 introduit six nouveaux TPR qui couvrent des dimensions absentes d’IMT-2020.

Exigence composite (scénario IC)

C’est l’une des innovations conceptuelles majeures de ce rapport. L’exigence composite évalue la satisfaction simultanée de plusieurs KPI — débit, latence et probabilité de succès de paquet — pour un nombre donné d’utilisateurs actifs par point de transmission (TRxP).

En Dense Urban-IC, la cible est de 6 utilisateurs par TRxP, chacun recevant au moins 30 Mbit/s (DL) / 10 Mbit/s (UL), avec une latence DL ≤ 10 ms et UL ≤ 30 ms, et une probabilité de succès de paquet d’au moins 99 %.

Cette exigence traduit une réalité fondamentale des services immersifs (XR, téléprésence, holographie) : il ne suffit pas d’être rapide ou fiable ou réactif — il faut l’être simultanément.

Détection et localisation radar (scénario ISAC)

Le scénario ISAC introduit des exigences sur la détection d’objets non connectés par le système radio :

Paramètre Indoor Factory-ISAC Urban Macro-ISAC
Probabilité de détection 95 % 95 %
Probabilité de fausse alarme 5 % 5 %
Précision de localisation horizontale 2 m 5 m
Précision de localisation verticale N/A 8 m
Précision de vitesse 2 m/s 4 m/s

Ces exigences font de la 6G un système capable d’assurer des fonctions de type radar — avec des implications directes pour la robotique industrielle, la sécurité en usine, et les véhicules autonomes.

Précision de positionnement (scénario ISAC)

Distincte de la localisation radar (qui cible des objets non connectés), la précision de positionnement concerne les terminaux connectés. La valeur retenue est le 90e percentile de l’erreur de positionnement :

  • 0,75 m en Indoor Factory-ISAC
  • 6 m en Urban Macro-ISAC

Pour rappel, IMT-2020 visait déjà des précisions sub-métriques en intérieur dans certaines configurations (TS 22.261 Rel-16). IMT-2030 ancre cette ambition dans une exigence de performance minimale qui ne peut être respecter que si l’on exploite toute la largeur de bande de 400 MHz.

Exigence IA (scénario AIAC)

L’exigence relative à l’IA est de nature qualitative : l’interface radio 6G doit supporter un ou plusieurs mécanismes liés aux fonctions d’IA, parmi : collecte de données, traitement distribué, apprentissage distribué, entraînement de modèles, inférence, ou d’autres capacités IA à déclarer par le proponent. Cette approche flexible reconnaît que l’intégration native de l’IA dans l’interface radio est encore en cours de standardisation à 3GPP (Study Items actifs en Rel-20).

Résilience et connectivité étendue (scénario UC)

L’exigence UC couvre deux dimensions complémentaires :

  • Résilience : maintien du service en cas de perturbation (panne d’alimentation, défaillance d’infrastructure). L’interface radio 6G doit supporter des mécanismes permettant la continuité ou la restauration rapide des communications.
  • Connectivité étendue : fourniture de services dans des zones non couvertes ou peu couvertes (zones rurales, maritimes, zones de catastrophe). Les solutions envisagées incluent les plateformes haute altitude (HAPS), les relais, les nœuds embarqués sur véhicules ou aéronefs.

Cette exigence est directement alignée avec les travaux NTN (Non-Terrestrial Networks) de 3GPP, actifs depuis Rel-17 et en extension significative en Rel-18/19.

Distance de liaison (Link Distance)

Enfin, un sixième item nouveau exige que le proponent déclare, via une analyse de bilan de liaison, la distance maximale à laquelle un débit donné peut être soutenu. Cet indicateur reflète l’équilibre performance/couverture, particulièrement pertinent pour les déploiements ruraux et NTN.

Le calendrier IMT-2030 / 3GPP : où en sommes-nous ?

La séquence normative est maintenant bien établie :

Période Étape
2023 Publication de Rec. ITU-R M.2160 (framework IMT-2030)
Fév. 2026 Finalisation du rapport TPR par WP 5D
Déc. 2026 Approbation prévue par SG 5 (ITU-R)
2024–2026 Définition des critères d’évaluation (M.[IMT-2030.EVAL] et M.[IMT-2030.SUBMISSION])
2025–2027 Études 6G dans 3GPP Rel-20 (study items RAN1/SA1)
2027–2029 Spécifications normatives 3GPP Release 21 (premier ensemble de specs 6G)
Début 2029 Soumission des RIT/SRIT candidates à l’ITU-R
2030 Désignation IMT-2030 et publication des spécifications finales

Concrètement, 3GPP Release 21 sera le premier ensemble de spécifications 6G. Son calendrier a été approuvé lors de TSG RAN #112 (juin 2026) : gel Stage 3 prévu en décembre 2028, gel ASN.1/OpenAPI en mars 2029 — délibérément calé juste avant la deadline ITU-R pour les propositions de candidats.

Conclusion : ce que ces exigences signifient pour la recherche

Les TPR IMT-2030 ne sont pas de simples jalons administratifs. Ils définissent l’espace de conception dans lequel toute technologie 6G devra évoluer. Quelques lectures transversales s’imposent :

Sur la couche physique : atteindre 36 Gbit/s en DL avec 600 MHz de bande agrégée implique des efficacités spectrales très élevées (60 bit/s/Hz en crête), ce qui présuppose des systèmes MIMO massifs multi-couches, très probablement avec une dimension spatiale exploitant des fréquences au-delà de la FR2 actuelle — voire au-delà de 100 GHz (domaine sub-THz).

Sur la localisation et le sensing : les exigences ISAC confèrent à la couche radio une double fonction — communications et détection radar — avec des niveaux de précision qui dépassent les capacités des systèmes PRS actuels de 5G NR (TS 38.215). Des architectures nouvelles seront nécessaires, probablement basées sur des signaux de référence dédiés au sensing.

Sur l’IA native : l’exigence AIAC est encore ouverte, mais elle formalise l’idée que l’IA doit être un composant de l’interface radio, pas seulement un outil de gestion réseau. C’est un changement de paradigme par rapport à 5G NR, où l’IA reste principalement dans la couche de gestion (O-RAN, NWDAF).

Sur les NTN : les exigences UC (résilience, connectivité étendue) sont directement adressées par les satellites LEO, les HAPS et les UAV-BS — un domaine dans lequel des travaux de recherche sont en cours au LIAS.

Les TPR IMT-2030 traduisent une vision en objectifs chiffrés. La prochaine étape — et c’est là que les communautés de recherche entrent en jeu — est de démontrer que des technologies concrètes peuvent les atteindre.

Références

[1] ITU-R, Framework and overall objectives of the future development of IMT for 2030 and beyond, Recommandation ITU-R M.2160-0, Union Internationale des Télécommunications, Genève, novembre 2023. Disponible : https://www.itu.int/rec/R-REC-M.2160/en

[2] L. Ma, M. Grant, H. Lin, J. Sköld, R. Liu, J. Shao, « From Vision to Design Targets: Technical Performance Requirements for IMT-2030 », IEEE Communications Magazine, juin 2026.

[3] ITU-R WP 5D, Draft New Report ITU-R M.[IMT-2030.TECH PERF REQ] — Minimum Requirements Related to Technical Performance for IMT-2030 Radio Interface(s), Document ITU-R 5/116, février 2026. (Approbation par SG 5 prévue en décembre 2026.)

[4] ITU, « IMT-2030: Technical requirements for the 6G future », communiqué ITU, 17 mars 2026. Disponible : https://www.itu.int/hub/2026/03/imt-2030-technical-requirements-for-the-6g-future/

La vision de la 6G par SK Telecom

Posté le by - 104 vues
Répondre

Vers la 6G : quelles évolutions pour l’architecture des réseaux mobiles ?

Même si les déploiements de 5G-Advanced se poursuivent, les experts 3GPP travaillent maintenant sur les études de la 6G (Rel 20) dont la commercialisation est généralement projetée après 2032.

En France, le hub collaboratif France6G a pour objectif de cartographier les acteurs de la 6G et de définir les orientations scientifiques et les verrous techniques à lever.

Les grands équipementiers et opérateurs publient régulièrement des feuilles de route qui, sans constituer des normes, dessinent un consensus assez net sur la direction que devrait prendre l’architecture des réseaux mobiles dans la prochaine décennie.

Cet article propose une synthèse pédagogique de ces grandes tendances, en s’appuyant notamment sur l’une des feuilles de route les plus complètes publiées récemment, « ATHENA », le troisième livre blanc 6G de l’opérateur sud-coréen SK Telecom, publié le 23 février 2026, disponible en ligne.

Il faut garder à l’esprit que ce type de document relève de la vision industrielle, pas du standard : il ne s’agit ni d’une spécification 3GPP, ni d’une architecture normalisée par l’O-RAN Alliance, mais d’une prospective qui dialogue avec les travaux de standardisation en cours sans s’y substituer. C’est néanmoins une lecture précieuse pour comprendre vers quoi convergent les opérateurs, et pour anticiper les sujets qui structureront vraisemblablement les prochaines releases 3GPP et les futurs travaux de l’O-RAN Alliance.

1. Quatre ruptures attendues à l’horizon 2030

Les feuilles de route 6G s’accordent généralement sur quatre évolutions majeures de l’environnement réseau de la décennie à venir.

La première est la convergence entre intelligence artificielle et réseaux, souvent résumée par le slogan « AI Everywhere ». Elle se décompose en deux axes complémentaires : AI for Network, c’est-à-dire l’IA mise au service de l’amélioration des performances réseau, et Network for AI, c’est-à-dire le réseau repensé pour porter et accélérer la diffusion des services d’IA eux-mêmes.

La deuxième rupture est l’essor massif de nouveaux usages : généralisation des véhicules autonomes et de la réalité augmentée/virtuelle multimodale héritées de la 5G, mais aussi émergence de l’« IA physique », incarnée notamment par les robots humanoïdes, identifiée comme un relais de croissance majeur du trafic mobile de la 6G.

La troisième rupture concerne l’architecture système elle-même : diversification des services, virtualisation et ouverture des réseaux, et renforcement des exigences de protection des données personnelles imposent une refonte structurelle plutôt qu’un simple empilement de nouvelles fonctions.

La quatrième, enfin, est davantage organisationnelle : les évolutions démographiques et sociétales (pénurie de compétences techniques, vieillissement des effectifs d’exploitation réseau) imposent de revoir les paradigmes d’exploitation, d’où l’insistance des opérateurs sur l’automatisation poussée et l’autonomie des réseaux.

2. Les objectifs qui guident cette évolution

Les feuilles de route 6G articulent généralement trois objectifs : l’efficacité opérationnelle (réduction du coût total de possession, gains de productivité), l’expérience client (amélioration perçue de la qualité de service, stabilité opérationnelle) et la monétisation (nouveaux modèles d’affaires liés à l’IA, augmentation du revenu moyen par utilisateur). L’enjeu pour les opérateurs est de trouver la zone d’intersection où une même brique technologique sert simultanément ces trois objectifs, plutôt que de les traiter séparément.

3. Les briques technologiques structurantes de la 6G

En croisant les feuilles de route publiées par plusieurs grands acteurs du secteur, six familles de technologies reviennent systématiquement comme structurantes pour la 6G.

L’IA d’abord : intelligence cognitive, AI-RAN, IA native au réseau, autonomie complète, efficacité énergétique pilotée par apprentissage automatique.

Le cloud ensuite : virtualisation poussée, RAN entièrement « cloudifié », infrastructure extensible à la demande, sobriété énergétique.

L’ouverture : interfaces ouvertes type Open RAN, exposition d’API réseau, plateformisation des actifs de l’opérateur.

La connectivité : intégration satellite-terrestre, continuité de service, hyperconnectivité, réseaux sensibles au temps (time-sensitive networking).

La sécurité : architecture Zero Trust, résilience, détection cognitive des menaces.

Et enfin la convergence des générations et des services : cohabitation 4G/5G/6G sur une même infrastructure, diversité croissante des terminaux, multiplication des services immersifs.

4. Six grandes visions pour le réseau 6G

Ces six familles de technologies se projettent à leur tour sur six visions d’architecture qui reviennent, sous des formulations proches, dans la plupart des feuilles de route 6G actuelles.

Le réseau AI-native est un réseau qui intègre nativement l’intelligence artificielle dans ses principes de fonctionnement, selon les deux axes déjà cités AI for network et Network for AI. Côté AI for network, l’objectif est un réseau pleinement intelligent, capable d’auto-optimisation en temps réel et d’automatisation de bout en bout (exploitation, optimisation de performance, prédiction et résolution d’incidents), avec une intervention humaine réduite au minimum. Côté Network for AI, il s’agit de concevoir une infrastructure télécom à faible latence et haute performance capable d’héberger elle-même des charges de travail d’IA, le même matériel pouvant servir à la fois la communication et le calcul IA. L’infrastructure IA (XPU : GPU, DPU, NPU) n’est pas discutée dans cet article.

Le réseau cloud-native correspond à l’extension de la virtualisation à l’ensemble du réseau télécom, afin de pouvoir étendre, réduire et redistribuer dynamiquement les ressources selon les profils de trafic, avec un pilotage de bout en bout sur tous les domaines (accès radio, cœur, transport, couche service).

Le réseau ubiquitaire vise une infrastructure « agnostique à la génération », c’est-à-dire non figée sur la 5G ou la 6G, capable de faire coexister organiquement les générations technologiques et d’offrir une couverture continue, y compris via les réseaux non terrestres (NTN).

Le réseau ouvert est un écosystème non captif d’un fournisseur unique, fondé sur du matériel COTS (Commercial Off-The-Shelf) et des interfaces ouvertes, qui doit aussi permettre d’exposer les données et actifs du réseau à des tiers, dans une logique de Network as a Platform.

Le réseau Zero Trust ne fait confiance par défaut à aucune entité et vérifie en continu chaque connexion, selon le principe « trust nothing, verify everything ». Cette vision se décline en réalité de façon transversale dans chacune des autres : détection automatique d’anomalies et ajustement dynamique des politiques dans le réseau AI-native, contrôle d’accès fin par micro-service et conteneur dans le réseau cloud-native, authentification et surveillance temps réel des API dans le réseau ouvert.

Le réseau orienté client enfin est pensé prioritairement autour de l’expérience utilisateur plutôt que de la commodité opérationnelle de l’exploitant, avec un objectif de taux de panne proche de zéro et une attention particulière portée aux nouveaux types de terminaux attendus en 6G (robots humanoïdes, véhicules autonomes, lunettes AR).

5. Le RAN devient un nœud de calcul intelligent

Au niveau de l’accès radio, la 6G est généralement envisagée selon deux axes complémentaires : l’IA au service de l’optimisation radio (AI for RAN) et le RAN comme infrastructure de calcul IA (RAN for AI). Cinq exigences de conception en découlent.

L’intégration de l’IA suppose un matériel générique doté de processeurs spécialisés (GPU, NPU…) capable de traiter en parallèle, sur les mêmes ressources virtualisées, le trafic de communication et des charges de calcul IA. Cette capacité de calcul sert à la fois à optimiser intelligemment le traitement du signal aux couches hautes et à la couche physique (adaptation de lien, interface air native-IA, économie d’énergie pilotée par prédiction de trafic), et à héberger des services d’IA tiers directement en périphérie, à faible latence, ce qui ouvre la voie à de nouveaux modèles économiques.

L’automatisation et l’optimisation reposent sur un contrôleur intelligent du RAN (un RIC, au sens où l’entend l’O-RAN Alliance), qui collecte et analyse en temps réel les données réseau pour réaliser, via des agents IA, une auto-optimisation fondée sur l’intention : équilibrage de charge, optimisation de couverture, réglage de paramètres, économies d’énergie, sans intervention directe de l’exploitant. Chaque solution exécutée dans ce contrôleur prend la forme d’une application fondée sur des interfaces ouvertes — on retrouve ici le concept de rApp et de xApp tel que défini par l’O-RAN Alliance. Deux cas d’usage illustrent bien cette logique : l’optimisation de paramètres assistée par IA, où un modèle entraîné sur les données réseau propose le meilleur jeu de paramètres par cellule sous contrainte de taux de coupure, et la mise en veille MIMO assistée par IA, où le modèle décide cellule par cellule des fenêtres de sommeil/réveil sans dégrader la qualité perçue.

La virtualisation vise à découpler complètement matériel et logiciel pour permettre un redéploiement flexible des composants RAN, avec des techniques de mutualisation de ressources (resource pooling) telles que le scale-in en cas de faible charge ou le scale-up/cell pooling en cas de pic de trafic, et la capacité à faire cohabiter 4G, 5G et 6G sur une même plateforme matérielle.

L’ouverture des interfaces s’appuie sur les standards de l’O-RAN Alliance, créée en 2018, pour permettre l’interopérabilité d’équipements multi-fournisseurs aussi bien entre équipements (interfaces externes) qu’au sein même d’un équipement (interfaces internes). L’objectif est de sécuriser des données réseau et terminal de haute qualité, granulaires et normalisées, exposées ensuite vers le NWDAF, l’OSS de l’opérateur, ou des tiers pour de l’analyse ou de l’entraînement de modèles IA.

L’architecture Zero Trust, enfin, devient un principe transversal au RAN : authentification mutuelle continue et chiffrement du trafic entre fonctions internes et entre équipements, surveillance continue des attaques avec automatisation des politiques de sécurité, isolement des ressources et des charges de travail pour limiter la propagation d’une intrusion en environnement virtualisé, et arbitrage explicite entre sécurité et performance pour les services sensibles à la latence (XR, contrôle industriel temps réel, V2X) déployés en périphérie.

6. Le cœur de réseau vers l’autonomie complète

Le cœur de réseau de la 6G est généralement envisagé au-delà de la simple connectivité (« Beyond Connectivity ») : il intégrerait nativement IA, capacité de calcul et sécurité Zero Trust, avec une structure de protocoles simplifiée entre terminaux et réseau et une communication inter-fonctions nettement plus efficace que dans le cœur 5G actuel.

Cinq leviers reviennent fréquemment dans les feuilles de route pour atteindre ce but : un pilotage fondé sur l’intention (intend based), où l’opérateur ne fixe que des objectifs (latence, disponibilité, coûts) et les agents IA traduisent ensuite en plans d’action par domaine ; une coopération entre agents spécialisés (supervision, diagnostic, qualité, sécurité) capable d’orchestrer des scénarios complexes ; une boucle fermée fiable s’appuyant sur un jumeau numérique réseau pour pré-valider les modifications avant déploiement, combinée à des stratégies de déploiement progressif (Canary Update, Rolling Upgrade) ; une analyse de cause racine systématisée croisant journaux, métriques et politiques ; et l’exposition de capacités réseau (QoS, sécurité, localisation, événements) sous forme d’API ouvertes monétisables, dans une logique de Network as a Platform.

Sur le plan de la transformation cloud-native, l’objectif est un environnement de fonctions réseau entièrement cloud-native, fondé sur une architecture en microservices portable entre clouds multiples ou hybrides. L’IA y joue un rôle de résilience marquant : détection des signes avant-coureurs de panne, isolement et récupération automatique de la fonction défaillante sans intervention humaine ni interruption perçue par le client — l’idée d’un cœur de réseau « qui ne meurt pas, même quand il meurt » —, l’horizon visé étant celui des réseaux dits « de niveau 4 » d’autonomie.

Côté ouverture de services, on distingue généralement trois niveaux de maturité pour l’exposition réseau : l’appel API simple, l’exposition contextuelle (qui tient compte de la situation de l’utilisateur) et l’exposition fondée sur l’intention (où le réseau traduit lui-même l’intention de service en politiques). S’y ajoutent des services d’itinérance en périphérie (Roaming Edge), avec des fonctions de plan utilisateur déployées dans le cloud à l’étranger mais pilotables depuis le réseau d’origine, pour rapprocher le traitement des données des clients en itinérance.

L’architecture Zero Trust appliquée au cœur insiste particulièrement sur la fonction d’exposition réseau et la passerelle API, identifiées comme points de vulnérabilité majeurs où se croisent menaces externes et internes : vérification continue de chaque appel API (origine, validité du certificat, intégrité du message, expiration du jeton), principe de moindre privilège granularisé jusqu’au niveau de l’endpoint, chiffrement systématique des échanges (IPSec, TLS récents), et gouvernance de sécurité intégrant sécurité de la chaîne logicielle d’approvisionnement et micro-segmentation.

7. Le réseau de transport, moteur discret de la performance 6G

Le réseau de transport est hors-scope de la 3GPP, alors qu’il conditionne directement la latence et la capacité de bout en bout. Plusieurs évolutions s’y dessinent.

Le pilotage de bout en bout assisté par IA repose sur un orchestrateur combinant un module de collecte de données, un cadre d’inférence IA (gestion des modèles, exécution de l’inférence, optimisation de performance) et un cadre d’automatisation qui agit en temps réel sur le réseau à partir des résultats d’analyse — avec, à la clé, un temps de détection et de résolution d’incident pouvant être ramené à l’ordre de la seconde sur des réseaux comptant plusieurs milliers de routeurs.

L’évolution vers des réseaux tout-optiques convergés vise à s’affranchir de la dépendance aux équipementiers en migrant vers des équipements convergés couches 1 à 3, une architecture de fronthaul nouvelle génération combinant fibre optique transparente et PON, et des architectures « White Box » à bas coût pour le matériel d’accès optique. Le pilotage de cet ensemble multi-fournisseurs s’appuie sur un modèle de données de gestion commun et des API ouvertes, notamment pour piloter les multiplexeurs optiques reconfigurables nouvelle génération (NG-ROADM), capables de débits supérieurs à 200 Gbit/s par longueur d’onde. La capacité par lien de fronthaul, actuellement de l’ordre de 25 Gbit/s, est en cours de migration vers 50 Gbit/s et au-delà, ce qui impose le recours à des modulations plus complexes (PAM4) et à l’optique cohérente numérique pour compenser la pénalité de dispersion liée à la montée en débit.

La sécurisation post-quantique du transport constitue l’un des chantiers les plus structurants pour la décennie à venir. Face à la menace que la maturation de l’informatique quantique fait peser sur les schémas de chiffrement classiques, les opérateurs envisagent une architecture de sécurité double : la distribution quantique de clés (QKD), qui repose sur l’installation d’équipements dédiés aux points névralgiques du réseau (centres de données, sites B2B, centraux), combinée à des algorithmes de cryptographie post-quantique (PQC) sur les liaisons de transmission. Ces services sont d’abord ciblés sur la synchronisation de données massives entre centres de données et sur des liaisons dédiées B2B dans des secteurs sensibles (finance, santé, secteur public, industrie).

Le dimensionnement du transport pour les services xPU anticipe l’arrivée massive de l’IA en répartissant les rôles entre des centres de données IA dédiés à l’entraînement de grands modèles (concentration de GPU, TPU, FPGA) et des clusters répartis en périphérie du réseau, dédiés à l’inférence en temps réel et faible latence, au plus près des usages (analyse vidéo, reconnaissance vocale, traitement de données IoT). Des essais pilotes de clustering GPU longue distance entre sites, combinant routeurs ouverts, modules optiques 400G et cartes réseau RDMA, sont déjà en cours pour évaluer les performances de transmission et d’entraînement sur des réseaux RoCE.

Enfin, le jumeau numérique du réseau de transport (Network Digital Twin) ambitionne de répliquer fidèlement, dans l’espace numérique, l’ensemble des éléments du réseau réel — structure, ressources, trafic, historique de pannes, politiques d’exploitation — afin de permettre simulation, automatisation, optimisation, prédiction et vérification avant tout changement sur le réseau de production.

8. La donnée réseau, nouvelle brique d’architecture à part entière

Un trait marquant des feuilles de route 6G les plus récentes est l’émergence d’un domaine d’architecture entièrement consacré à la valorisation de la donnée réseau, au même rang que l’accès radio, le cœur et le transport. Le constat de départ est connu des opérateurs : la donnée générée par le réseau (localisation, trafic, qualité radio…) est déjà exploitée commercialement — analyse de fréquentation en temps réel, services de positionnement, analyse de zones commerciales — mais la multiplication des cas d’usage en 6G rend intenable la construction d’un pipeline de données indépendant pour chaque service, en raison de la redondance des coûts de développement, de la complexité opérationnelle croissante et de la difficulté à maintenir des politiques de sécurité cohérentes.

Une plateforme de ce type s’organise généralement autour de quatre principes. Une architecture hybride edge-cloud combine un moteur d’exécution en périphérie, capable de fonctionner de manière autonome y compris en cas de coupure temporaire avec le cloud — un point critique pour des environnements industriels (automatisation d’usine, télémédecine) — et capable d’appliquer de l’apprentissage fédéré pour entraîner des modèles sans faire transiter de données sensibles hors du site, avec un moteur d’exécution centralisé dans le cloud responsable de la supervision globale, de la gestion des politiques (souvent via une approche Infrastructure as Code fondée sur Git) et de la conformité réglementaire (RGPD notamment).

Le développement de services pilotés par l’IA s’appuie sur le traitement automatique du langage naturel pour traduire une expression de besoin métier en attributs de données nécessaires, sur des pipelines de feature engineering automatisés, et sur la génération et le réglage automatiques de modèles candidats, orchestrés ensuite avec des mécanismes de résilience désormais classiques en architecture distribuée (circuit breaker, tentatives de relance, délais d’expiration).

L’exploitation autonome assistée par IA se matérialise par des copilotes d’exploitation combinant grand modèle de langage (LLM) et génération augmentée par récupération (RAG), s’appuyant sur une collecte d’observabilité standardisée (métriques, journaux, traces, selon le standard OpenTelemetry), des moteurs de détection d’anomalies et d’analyse de cause racine, et des bases de connaissances indexées des incidents passés pour proposer, après validation humaine, des actions correctives automatisées — avec, à terme, des mécanismes d’auto-réparation pour les pannes mineures.

Enfin, un modèle de gouvernance à deux plans distingue généralement un plan de gouvernance centralisé, qui gère les politiques de manière déclarative avec validation et déploiement automatisés via CI/CD, d’un plan de livraison en périphérie, qui packages et déploie rapidement les services conteneurisés avec des capacités de retour arrière rapide et de déploiement progressif — le tout sous une architecture Zero Trust cohérente entre edge et cloud.

9. Une vision industrielle à mettre en perspective avec la standardisation

Trois précautions de lecture s’imposent lorsqu’on exploite ce type de feuille de route à des fins pédagogiques ou de veille.

D’abord, il s’agit toujours d’une vision d’opérateur ou d’équipementier, pas d’un standard : chaque acteur y développe sa propre nomenclature de fonctions et d’architectures, qui ne préjuge en rien de ce qui sera effectivement retenu par le 3GPP ou l’O-RAN Alliance. Ces feuilles de route sont d’ailleurs souvent accompagnées d’une clause de réserve explicite rappelant qu’elles sont fournies à titre d’information et ne constituent aucun engagement sur une technologie ou un service réellement livré.

Ensuite, ces documents mêlent délibérément des registres différents : une part de prospective pure (« devrait évoluer », « est attendu ») et une part de R&D réelle, mais à des stades de maturité très variables — certains éléments déjà déployés en commercial, d’autres encore au stade de la preuve de concept ou du pilote en laboratoire. Une lecture rigoureuse impose de toujours vérifier à quel stade de maturité se situe l’élément cité avant de le présenter comme une réalité opérationnelle.

Enfin, ces visions s’inscrivent explicitement dans un dialogue avec les instances de standardisation en cours — 3GPP (notamment les travaux des Releases 19 et 20), O-RAN Alliance (SMO, RIC, interfaces O1/O2/R1), ETSI NFV, AI-RAN Alliance, GSMA — sans pour autant s’y substituer. Elles constituent à ce titre un bon point d’entrée pour suivre, dans les prochaines releases, lesquelles de ces propositions seront effectivement retenues, et lesquelles resteront propres à l’écosystème d’un opérateur donné.

10. Conclusion

Au-delà des appellations propres à chaque opérateur, un panorama assez cohérent se dégage des feuilles de route 6G publiées ces dernières années : un réseau pensé nativement pour l’IA — à la fois optimisé par elle et conçu pour l’héberger —, entièrement virtualisé et orchestré de bout en bout, ouvert à l’interopérabilité multi-fournisseurs, sécurisé selon les principes Zero Trust à chaque couche, et dont la donnée elle-même devient un domaine d’architecture à part entière. Pour qui enseigne ou pratique la veille sur les réseaux 5G-Advanced et 6G, ces documents constituent une référence utile à croiser avec les travaux de standardisation du 3GPP et de l’O-RAN Alliance qui, seuls, détermineront in fine ce qui sera réellement déployé.

Glossaire des principaux sigles

Sigle Signification
AI-RAN Artificial Intelligence – Radio Access Network
COTS Commercial Off-The-Shelf
DCO Digital Coherent Optics
LCM Life Cycle Management
NG-ROADM Next-Generation Reconfigurable Optical Add-Drop Multiplexer
NTN Non-Terrestrial Network
NWDAF Network Data Analytics Function
O-RAN Open Radio Access Network
PAM4 Pulse Amplitude Modulation 4-level
PQC Post-Quantum Cryptography
QKD Quantum Key Distribution
RIC RAN Intelligent Controller
RoCE RDMA over Converged Ethernet
SBA Service Based Architecture
vRAN Virtualized Radio Access Network
xPU terme générique pour GPU/NPU/TPU/FPGA
ZTA Zero Trust Architecture

Pour aller plus loin

SK Telecom, 2026 SK Telecom 6G White Paper – Vision on Future Network Architecture, ATHENA, 23 février 2026 : news-static.sktelecom.com/…/2026-SKT-6G-White-Paper-ATHENA_Eng.pdf

6G Progress Report, GSMA, May 2026, https://www.gsma.com/solutions-and-impact/technologies/networks/wp-content/uploads/2012/10/GSMA-6G-Progress-Report-May-2026.pdf

 

5G Privée Hybride – Smart Hospital un use case vertical de Bouygues Télécom

Posté le by - 221 vues
Répondre

Cas d’usage hospitalier — Bouygues Telecom. La figure 1 a été récupérée sur le lien linkedIn d’Olivier Czechowski, Business Developer Smart Industries chez Bouygues Télécom.

Je remercie Olivier, Nicolas Boulenger (expert 5G) et son équipe pour la relecture de l’article et les corrections apportées.

Introduction — La 5G privée hybride en milieu hospitalier

La 5G privée s’impose progressivement comme l’infrastructure de connectivité de référence pour les réseaux de campus et les environnements critiques : usines, ports, campus universitaires, hôpitaux. Elle offre une latence maîtrisée, une isolation du trafic, et une qualité de service (QoS) garantie avec un nombre d’antennes moins important que le WiFi [1]. Le WiFi reste complémentaire à l’accès 5G.

L’architecture dite hybride correspond au modèle PNI-NPN (Public Network Integrated Non-Public Network), défini dans TS 23.501 §5.30.3. Elle distingue deux plans :

  • Plan de contrôle (CP) : AMF, SMF, PCF, UDM, AUSF, NRF hébergés dans l’infrastructure opérateur (Bouygues Telecom).
  • Plan utilisateur (UP) : l’UPF (User Plane Function) est déployée on-premise dans la salle informatique de l’hôpital, permettant un traitement local du trafic médical sensible.

Ce modèle est normalisé dans la spécification 3GPP TS 23.501 §5.6.5 (LADN — Local Area Data Network) et TS 23.548 (Edge Computing — MEC). Le schéma Bouygues Telecom illustre ce déploiement sur un bâtiment à 4 niveaux, chaque étage disposant d’un DAS 4G/5G, de small cells 5G NR et d’un UPF dédié (nommé LPG par Ericsson) situé dans l’hopital, permettant d’accéder au LAN de l’hôpital.

Figure 1 : Image issue d’un post linkedin de Olivier Czechowski

 

2. Les briques fondamentales du slicing 5G : S-NSSAI, DNN et SSC Mode

2.1 Le S-NSSAI — Single Network Slice Selection Assistance Information

Chaque tranche de réseau (slice) est identifiée par un indicateur de tranche S-NSSAI. Cet indicateur est défini dans la spécification 3GPP TS 23.501 §5.15.2. Il est composé de deux champs :

Champ Taille Description
SST (Slice/Service Type) 8 bits Type de service standardisé ou propriétaire (voir tableau ci-dessous)
SD (Slice Differentiator) 24 bits — optionnel Différenciateur permettant de distinguer plusieurs slices de même SST au sein d’un même PLMN (ex. deux slices URLLC distinctes)

 

SST standardisés (TS 23.501 Table 5.15.2.2-1) :

SST Nom Cas d’usage type
1 eMBB Enhanced Mobile Broadband — haut débit (smartphones soignants, tablettes EHR, vidéo HD)
2 URLLC Ultra-Reliable Low-Latency — IoT médical critique, MCX (Mission Critical Communications)
3 MIoT / mMTC Massive IoT — très grand nombre de capteurs à faible débit (thermomètres, badges RTLS)
4 V2X Vehicle-to-Everything — ambulances connectées (usage hospitalier marginal)
5 HMTC High Performance MTC
6 HDLLC High Data Low Latency Communication
7 GBRSS Guaranteed Bit Rate Streaming Service.
128/ 255 Propriétaire Valeurs réservées aux opérateurs pour des usages non standardisés

 

Le SD peut permettre à l’opérateur de définir des slices URLLC (SST=2) distinctes sans ambiguïté pour le réseau. Exemples :

  • {SST=2, SD=0x000001} — IoT médical critique (pompes à perfusion, capteurs temps réel)
  • {SST=2, SD=0x000002} — Communications MCX (voix/vidéo/alertes critiques)
  • {SST=1, SD=0x000003} — eMBB soignants (EHR/HIS, tablettes)

2.2 Le DNN — Data Network Name

Le DNN (Data Network Name) est défini dans les spécifications 3GPP TS 23.501 §5.8.2 et TS 23.003 §9A. Sa structure est identique à un FQDN (ex. hospital-iot, hospital-staff, hospital-mcx) avec une longueur maximale de 100 octets (TS 23.003 §9A.2).

En 4G, l’APN remplissait un rôle de résolution DNS : le MME construisait un FQDN à partir de l’APN (<APN>.apn.epc.mncXXX.mccYYY.3gppnetwork.org) pour résoudre l’adresse du PGW cible. En 5G, ce mécanisme DNS est remplacé par la fonction de découverte exposée par la fonction réseau NRF : la fonction AMF interroge la fonction NRF via le message REST Nnrf_NFDiscovery, en fournissant comme critères de sélection de la fonction SMF, le DNN, le S-NSSAI et le TAI (Tracking Area Identity) de l’UE. Le DNN conserve donc un rôle analogue à l’APN, mais combiné au S-NSSAI et au TAI, via une découverte de services REST plutôt que par DNS.

Le DNN remplit trois fonctions complémentaires :

  • Identification du Data Network : fonction première (TS 23.501 §5.8.2) — le DNN désigne le réseau de destination accessible via l’interface N6 de l’UPF, typiquement le Cloud entreprise (EHR/HIS, MCX) ou Internet.
  • Participation à la sélection du SMF et de l’UPF : le DNN est l’un des critères transmis par l’AMF au NRF lors de la découverte de la fonction SMF (avec le S-NSSAI et le TAI). Une fois la fonction SMF sélectionnée, celle-ci utilise le DNN, combiné au S-NSSAI, au SSC Mode et à la localisation de l’UE, pour choisir l’UPF approprié. Le DNN est donc un critère contributif — il n’est pas à lui seul déterminant.
  • Vérification de souscription : l’UDM stocke, pour chaque abonné, la liste des DNN autorisés par S-NSSAI. Le SMF vérifie cette cohérence lors de l’établissement de la PDU Session (TS 23.502 §4.3.2).

 

DNN et architecture hybride PNI-NPN

Dans une architecture PNI-NPN, un DNN hospital-iot sera associé à une fonction réseau SMF qui communique avec la fonction UPF on-premise de l’hôpital. Ces deux entités communiquent via l’interface N4/PFCP, mais elles n’appartiennent pas nécessairement au même plan d’adressage IP : l’UPF on-premise dispose d’une adresse dans le LAN de l’hôpital, tandis que la fonction réseau SMF est dans le plan d’adressage de l’opérateur. La joignabilité N4 entre eux est assurée par le MPLS L3 VPN (ou un VPN dédié plan de contrôle) qui interconnecte les deux domaines.

L’UE reçoit une adresse IP allouée par la fonction réseau SMF dans un pool d’adresses IP dédié au DNN, typiquement dans le plan d’adressage du Data Network cible (le Cloud médical). Ce n’est pas l’adresse de l’UPF ni celle du SMF — c’est une adresse routée par l’UPF via l’interface N6 vers le Cloud. Ainsi, depuis le Cloud médical, l’UE est visible comme un hôte du réseau privé hospitalier.

Un DNN internet pointera quant à lui vers une fonction UPF mutualisée dans le cœur opérateur avec sortie Internet directe, avec un pool d’adresses distinct. C’est cette configuration SMF — deux DNN, deux UPF, deux pools d’adresses, deux chemins N6 — qui matérialise concrètement la séparation des flux entre réseau privé médical et réseau public.

2.3 Le SSC Mode — Session and Service Continuity

Le Mode SSC définit le comportement de l’UPF anchor (PSA : PDN Session Anchor) lors d’un handover ou d’un déplacement de l’UE. Défini dans la spécification 3GPP TS 23.501 §5.6.9, le mode SSC s’applique par PDU Session.

Mode Nom Comportement UPF anchor Cas d’usage hospitalier
SSC Mode 1 Anchor fixe L’UPF anchor ne change pas. L’adresse IP de l’UE reste stable pendant toute la PDU Session. IoT médical et MCX : stabilité de l’adresse IP indispensable pour les flux TCP persistants et les sessions applicatives longues.
SSC Mode 2 Break-before-make L’ancienne PDU Session est libérée avant qu’une nouvelle soit établie avec un nouvel UPF anchor. L’UE obtient une nouvelle adresse IP. Services non-critiques tolérant une courte interruption (portail patient, déplacement RDC → Étage 3).
SSC Mode 3 Make-before-break Une nouvelle PDU Session est établie avant la libération de l’ancienne. Double tunnel transitoire. L’adresse IP change mais sans interruption de service. Soignants en déplacement inter-étages : continuité de l’application EHR sans coupure visible, malgré le changement d’adresse IP.

 

Le Mode SSC effectif est négocié lors de l’établissement de la session PDU (PDU Session Establishment) : l’UE propose un mode (via l’URSP), le SMF vérifie la compatibilité avec la souscription UDM et retourne le mode retenu dans le PDU Session Establishment Accept.

 

3. Call Flow d’enregistrement — Comment l’UE récupère le S-NSSAI

Procédure décrite dans TS 23.502 §4.2.2 et TS 24.501 §5.5.1.

3.1 Les types de NSSAI

NSSAI Description
Default Configured NSSAI Préconfigurée dans l’USIM (EF_5GS3GPPLOC) ou poussée par OTA/OMA-DM avant le premier enregistrement. Utilisée si l’UE n’a pas encore de Configured NSSAI pour ce PLMN.
Configured NSSAI Liste de S-NSSAI stockée persistamment dans l’UE pour un PLMN donné, après enregistrement réussi. Source : Registration Accept ou UE Configuration Update Command.
Requested NSSAI Liste envoyée par l’UE dans le Registration Request, construite à partir de la Configured NSSAI courante.
Allowed NSSAI Sous-ensemble retourné à l’UE dans le Registration Accept : slices effectivement utilisables pour les PDU Sessions.
Rejected NSSAI S-NSSAIs présents dans la Requested NSSAI mais non autorisés, avec cause de rejet (TS 24.501 §9.11.3.46A).

 

3.2 Séquence détaillée (TS 23.502 §4.2.2)

Étape 1 — Registration Request (UE → AMF) :

L’UE envoie un Registration Request NAS (TS 24.501 §8.2.6) contenant :

  • 5GS Registration Type : Initial / Periodic / Mobility
  • SUCI (ou 5G-GUTI si déjà enregistré)
  • Requested NSSAI : S-NSSAIs souhaités
  • UE 5G Security Capability, Last Visited TAI

Étape 2 — Authentication (AMF ↔ AUSF ↔ UDM) :

L’AMF déclenche 5G-AKA ou EAP-AKA’ (TS 33.501 §6.1). L’AUSF interroge l’UDM pour générer les vecteurs d’authentification. Le SUPI est dérivé du SUCI.

Étape 3 — Récupération du profil de souscription (AMF → UDM) :

Via l’interface N8, l’AMF envoie Nudm_SDM_Get (TS 29.503) pour récupérer :

  • Subscribed S-NSSAIs : slices souscrites (stockées dans l’UDR)
  • DNN autorisés par S-NSSAI : liste des DNN valides pour chaque slice
  • Access and Mobility Subscription Data, Session Management Subscription Data

Étape 4 — Validation du slice et consultation optionnelle du NSSF (AMF) :

Rôle exact de l’AMF et du NSSF

C’est la fonction AMF qui valide les S-NSSAIs : elle compare la Requested NSSAI de l’UE avec les Subscribed S-NSSAIs récupérés de l’UDM. Seule l’intersection constitue la base de l’Allowed NSSAI.

La fonction NSSF (TS 29.531) est consultée via le message Nnssf_NSSelection_Get pour un rôle distinct : sélectionner l’AMF Set ou l’AMF cible capable de servir les slices demandées (contexte multi-AMF, roaming, AMF spécialisée par slice). Il peut aussi retourner les NSSAIs de réseaux disponibles, mais elle n’effectue pas la validation de souscription abonné — responsabilité exclusive de l’AMF, appuyée sur l’UDM.

 

Étape 5 — Registration Accept (AMF → UE) :

L’AMF retourne le Registration Accept (TS 24.501 §8.2.7) contenant :

  • Allowed NSSAI : slices effectivement autorisées
  • Configured NSSAI : à stocker dans l’UE pour ce PLMN
  • Rejected NSSAI (si applicable) avec cause de rejet
  • 5G-GUTI, T3512 (timer periodic registration)

 

4. Sélection de la SMF — Rôle de la NRF et critères de découverte

Lors de l’établissement d’une session PDU, l’AMF doit sélectionner la SMF appropriée via la fonction NRF (Network Repository Function) et la procédure Nnrf_NFDiscovery (TS 29.510).

4.1 Déclenchement

L’UE envoie une requête PDU Session Establishment Request NAS à l’AMF contenant :

  • PDU Session ID : identifiant local UE (1–15)
  • S-NSSAI : doit faire partie de l’Allowed NSSAI
  • DNN : absent → SMF attribuera le DNN par défaut de la souscription
  • PDU Session Type : IPv4, IPv6, IPv4v6, Ethernet, Unstructured
  • SSC Mode : mode de continuité souhaité

4.2 Critères de découverte NRF (TS 29.510 §6.2.6)

Critère Détail
NF Type = SMF Filtre primaire : seuls les SMF sont retournés.
S-NSSAI Le SMF doit supporter le S-NSSAI demandé. Un SMF peut être dédié à certains slices uniquement (ex. SMF URLLC distinct du SMF eMBB).
DNN Le SMF doit être configuré pour servir ce DNN spécifique (hospital-iot, hospital-staff…).
TAI (Tracking Area Identity) Le SMF doit couvrir la zone géographique de l’UE — permet de sélectionner l’UPF on-premise le plus proche.
PLMN ID Pertinent en roaming : le SMF doit appartenir au PLMN home ou visité selon le modèle (HR, LBO).
Priorité / Capacité Le NRF retourne les SMF triés par priorité et charge. L’AMF peut appliquer du load balancing.

 

4.3 Création du contexte SMF

L’AMF envoie Nsmf_PDUSession_CreateSMContext (TS 29.502) au SMF sélectionné, contenant SUPI, PDU Session ID, S-NSSAI, DNN, PDU Session Type, SSC Mode, et le NAS message original encapsulé.

Le SMF récupère ensuite le Session Management Subscription Data depuis l’UDM (Nudm_SDM_Get, TS 29.503) pour vérifier que le DNN et le S-NSSAI demandés sont bien autorisés pour cet abonné, et obtenir les paramètres de session par défaut (SSC Mode autorisé, PDU Session Type autorisé, règles QoS par défaut, DNN par défaut si absent de la requête).

 

5. URSP — UE Route Selection Policy

L’URSP permet à l’UE de sélectionner automatiquement le bon S-NSSAI et le bon DNN selon l’application qui génère le trafic. Références : TS 23.503 §6.6 et TS 24.526.

5.1 Architecture des acteurs

Entité Rôle Interface
PCF Génère les règles URSP à partir des politiques stockées dans l’UDR (Npcf_UEPolicyControl) N7 (PCF ↔ AMF), N36 (PCF ↔ UDR)
AMF Transmet les règles URSP à l’UE via NAS — Registration Accept ou UE Configuration Update Command (TS 24.501 §8.2.29) N1 (AMF ↔ UE)
UE Stocke les règles URSP et les applique à chaque flux applicatif pour choisir la PDU Session cible —

5.2 Structure d’une règle URSP (TS 24.526 §5.2)

Chaque règle contient un Traffic Descriptor et un ou plusieurs Route Selection Descriptors ordonnés par priorité. L’UE évalue les règles dans l’ordre croissant de leur valeur de priorité (valeur la plus faible = priorité la plus haute).

Composant Sous-champ Exemple hospitalier
Traffic Descriptor IPv4/IPv6 destination + prefix 10.100.0.0/16 (plage IP Cloud médical)
FQDN ehr-hospital.fr, mcx.hopital.fr
App Descriptor (OS App ID) com.hospital.ehrclient (Android)
Match-all Trafic non classifié → slice par défaut
Route Selection Descriptor S-NSSAI {SST=2, SD=0x000001}
DNN hospital-iot, hospital-staff, hospital-mcx
SSC Mode 1 (anchor fixe) — recommandé pour usages critiques
PDU Session Type IPv4, IPv6, Ethernet

 

Le Traffic Descriptor URSP supporte nativement un composant OS-Id + OS-App-Id, introduit depuis 3GPP Release 16 (TS 24.526 §5.2, TS 23.503 §6.6.2).

Cela permet de cibler le trafic d’une application spécifique identifiée par son identifiant système d’exploitation et son nom de package applicatif. Ainsi, le trafic est orienté vers le réseau IP pour un usage eMBB classique vers le réseau opérateur ou vers le réseau de l’hôpital (les serveurs applicatifs).

 

5.3 Exemples de règles URSP hospitalières

Règle 1 —trafic IoT médical critique

Traffic Descriptor : IPv4 dest = 10.100.0.0/16

Route Selection : S-NSSAI={SST=2, SD=0x000001}, DNN=hospital-iot, SSC Mode=1, PDU Type=IPv4

→ Pompes à perfusion, capteurs de température → PDU Session sur l’UPF local, anchor fixe (SSC Mode 1) garantissant la stabilité de la session applicative.

Règle 2 — applications soignants (EHR/HIS)

Traffic Descriptor : FQDN = *.ehr-hospital.fr

Route Selection : S-NSSAI={SST=1, SD=0x000003}, DNN=hospital-staff, SSC Mode=3, PDU Type=IPv4

→ Smartphones et tablettes soignants → PDU Session sur l’UPF, transit vers Cloud via MPLS. SSC Mode 3 (make-before-break) pour les déplacements inter-étages sans coupure visible de l’application EHR.

 

Règle 3 — communications MCX

Traffic Descriptor : App Descriptor = com.hospital.mcx

Route Selection : S-NSSAI={SST=2, SD=0x000002}, DNN=hospital-mcx, SSC Mode=1, PDU Type=IPv4

→ Push-to-talk critique, vidéo alertes → PDU Session dédiée MCX. SSC Mode 1 obligatoire : un groupe MCX actif ne peut pas tolérer de changement d’adresse IP en cours de communication.

Règle 4 — Priorité 100 (défaut) : accès Internet pour les salariés qui ont une carte SIM dédiée (hopital)

Traffic Descriptor : Match-all

Route Selection : S-NSSAI={SST=1}, DNN=internet, SSC Mode=2, PDU Type=IPv4v6

→ Smartphones patients, portail patient, divertissement → slice eMBB public, sortie Internet via UPF mutualisé opérateur.

5.4 Provisionnement des règles URSP avec OS-Id et OS-App-Id — Déploiement à l’échelle hospitalière

Les règles URSP décrites doivent être présentes sur chaque UE des professionnels de santé dès la mise en service. L’enjeu du provisionnement de masse est triple :

  • Cohérence : tous les UE d’un même profil (soignant, technicien biomédical, agent MCX) appliquent les mêmes règles.
  • Mise à jour : toute évolution applicative (nouvel OS-App-Id, nouvelle slice) doit se propager sans intervention manuelle.
  • Traçabilité : l’opérateur et l’IT hospitalier doivent pouvoir auditer les règles effectivement en vigueur sur les UE.

Deux canaux de provisionnement coexistent en 5G : le provisionnement réseau (PCF → UE via NAS) et le provisionnement OTA/MDM hors-bande.

Le provisionnement réseau

La politique est stockée dans l’UDR (Unified Data Repository) sous forme de UE Policy par abonné ou par groupe d’abonnés (Policy Group).

Pour une 5G privée hospitalière, l’IT provisionnera typiquement 3 profils de groupe :

Groupe OS-App-Id inclus S-NSSAI cible
soignants com.hospital.ehrclient, com.hospital.his SST=1, SD=0x000003
biomédical com.hospital.iotmanager, com.hospital.devicemonitor SST=2, SD=0x000001
Mcx com.hospital.mcx, com.hospital.pushtoalk SST=2, SD=0x000002

Un abonné appartient à un groupe via son SUPI → profil UDM → Policy Group ID → PCF récupère les règles URSP du groupe au niveau de l’UDM/UDR.

Provisionnement OTA via OMA-DM / MDM (canal complémentaire)

Le provisionnement réseau (PCF) gère les règles URSP au sens 3GPP. Mais l’OS-Id/OS-App-Id implique une coordination avec l’OS de l’UE (Android/iOS) qui, lui, est géré par un MDM (Mobile Device Management).

Pourquoi le MDM est indispensable :

L’UE ne peut appliquer une règle URSP basée sur un OS-App-Id que si :

  1. L’application hospital.ehrclient est installée sur l’UE.
  2. L’OS Android expose l’identité de l’application à la couche NAS (interface OS-URSP, TS 24.526 §4.2).
  3. Le profil MDM autorise cette exposition (certains profils MDM restrictifs désactivent l’API OS-URSP).

Le MDM (typiquement Microsoft Intune, VMware Workspace ONE, ou SOTI MobiControl en milieu hospitalier) gère :

Fonction MDM Lien avec URSP OS-App-Id
Déploiement de l’application Installe com.hospital.ehrclient via App Store managé
Profil réseau Android (AOSP Network Policy) Active l’exposition OS-App-Id à la couche modem
Configuration APN/DNN de fallback Garantit un DNN par défaut si URSP non encore reçu
Mise à jour des App-IDs En cas de changement de package name applicatif

5.5 OS-Id standardisés — Référence GSMA NG.114

L’OS-Id est un UUID de 16 octets alloué par la GSMA (registre GSMA NG.114). Les valeurs pour les OS courants en milieu hospitalier :

OS OS-Id (UUID)
Android (AOSP) 97a498e3-fc92-5c94-8986-0333d379d3ae
iOS / iPadOS 4daf3eb8-2d37-4a95-b951-5e44b3f93f0e
Windows fe0b4dfa-06f6-4ad1-9dc4-c85d0e0d4d76

Pour un déploiement Android Enterprise (profil professionnel hospitalier), seul l’OS-Id Android est pertinent. L’OS-App-Id correspond au package name de l’application (identifiant applicationId dans le build.gradle de l’app).

Encodage dans le Traffic Descriptor (TS 24.526 §5.2.1, type 0x02) :

Octet 1     : Type = 0x02 (OS-Id + OS-App-Id)Octets 2–17 : OS-Id (16 octets UUID)              = 97 A4 98 E3 FC 92 5C 94 89 86 03 33 D3 79 D3 AEOctet 18    : longueur OS-App-Id (UTF-8)Octets 19–N : OS-App-Id = « com.hospital.ehrclient » (UTF-8)

6. Établissement de session PDU— Rôle de l’UPF et du SMF

Référence : TS 23.502 §4.3.2.

6.1 Séquence

Étape 1 — PDU Session Establishment Request (UE → AMF) :

  • NAS contenant : PDU Session ID, S-NSSAI, DNN, PDU Session Type, SSC Mode

Étape 2 — Sélection du SMF (AMF → NRF → SMF) :

  • L’AMF interroge le NRF via Nnrf_NFDiscovery (S-NSSAI, DNN, TAI) — voir section 4.

Étape 3 — Session Context Creation (AMF → SMF) :

  • L’AMF envoie Nsmf_PDUSession_CreateSMContext (TS 29.502).
  • Le SMF vérifie le profil de souscription UDM (TS 29.503) : DNN autorisé, SSC Mode, QoS par défaut.

Étape 4 — Configuration de l’UPF (SMF → UPF via N4/PFCP) :

  • Le SMF sélectionne l’UPF on-premise selon DNN et TAI, puis pousse via PFCP (TS 29.244) :
    • PDR (Packet Detection Rules), FAR (Forwarding Action Rules), QER (QoS Enforcement), URR (Usage Reporting)

Étape 5 — PDU Session Establishment Accept (SMF → AMF → UE) :

  • L’UE reçoit l’adresse IP attribuée, les paramètres QoS (5QI, ARP, GFBR, MFBR) et les informations de tunnel N3 (TEID, adresse UPF).

 

7. Routage entreprise — MPLS L3 VPN entre l’UPF et le Cloud

Le trafic sortant de l’UPF via l’interface N6 est acheminé soit vers le LAN de l’hôpital, soit vers le réseau de l’opérateur.

La signalisation entre le SMF et l’UPF via l’interface N4 est échangée entre le cœur de réseau de l’opérateur et l’UPF dédié.

La technologie de transport privilégiée repose sur le MPLS L3 VPN (RFC 4364), garantissant la sécurisation de la signalisation en isolant les flux et par le chiffrement et l’intégrité. Les flux initiaux N4 ou N6 sont encapsulés en IPSEC et chiffrés.

Par ailleurs, la résilience de l’architecture est assurée par l’utilisation de deux fibres distinctes, chacune reliant un UPF au SMF.

7.1 Pourquoi MPLS L3 VPN ?

Critère Justification pour la 5G privée hospitalière
Isolation du trafic VRF dédié : isolation totale du trafic médical vis-à-vis du trafic Internet public. Conforme RGPD et HDS (Hébergeur Données de Santé).
SLA garanti L’opérateur engage des niveaux de service (latence, jitter, disponibilité) contractuels sur le backbone MPLS.
QoS end-to-end Classes de service MPLS (EXP/TC bits) : priorisation des flux MCX critiques sur le backbone opérateur.
Scalabilité Ajout de sites (nouveaux UPF) sans reconfiguration du cœur : le PE intègre le nouveau site dans le VRF existant via MP-BGP.
Sécurité Trafic encapsulé dans les labels MPLS ; pas d’exposition Internet. Complémentaire avec IPsec pour le chiffrement des données de santé.

 

7.2 Architecture MPLS L3 VPN (RFC 4364)

  • CE (Customer Edge) : routeur hôpital, connecté au PE via liaison dédiée.
  • PE (Provider Edge) : routeur opérateur en bordure du backbone. Maintient un VRF dédié par client. Distribue les routes via MP-BGP (AFI=1, SAFI=128).
  • P (Provider Core) : routeurs cœur MPLS — forwarding sur labels uniquement, aucune connaissance des routes privées client.

7.3 Mécanisme de forwarding

  1. UPF → CE (N6) : paquet IP natif, routage local vers le CE.
  2. CE → PE ingress : le PE identifie le VRF client et impose deux labels en empilement (label stacking) :
  • Label externe (transport label) : label du LSP vers le PE de sortie, distribué par LDP ou RSVP-TE.
  • Label interne (VPN label) : identifie le VRF de destination sur le PE de sortie, distribué par MP-BGP avec les Route Targets (RT).
  1. Backbone MPLS : routeurs P — commutation sur le label externe uniquement (Penultimate Hop Popping — PHP sur le dernier P).
  2. PE egress → CE Cloud : décapsulation MPLS, lookup IP dans la VRF FIB, transmission vers l’endpoint Cloud.

7.4 Interfaces 5GC et backbone MPLS

Interface 3GPP Protocole Rôle et remarque
N6 IP natif (après décapsulation GTP-U par l’UPF) Trafic utilisateur UE → Cloud. Traverse le MPLS L3 VPN via le CE hôpital.
N4 PFCP (UDP/IP, port 8805) Contrôle SMF → UPF on-premise. Recommandé dans un VRF séparé dédié au plan de contrôle, avec QoS prioritaire.
N3 GTP-U (UDP/IP) Trafic gNB → UPF. Interne au LAN hospitalier pour un UPF on-premise — ne traverse pas le backbone opérateur.

 

Interface N4 et disponibilité

L’interface N4/PFCP entre le SMF (opérateur) et l’UPF (on-premise hôpital) est critique : toute interruption empêche le SMF de mettre à jour les règles de forwarding de l’UPF. Il est fortement recommandé de la faire transiter via un VRF séparé distinct du VRF de données utilisateur, avec une priorité QoS élevée sur le backbone MPLS.  Il faut aussi assurer une sécurisation du CE sur le transport (2 chemins de transport) afin de maintenir un taux de disponibilité élevé

 

8. Synthèse de l’architecture end-to-end

Trajet complet d’un paquet généré par un capteur IoT médical (Étage 2 — Soins intensifs) vers le Cloud EHR :

# Segment Technologie Détail
1 Capteur IoT → Small cell 5G NR (TS 38.211) Liaison radio NR, slot format URLLC
2 Small cell → UPF Étage 2 (N3) GTP-U / UDP / IP Tunnel GTP-U entre gNB et UPF local (LAN hôpital)
3 UPF → CE hôpital (N6) IP natif Décapsulation GTP-U, lookup VRF, vers CE
4 CE hopital → Serveurs EHR IP (Serveur) Routage vers le serveur local de l’hopital

 

9. Références normatives

Référence Titre et section pertinente
TS 23.501 System Architecture for 5G — §5.15 (Slicing), §5.6.5 (LADN), §5.6.9 (SSC), §5.8.2 (DNN), §5.30.3 (PNI-NPN)
TS 23.002 Network Architecture — §4A (DNN/APN)
TS 23.003 Numbering, Addressing — §9A (DNN structure, 100 octets max)
TS 23.502 Procedures for 5G — §4.2.2 (Registration), §4.3.2 (PDU Session Establishment)
TS 23.503 Policy and Charging Control — §6.6 (URSP)
TS 23.548 5G System Enhancements for Edge Computing (MEC)
TS 24.501 NAS Protocol for 5G — §5.5.1, §8.2.6/8.2.7, §8.2.29, §9.11.3.46A
TS 24.526 UE policies for 5G — §5.2 (URSP Traffic Descriptors, Route Selection Descriptors)
TS 29.244 Interface CP / UP nodes — PFCP, N4
TS 29.502 SMF Services — Nsmf_PDUSession
TS 29.503 UDM Services — Nudm_SDM (profil souscription)
TS 29.510 NRF Services — Nnrf_NFDiscovery, critères SMF/UPF
TS 29.531 NSSF Services — Nnssf_NSSelection (sélection AMF Set)
TS 33.501 Security Architecture for 5G — §6.1 (5G-AKA), §6.2 (EAP-AKA’)
RFC 4364 BGP/MPLS IP Virtual Private Networks (L3 VPN)
RFC 3031 Multiprotocol Label Switching Architecture (MPLS)

 

 

La fonction SCP : proxy applicatif spécialisé pour la signalisation inter-NF

Posté le by - 121 vues
Répondre

Nous allons voir dans cet article la fonction SCP Service Communication Proxy proposée dans la Rel-16 pour apporter une souplesse dans le déploiement du 5GC et dans la communication entre les fonctions NF.

Dans le cœur de réseau 5G (5GC), tout est service. Une fonction réseau (NF) n’appelle plus forcément une autre NF via une interface point à point figée comme en EPC (S1, S5, S11…) : elle consomme un service exposé en HTTP/2, décrit en JSON, au sein d’une architecture orientée services — la SBA, Service-Based Architecture (3GPP TS 23.501 §7).

Mais « orienté services » ne dit pas comment la requête voyage concrètement entre le consommateur (NFc) et le producteur (NFp). Sur ce point, la 3GPP définit quatre modèles de communication, désignés modèles A, B, C et D (TS 23.501 §7.1.1). Ils se distinguent par une question simple : qui découvre le producteur, qui le sélectionne, et qui route effectivement la requête ?

Le socle commun : le NRF

Avant de comparer les modèles, un mot sur la fonction qui rend tout ça possible : le NRF (Network Repository Function). Chaque instance de NF s’y enregistre avec un profil (NFProfile, TS 29.510 §6.1.6.2) décrivant son type, son statut, les slices qu’elle sert (sNssais), sa charge courante (load), sa capacité configurée (capacity), sa localisation, et bien d’autres attributs. C’est sur cette base que repose toute logique de discovery (trouver les candidats) et de sélection (choisir le bon candidat parmi eux).

Ce qui change d’un modèle à l’autre, c’est seulement la répartition de ces deux tâches — discovery et sélection — entre le consommateur et un composant que l’on n’a pas encore présenté : le SCP.

Modèles A et B : la communication directe

Dans les modèles A et B, le NFc parle directement au NFp, sans intermédiaire de routage.

Modèle A — sans discovery. Le consommateur connaît déjà l’adresse du producteur, configurée statiquement. Aucune interrogation du NRF n’a lieu au moment de l’appel. C’est simple, mais rigide : ça ne tient pas la route dès que les instances NF sont déployées, retirées ou redimensionnées dynamiquement — exactement le genre de souplesse qu’on recherche en environnement cloud-native.

Modèle B — avec discovery, sans SCP. Le consommateur interroge le NRF (Nnrf_NFDiscovery_Request), reçoit une liste de candidats (SearchResult, TS 29.510 §6.2.3), applique lui-même sa logique de sélection (charge, localisation, slice…), puis contacte directement l’instance choisie. La découverte est dynamique, mais chaque NFc doit implémenter sa propre logique de discovery et de sélection — du code répété dans chaque type de NF.

Le SCP : un proxy de service, pas un simple routeur

Les modèles C et D introduisent le SCP (Service Communication Proxy), une fonction réseau à part entière dont le rôle est de gérer l’échange de signalisation entre NFs. Deux déploiements sont possibles : colocalisé avec chaque NF (modèle sidecar, comme dans un service mesh applicatif), ou centralisé comme une entité à part.

Le SCP agit comme un routeur de service et, selon le modèle, comme un agent de sélection : il peut interroger lui-même le NRF pour obtenir les paramètres de sélection (charge, capacité, localisation) d’un ensemble d’instances, et choisir la plus appropriée au moment du routage — une décision mécaniquement plus fraîche que celle prise par un NFc qui aurait mis en cache un résultat de discovery plus ancien (borné par le validityPeriod de la réponse NRF et le heartBeatTimer de chaque instance enregistrée).

Modèle C : le NF consommateur garde la main sur la découverte

Dans le modèle C, le NFc continue d’interroger le NRF et d’appliquer sa propre logique de sélection — exactement comme en modèle B. La différence se situe après : au lieu de contacter directement le producteur, le NFc envoie sa requête au SCP, en indiquant l’adresse cible.

Deux cas se présentent. Si cette adresse pointe vers une instance unique, le SCP se contente de router — un simple relais. Si elle pointe vers un NF Set (un ensemble d’instances interchangeables), le SCP doit lui-même sélectionner une instance dans ce set, en interrogeant si besoin le NRF pour affiner son choix.

Le NFc fait donc toujours le gros du travail de discovery et de sélection, mais délègue le routage réseau au SCP — un point de contrôle centralisé qui apporte de la résilience et de l’observabilité, sans simplifier la logique côté consommateur.

Modèle D : la découverte déléguée

Le modèle D va plus loin : le NFc ne fait ni discovery ni sélection. Il construit sa requête avec uniquement les critères nécessaires — type de NF cible, S-NSSAI, DNN, zone géographique — typiquement transmis via les en-têtes 3gpp-Sbi-Discovery-* en HTTP/2 (TS 29.500), et envoie le tout au SCP.

C’est le SCP qui interroge le NRF, obtient les candidats correspondants, effectue la sélection finale, puis route la requête. Le NFc n’a plus besoin de connaître le NRF ni d’implémenter quoi que ce soit en matière de sélection : toute cette intelligence est centralisée dans le SCP — au prix d’un SCP qui doit être nettement plus robuste et complet.

Quel modèle pour quel déploiement ?

Il n’y a pas de modèle « supérieur » dans l’absolu — seulement des compromis différents.

Le modèle A reste pertinent pour des relations NF figées à petite échelle, là où la complexité d’un NRF ne se justifie pas. Le modèle B convient à des déploiements dynamiques mais de taille modeste, où dupliquer la logique de sélection dans chaque NF reste acceptable. Le modèle C apporte de la résilience et de l’observabilité centralisée sans renoncer à la maîtrise de la sélection côté consommateur — un bon compromis pour des architectures en transition. Le modèle D, enfin, est celui qui s’aligne le mieux avec une approche service mesh à grande échelle : il simplifie radicalement chaque NF, au prix de concentrer une responsabilité critique — et donc une exigence de robustesse accrue — sur le SCP.

En pratique, un même cœur de réseau 5G n’est pas obligé de choisir un seul modèle pour toutes ses interactions : certains flux peuvent rester en communication directe (B) tandis que d’autres transitent par un SCP en mode délégué (D), selon la criticité, la fréquence d’appel, ou la maturité de l’infrastructure de routage déployée par l’opérateur.

Références : 3GPP TS 23.501 §6.3 et §7.1.1 (NF Service Framework) ; TS 29.500 (en-têtes de découverte HTTP/2) ; TS 29.510 (Nnrf_NFDiscovery, schémas NFProfile et SearchResult).

Comprendre la 5G – NTN Part 4

Posté le by - 105 vues
Répondre

Suite de l’article : Comprendre la 5G – NTN Part 3

Variabilité Temporelle et Mises à Jour

Mobilité du Satellite (LEO)

Pour les constellations LEO, le satellite se déplace rapidement par rapport à la Terre (vitesse orbitale ~7.5 km/s pour un satellite à 600 km).

Taux de variation de la distance :

dD/dt ≈ v_sat × cos(θ)

où θ est l’angle entre le vecteur vitesse du satellite et la direction UE-satellite.

Impact sur TA : Le TA doit être mis à jour régulièrement. Le taux de variation du TA est :

dTA/dt = (1/c) × dD/dt

Exemple numérique :

  • v_sat = 7 500 m/s
  • Angle défavorable : cos(θ) = 0.7
  • dD/dt = 5 250 m/s
  • dTA/dt = 5 250 / (3×10⁸) ≈ 17.5 µs/s ≈ 1.05 ms/minute

Le TA change donc d’environ 1 ms par minute, nécessitant des mises à jour fréquentes.

Périodicité des Mises à Jour

Le 3GPP TS 38.213 définit que les mises à jour de TA doivent être envoyées lorsque l’erreur de TA dépasse un seuil. En NTN, ce seuil est adapté mais le principe reste :

Fréquence de mise à jour du TA :

  • LEO : Toutes les 10-100 secondes (selon la géométrie)
  • GEO : Très rarement (satellite quasi-stationnaire)

Fréquence de mise à jour de Koffset/Kmac :

  • LEO : Toutes les 1-10 secondes (éphémérides mises à jour)
  • GEO : Rarement (peut être fixe)

Prédiction et Compensation Doppler

La variation de distance induit également un effet Doppler en fréquence qui doit être compensé. La compensation Doppler en NTN (TS 38.821) peut être :

  1. Pré-compensée par l’UE (Common TA/Doppler pre-compensation)
  2. Compensée par le satellite (si régénératif)
  3. Combinaison des deux

Le calcul du décalage Doppler est :

f_doppler = -f_carrier × (v_radiale / c)

où v_radiale = dD/dt (vitesse radiale).

Architectures NTN et Implications

Transparent Payload

Dans une architecture transparente (bent-pipe), le satellite est un simple répéteur :

  • TA pré-compensé : Obligatoire côté UE
  • Koffset : Calculé par l’UE ou fourni par le réseau
  • Kmac : Géré localement par l’UE
  • Commandes TA résiduelles : Envoyées par le gNB au sol

L’UE doit avoir des capacités GNSS et de calcul d’éphémérides.

Regenerative Payload

Dans une architecture régénérative, le satellite décode et ré-encode les signaux :

  • TA : Peut être géré partiellement par le satellite
  • Koffset : Split entre segment spatial et terrestre
  • Kmac : Géré par le satellite gNB

Cette approche réduit la complexité UE mais augmente celle du satellite.

Choix de l’Architecture

Le choix entre transparent et régénératif impacte directement la gestion de TA, Koffset et Kmac :

Aspect Transparent Régénératif
TA pré-compensé UE obligatoire Optionnel
Complexité UE Élevée (GNSS+calcul) Modérée
Complexité satellite Faible Élevée
Latence minimale RTT complet RTT segment
Efficacité spectrale Modérée Élevée

Défis et Limitations

Précision de Localisation

L’efficacité du TA pré-compensé dépend de la précision GNSS de l’UE :

  • GPS standard : Précision ~5-10 m → erreur TA ~33-66 ns
  • GNSS augmenté : Précision ~1 m → erreur TA ~6.6 ns

Avec c = 3×10⁸ m/s, une erreur de position de 10 m induit une erreur de TA de ~33 ns, ce qui reste négligeable par rapport au Tc ≈ 0.509 ns mais peut s’accumuler.

Latence des Éphémérides

Les éphémérides sont diffusées dans les SIB avec une périodicité de quelques secondes. Durant cet intervalle, la position du satellite (LEO) a changé, induisant une erreur dans le calcul de TA pré-compensé.

Atténuation : Utiliser des modèles de prédiction d’orbite (propagateurs Kepler/SGP4) avec les paramètres orbitaux.

Délai de Feeder Link

Le délai feeder link (satellite ↔ gateway) est souvent variable en fonction de :

  • Charge du réseau backbone
  • Routage IP
  • Traitement dans les gateways

Cette variabilité introduit un jitter qui doit être absorbé par les buffers et compensé par les mises à jour de TA résiduel.

Consommation Énergétique

Le calcul fréquent de TA pré-compensé, Koffset et Kmac par l’UE consomme de l’énergie :

  • Acquisition GNSS continue
  • Calculs trigonométriques pour les distances
  • Traitement des éphémérides

Optimisations :

  • Utiliser des prédictions au lieu de recalculer à chaque slot
  • Mode discontinu avec réveil périodique
  • Offload vers le réseau si possible

Conclusion

La gestion temporelle en 5G NTN représente un défi majeur que le 3GPP a relevé par l’introduction de mécanismes sophistiqués :

  1. Le Timing Advance (TA) pré-compensé permet à l’UE de calculer lui-même la majorité de l’avance temporelle nécessaire, réduisant la charge sur le réseau et permettant une synchronisation initiale rapide malgré les délais importants.
  2. Le Round-Trip Time (RTT) étendu, pouvant atteindre 520 ms en GEO, impose une refonte complète des procédures HARQ et des fenêtres de retransmission.
  3. Koffset compense le RTT dans les relations temporelles de scheduling et HARQ, permettant au système de fonctionner malgré des délais de propagation dépassant largement la durée d’une trame.
  4. Kmac assure que la couche MAC prépare les données suffisamment en avance pour que la couche physique puisse appliquer le TA important requis en NTN.

Ces mécanismes, standardisés dans les TS 38.213, 38.214, 38.321 et 38.821, permettent à la 5G NR de s’étendre au-delà de son domaine terrestre initial pour embrasser les réseaux satellites, ouvrant la voie à une connectivité globale véritablement ubiquitaire.

Les défis restants portent sur l’optimisation de la consommation énergétique des UEs, la gestion de la mobilité satellite (particulièrement pour les constellations LEO), et l’interopérabilité entre segments terrestres et non-terrestres dans les architectures hybrides futures.

Références 3GPP

  • TS 38.211 – Physical channels and modulation
  • TS 38.213 – Physical layer procedures for control
  • TS 38.214 – Physical layer procedures for data
  • TS 38.300 – NR and NG-RAN Overall description
  • TS 38.321 – Medium Access Control (MAC) protocol specification
  • TS 38.331 – Radio Resource Control (RRC) protocol specification
  • TS 38.821 – Solutions for NR to support non-terrestrial networks (NTN)

Glossaire

  • ECEF : Earth-Centered, Earth-Fixed (système de coordonnées)
  • GEO : Geostationary Earth Orbit
  • GNSS : Global Navigation Satellite System
  • HARQ : Hybrid Automatic Repeat Request
  • LEO : Low Earth Orbit
  • MAC : Medium Access Control
  • NTN : Non-Terrestrial Networks
  • PDSCH : Physical Downlink Shared Channel
  • PUCCH : Physical Uplink Control Channel
  • PUSCH : Physical Uplink Shared Channel
  • RTT : Round-Trip Time
  • SCS : Subcarrier Spacing
  • SIB : System Information Block
  • TA : Timing Advance
  • TAC : Timing Advance Command
  • UE : User Equipment

 

Comprendre la 5G – NTN Part 3

Posté le by - 142 vues
Répondre

Suite de l’article Comprendre la 5G – NTN Part 2

L’Ordonnancement Temporel : Koffset et Kmac

Le Problème de la Latence HARQ

Dans un réseau 5G NR terrestre, le mécanisme HARQ (Hybrid Automatic Repeat Request) suit un timing strict défini par le 3GPP TS 38.214 :

  1. Slot n : Transmission downlink du PDSCH
  2. Slot n+k : Réception de l’ACK/NACK dans le PUCCH uplink
  3. Slot n+k+k’ : Retransmission éventuelle

Les valeurs de k sont typiquement petites (4 à 8 slots) car le RTT terrestre est faible.

En NTN, avec un RTT de plusieurs millisecondes voire centaines de millisecondes, ces valeurs deviennent inadaptées. Le 3GPP a donc introduit Koffset et Kmac.

Le décalage Koffset associé au temps de propagation introduit une latence élevée pour l’acquittement. La 5G NTN propose d’augmenter le traitement en parallèle de 16 processus à 32 processus pour éviter un effondrement du débit par attente d’acquittement (HARQ Stalling). Mais la 3GPP propose également de désactiver le processus HARQ.

Koffset : Compensation du Délai de Propagation

Le paramètre Koffset est défini dans le TS 38.214 (amendements NTN) et représente un offset temporel additionnel pour compenser le délai de propagation NTN. Afin de comprendre l’intérêt de ce paramètre, revenons sur le cas d’usage de la 5G terrestre.

Lorsque la station de base envoie des informations de contrôle DCI, c’est pour :

  • Informer l’UE qu’il recevra des données en DL. L’UE répondra à la station de base en transmettant un acquittement HARQ.
  • Informer l’UE qu’il peut émettre des données en UL

La 5G terrestre définit des indicateurs K0, K1 et K2 :

  • K0 : retard entre la réception de l’information DCI et la réception des données sur le canal PDSCH
  • K1: retard entre la réception de l’information DCI et l’émission de l’acquittement sur le canal PUCCH
  • K2: retard entre la réception de l’information DCI et l’émission des données sur le canal PUSCH

La valeur de K0, K1 et K2 sont des paramètres d’ordonnancement fixés à la durée de quelques sous-trames. Par exemple K1 vaut 3 ms, ce qui signifie que la station de base s’attend à recevoir cet acquittement 3 ms après l’émission du DCI. Du point de vue de l’UE, celui-ci dispose de moins de 3 ms pour récupérer la trame radio, l’acquitter et l’envoyer à la station de base (il faut prendre en compte la propagation DL et UL donc le TA). Si le TA est supérieur à 3 ms, il est impossible que l’acquittement soit reçu sur la sous-trame dédié.

Figure 1 : L’acquittement émis par l’UE et reçu par le gNB

Dans le cas ou la commande DCI demande à l’UE de transmettre un paquet montant, ce paquet doit être reçu à K2+Koffset trames après la commande DCI. La valeur du Koffset garantit que le nombre de sous-trames pour la réception du paquet au niveau du gNB est supérieur au RTT maximal. Il s’agit bien d’un paramètre d’ajustement d’ordonnancement « grossier ».

Figure 2 : La réception du paquet UL reçu par le gNB (Rohde et Schwarz)

Définition et Calcul

Koffset = ⌈2 × T_propagation / T_slot⌉

où :

  • T_propagation = délai de propagation unidirectionnel UE↔satellite↔gateway
  • T_slot = durée d’un slot (dépend de la numérologie)

Exemple LEO (600 km, élévation 30°) :

  • Distance UE-satellite : ~693 km
  • Distance satellite-gateway : ~693 km
  • T_propagation : (693 + 693) km / c ≈ 4.6 ms
  • Avec SCS 15 kHz (T_slot = 1 ms) : Koffset ≈ 10 slots

Exemple GEO (35 786 km) :

  • Distance totale : ~80 000 km (UE-SAT-GW)
  • T_propagation : ~267 ms
  • Avec SCS 15 kHz : Koffset ≈ 534 slots

Application de Koffset

Koffset est appliqué aux relations temporelles suivantes (TS 38.214) :

Pour PDSCH → HARQ-ACK :

Slot_HARQ-ACK = Slot_PDSCH + K1 + Koffset

Pour DCI → PUSCH :

Slot_PUSCH = Slot_DCI + K2 + Koffset

où K1 et K2 sont les valeurs configurées normalement en NR terrestre.

Configuration de Koffset

Koffset peut être :

  1. Calculé par l’UE (mode pré-compensé) en fonction des éphémérides et de sa position
  2. Signalé par le réseau via les SIB ou RRC (mode transparent)

Le choix dépend de l’architecture NTN (transparent vs régénératif) et de la capacité de l’UE à calculer les paramètres temporels.

Kmac : Timing Advance pour la Couche MAC

Le paramètre Kmac est intimement lié au Timing Advance mais opère au niveau de la couche MAC. Il représente le délai à appliquer aux PDU MAC pour tenir compte du TA en NTN.

Distinction TA vs Kmac

  • TA (Timing Advance) : Appliqué au niveau physique (PHY), avance le timing de transmission RF

Kmac : Appliqué au niveau MAC, avance la préparation et l’envoi des MAC PDU à la couche physique

Figure 3 : La liaison NTN (illustration 3GPP)

Le point de référence correspond à l’alignement entre la trame physique UL et DL. Mais il faut prendre en compte la distance entre la couche MAC du gNB terrestre et le point de référence. La 3GPP propose un décalage UL/DL afin de compenser de manière transparente à l’UE.

Figure 4 : Les timers Koffset et Kmac (Rohde et Schwarz)

De plus, lorsque le satellite se déplace, il peut suspendre sa connexion feeder avec une passerelle terrestre (nommée passerelle source) et activer une connexion feeder avec une autre passerelle terrestre (nommée passerelle cible). Le routage IP est anticipé pour éviter d’avoir une latence importante, mais on peut imaginer que qu’avant routage la passerelle terrestre contient le gNB DU et le RRU et après routage, le gNB DU est resté sur la passerelle source et le RU est au niveau de la passerelle cible ce qui modifie le désalignement DL/UL.

Cas Pratiques et Dimensionnement

Scénario LEO (600 km)

Considérons un satellite LEO à 600 km d’altitude, avec un UE à une élévation de 30°.

Paramètres géométriques :

  • Distance UE-satellite : ~693 km
  • Distance satellite-gateway (supposé au nadir) : ~693 km
  • Distance totale : 1 386 km

Calculs temporels :

RTT = 2 × 1 386 / 300 000 ≈ 9.24 ms

TA_precomp = 1 386 / 300 000 ≈ 4.62 ms

Avec SCS 15 kHz (T_slot = 1 ms) :

Koffset = ⌈9.24⌉ = 10 slots

Kmac = ⌈4.62⌉ = 5 slots

Avec SCS 30 kHz (T_slot = 0.5 ms) :

Koffset = ⌈9.24 / 0.5⌉ = 19 slots

Kmac = ⌈4.62 / 0.5⌉ = 10 slots

Scénario GEO (35 786 km)

Pour un satellite géostationnaire :

Paramètres géométriques :

  • Distance UE-satellite : ~38 000 km (élévation 30°)
  • Distance satellite-gateway : ~40 000 km
  • Distance totale : ~78 000 km

Calculs temporels :

RTT = 2 × 78 000 / 300 000 ≈ 520 ms

TA_precomp = 78 000 / 300 000 ≈ 260 ms

Avec SCS 15 kHz :

Koffset = ⌈520⌉ = 520 slots

Kmac = ⌈260⌉ = 260 slots

Impact sur les Ressources Système

Ces valeurs importantes ont des conséquences majeures :

  1. Processus HARQ :
  • Nombre de processus HARQ nécessaires : Au moins RTT/TTI
  • En GEO avec SCS 15 kHz : 520 processus HARQ minimum
  • En NR terrestre : Typiquement 8-16 processus
  1. Mémoire requise :
  • Buffers MAC : Kmac × taille_MAC_PDU × nombre_UE
  • Buffers HARQ : RTT × débit_pic
  • En GEO : Plusieurs dizaines de MB par UE
  1. Complexité du scheduleur :
  • Fenêtre de scheduling : Kmac + Koffset slots
  • En GEO : Planification sur ~780 slots (7.8 secondes avec SCS 15 kHz)

Comprendre la 5G – NTN Part 2

Posté le by - 214 vues
Répondre

Suite de l’article Comprendre la 5G – NTN Part 1

Le Timing Advance (TA) : Compenser le Délai de Propagation

Principe Fondamental du TA

Le Timing Advance est un mécanisme fondamental des réseaux de mobiles (cf. 3GPP TS 38.213 pour la 5G NR – Section 4.2). Son objectif est de garantir que les transmissions uplink de tous les UEs arrivent synchronisées à la station de base (gNB ou satellite).

Sans TA, les transmissions de différents UEs situés à des distances variables arriveraient à des instants différents, causant des interférences inter-symboles et dégradant les performances du système.

Le principe : L’UE avance temporellement sa transmission uplink d’une valeur TA pour compenser le délai de propagation, de sorte que : T_arrivée_gNB = T_transmission_UE + T_propagation – TA ≈ T_référence

Calcul du TA dans les Réseaux Terrestres

Dans les réseaux terrestres (TS 38.213 pour la 5G), le TA est calculé par le gNB en mesurant la différence de temps entre la réception du signal Uplink et le début de la sous-trame dédiée à la réception de ce message. Le gNB envoie ensuite des commandes de TA à l’UE via :

  • Timing Advance Command (TAC) dans le Random Access Response (RAR) afin de calculer la valeur du TA initial. On parle de boucle ouverte et le gNB mesure la différence de temps entre la réception du préambule d’accès RACH et la sous-trame dédiées à la réception des RACH
  • TA adjustments via des commandes MAC CE (Control Element) permettant de compenser en boucle fermée la variation du TA lorsque l’UE se déplace. On compense ainsi le delta supplémentaire lorsque l’UE se déplace par rapport à la valeur du TA précédent.

Ajustement en boucle ouverte

La valeur de TA est quantifiée en unités de Tc (temps d’échantillonnage de base) :

TA = NTA × Tc.

On retrouve parfois en 4G-LTE le calcul suivant 1 TA = 16 Ts avec Ts = 1/(15000 × 2048) ≈ 32,55 ns (durée d’échantillonnage de base).

En NR (5G) :

  • TA dépend de la numérologie (SCS – Subcarrier Spacing)
  • Pour SCS = 15 kHz : 1 TA unit = 16 × 64 Tc ≈ 0,51 μs
  • Pour SCS = 30 kHz : 1 TA unit = 16 × 64 Tc / 2
  • Tc = 1/(480000 × 4096) (période d’échantillonnage de base)

Avec Tc ≈ 0.509 ns on peut calculer l’erreur de distance : 0,51 μs / 2× c ≈ 78 m

En boucle ouverte, le gNB transmet la valeur TA absolue

  • NR : MAC CE « Absolute Timing Advance Command » Absolute : 12 bits (valeur complète) Le calcul est le suivant : TA = TA_command × N_TA
  • TA_command : valeur reçue (0 à 4095 pour 12 bits)
  • N_TA : granularité qui dépend de la numerology (SCS)

Granularité N_TA selon le SCS :

  • μ = 0 (SCS 15 kHz) : N_TA = 16 × 64 Tc
  • μ = 1 (SCS 30 kHz) : N_TA = 16 × 64 Tc / 2¹ = 16 × 32 Tc
  • μ = 2 (SCS 60 kHz) : N_TA = 16 × 64 Tc / 2² = 16 × 16 Tc
  • μ = 3 (SCS 120 kHz) : N_TA = 16 × 64 Tc / 2³ = 16 × 8 Tc

Le TA est codé sur :

  • 11 bits en LTE : valeurs de 0 à 2047
  • 12 bits en NR : valeurs de 0 à 3846 (valeurs utilisables max actuellement)

Distance maximale :

  • LTE : 2047 × 78 m ≈ 160 km
  • NR (15 kHz) : environ 200 km

Ajustement en boucle fermée

Une fois la connexion établie, le réseau effectue des ajustements fins du TA. Commandes TA :

  • LTE : MAC CE (Control Element) « Timing Advance Command »
    • 6 bits : valeurs de 0 à 63
    • Représente un ajustement relatif : TA_new = TA_old + (TA_command – 31) × 16 Ts
    • Plage : ±31 unités TA (±1,6 km environ)
  • NR : MAC CE  » « Relative Timing Advance Command »
    • Relative : 6 bits (ajustement incrémental)

Pour le TA relatif

TA_new = TA_old + (TA_adjustment – 31) × N_TA

Timer TA :

  • timeAlignmentTimer : si l’UE ne reçoit pas de commande TA pendant cette durée, elle considère que le TA n’est plus valide
  • Valeurs typiques : 500 ms à 10 s
  • Expiration → l’UE doit refaire un RACH

TA Offset dans le réseau terrestre

Le TA offset est un désalignement intentionnel entre les trames downlink et uplink qui est transmis par le paramètre 5G NR n-TimingAdvanceOffset diffusé par un message RRC SIB.

Valeurs possibles : •

  • n0 : TA_offset = 0 (comportement par défaut)
  • n25600 : TA_offset = 25600 Tc ≈ 13 μs
  • n39936 : TA_offset = 39936 Tc ≈ 20 μs

Le TA_offset vaut 0 dans le cas FDD (les trames UL et DL sont synchronisées en temps sur des bandes de fréquences différentes.

Dans le cas TDD il faut prendre en compte le délai du temps de garde (Special). Exemple de pattern TDD (D = Downlink, U = Uplink, S = Symbole flexible)

  1. Slot n : DDDDDDDDDDDDD (tout DL)
  2. Slot n+1 : DDDSUUUUUUUUU (DL + spécial + UL)
  3. Slot n+2 : UUUUUUUUUUUUU (tout UL)

Le Ta_offset permet de prendre en compte ce délai. Ainsi en 5G pour les réseaux terrestres, TA=(N_TA+N_TAoffset).Tc

Ainsi en 5G pour les réseaux terrestres, TA=(N_TA+N_TAoffset).Tc

TA Pré-Compensé en NTN : Une Approche différente

Alors que pour le réseau terrestre la valeur du TA est calculée par la station de base, l’évolution majeure pour les terminaux 5G NTN est la capacité à pré-calculer le TA.

Pré-calcul du TA

En NTN, les délais de propagation sont beaucoup trop importants. Le 3GPP a introduit un concept dans le TS 38.821 : le TA pré-compensé (pre-compensated TA).

Dans le cas du réseau non terrestre, l’UE communique vers un satellite et le satellite transmet le trafic vers une passerelle satellitaire terrestre. On parle de lien de service le lien entre l’UE et le satellite et de lien de feeder, le lien entre le satellite et la passerelle satellitaire terrestre.

Figure 1 : Liaison NTN

Le standard 3GPP propose actuellement 2 architectures 5G NTN :

  • Architecture Transparente
  • Architecture Regénérative

Dans l’architecture transparente, la station de base est au sol, c’est-à-dire après la passerelle terrestre. Le temps de propagation radio aller/retour prend en compte le temps de propagation sur le lien de service et sur le lien du feeder.

Dans l’architecture régénérative, la station de base est située dans le satellite. Le temps de propagation radio prend en compte le temps de propagation sur le lien de service uniquement.

Principe du Pré-calcul

L’idée clé est que l’UE calcule lui-même la valeur du TA en utilisant :

  1. Les éphémérides du satellite : Position et vitesse du satellite, diffusées dans les System Information Blocks (SIB19 selon TS 38.331)
  2. Sa propre position GNSS : Latitude, longitude, altitude obtenues via GPS/Galileo/etc.
  3. Le temps de référence commun : Fourni par le satellite

Le calcul du TA pré-compensé suit la formule (TS 38.821, Section 6.3.1.1) :

TA_precomp = (d_UE→SAT + d_SAT→GW) / c

où :

  • d_UE→SAT = distance UE vers satellite (calculée géométriquement)
  • d_SAT→GW = distance satellite vers gateway (fournie dans SIB19)
  • c = vitesse de la lumière

Calcul Géométrique de la Distance UE-Satellite

La distance UE-satellite se calcule en coordonnées ECEF (Earth-Centered, Earth-Fixed) :

d_UE→SAT = √[(X_sat – X_UE)² + (Y_sat – Y_UE)² + (Z_sat – Z_UE)²]

Les coordonnées du satellite (X_sat, Y_sat, Z_sat) sont dérivées des éphémérides, tandis que les coordonnées de l’UE (X_UE, Y_UE, Z_UE) sont converties depuis ses coordonnées GNSS (latitude, longitude, altitude).

Mais, un satellite LEO se déplace environ à 28000 km/h (7,8 km/s). Le délai de propagation varie donc entre le sens montant et le sens descendant.

Figure 2 : La distance entre le satellite et l’UE en fonction de la position du satellite (Rohde et Schwarz)

Figure 3 : Le temps RTT sur le lien de service (Rohde et Schwarz)

Lorsque l’UE envoi une demande d’accès aléatoire à l’instant t0, la 3GPP propose de calculer le RTT à partir :

  • du délai t1 entre l’UE et le satellite (lien de service). Le satellite reçoit la demande d’accès à l’instant t1 et le transmet à la passerelle. Il est nécessaire de connaitre la position du satellite à l’instant t1.
  • du temps RTT_feeder nommé t2 entre le satellite et la passerelle terrestre.
  • du délai satellite-UE (lien de service) à l’instant t2. Il est donc nécessaire de connaitre la position du satellite à l’instant t2.

Pour calculer la position du satellite à l’instant t1 et t2, l’UE connait :

  • le temps de référence tepoch. Celui-ci correspond par exemple à l’instant de le sous-trame n°5
  • des informations éphémérides du satellite
    • Sa position à l’instant tepoch
    • Son vecteur vitesse à l’instant tepoch
    • Son vecteur accélération à l’instant tepoch

Toutefois, en connaissant la position de l’UE et du satellite (à l’instant t0, t1 et t2), il est possible de localiser la position de la passerelle satellitaire terrestre à partir du RTT_feeder. Afin de masquer cette information, la 3GPP propose une subtilité qui consiste à définir un point de référence sur le lien feeder nommé RP ou UTSRP (uplink time synchronization) comme point de référence.

Ainsi, la station de base diffuse dans le SIB19 les paramètres Common TA. Cette information (éphéméride et temps de référence tepoch) permet de calculer le RTT du lien feeder et s’applique donc à tous les UE :

  • Le délai NTA,common entre le point de référence et le satellite à l’instant tepoch
  • La vitesse NTA,commondrift entre le point de référence et le satellite à l’instant tepoch
  • L’accélération NTA,commondriftvariation entre le point de référence et le satellite à l’instant tepoch

Dans le cas ou l’architecture choisie par l’opérateur est l’architecture regénérative, alors les paramètres Common TA (NTA,common, NTA,commondrift, NTA,commondriftvariation) sont toutes égales à 0.

Ainsi le pré-calcul du TA effectué par l’UE est le suivant :

  • NTA,adjUE: avance temporelle estimée par l’UE lui-même pour pré-compenser le délai de la liaison de service. Elle est calculée à partir de :
    • La position de l’UE estimée via positionnement GNSS
    • La position estimée du satellite basée sur les informations d’éphémérides que l’UE possède
  • NTA,adjcommon est l’avance temporelle commune contrôlée par le réseau sur le lien feeder. Elle est dérivée des paramètres reçus par l’UE en provenance de la couche supérieure RRC SIB 19 et se calcule à partir du délai feeder à l’instant t1 et à l’instant t2 :
    • TACommon : estimation initiale du délai de propagation entre le satellite et la passerelle terrestre ou du point de référence
    • TACommonDrift : représente la vitesse de dérive de l’avance temporelle commune
    • TACommonDriftVariation (si configurés). Si non configurés, sa valeur par défaut est 0. Ce paramètre représente la variation (ou accélération) de la dérive du timing. Il modélise le fait que la vitesse de changement de distance n’est pas constante en raison de l’orbite non circulaire du satellite et d’autres facteurs.

Le délai vaut :

Tepoch est la référence temporelle qui correspond à l’instant où le récepteur UE doit recevoir une sous-trame définie. Cela permet d’avoir une référence de temps commune entre le réseau et l’UE.

Figure 4 : Le calcul du délai sur le feeder en fonction de la position du satellite à l’instant t

 

3.2 Timing Advance Résiduel

Même avec le TA pré-compensé, il subsiste une erreur due à :

  • Imprécisions de position GNSS de l’UE (quelques mètres)
  • Latence dans les éphémérides (propagation des SIB)
  • Délai de feeder link variable

Le réseau envoie donc encore des commandes TA résiduelles via MAC CE pour affiner l’alignement temporel. Ces corrections sont beaucoup plus petites qu’en réseau terrestre. Mais, de par la vitesse du satellite LEO, la variation de délai est de 40 µs toutes les 1 ms ce qui nécessite de mettre à jour régulièrement le TA lorsque l’UE est en mode connecté. La charge en signalisation est trop importante pour conserver ce mode de fonctionnement. Le pré-calcul du TA permet à l’UE de compenser automatiquement la variation du délai sur le lien de service et le lien de feeder.

Ainsi, si la station de base gNB mesure une différence de temps entre la réception de la sous-trame UL par rapport à la sous-trame de réception, cette différente étant négligeable, peut être  compensée par le gNB.

Ainsi, le TA global se calcule de la manière suivante :

Avec NTa,offset défini par le paramètre nr-TimingAdvanceOffset : Un offset supplémentaire appliqué au TA pour tenir compte de la configuration spécifique NTN (TS 38.213 Section 4.2).

 

 

 

 

Comprendre la 5G – NTN Part 1

Posté le by - 211 vues
Répondre

Cet article a été écrit avec la collaboration de Mohamed El Jaafari, expert Réseau radio 3GPP et satellitaire chez Thales AleniaSpace, et en attente de relecture.

Je remercie également Dorin Panaitopol, expert 3GPP chez Thales.

Mohamed El Jaafari est un des auteurs du livre 5G Non-Terrestrial Networks: Technologies, Standards, and System Design

Introduction

L’intégration des réseaux non-terrestres (NTN – Non-Terrestrial Networks) dans l’écosystème 5G New Radio (NR) constitue l’une des évolutions majeures des télécommunications modernes.

Initialement conçue pour des réseaux cellulaires terrestres, la 5G doit désormais s’adapter à des infrastructures hybrides capables d’assurer une connectivité via des satellites en orbite basse (LEO), moyenne (MEO) ou géostationnaire (GEO). Cette convergence entre réseaux terrestres et spatiaux est aujourd’hui considérée comme un élément structurant des futures architectures 6G.

Cependant, l’extension de la 5G NR vers les réseaux NTN ne consiste pas simplement à remplacer une station de base terrestre par un satellite. Les caractéristiques physiques des liaisons satellite-terre introduisent des contraintes radicalement différentes, notamment en matière de propagation radio et de synchronisation temporelle. Alors qu’un réseau terrestre traditionnel fonctionne avec des distances de quelques kilomètres entre l’UE et la station de base, les réseaux NTN doivent gérer des distances pouvant dépasser 36 000 km dans le cas des satellites GEO, entraînant des délais de propagation plusieurs ordres de grandeur supérieurs à ceux des réseaux cellulaires conventionnels.

Ces délais ont un impact direct sur les mécanismes fondamentaux de la couche radio 5G NR. Les procédures de synchronisation temporelle, conçues à l’origine pour des environnements terrestres à faible latence, doivent être adaptées afin de maintenir l’orthogonalité des transmissions et garantir le bon fonctionnement de l’interface radio. Le 3GPP a ainsi introduit plusieurs évolutions spécifiques au NTN concernant notamment le Timing Advance (TA), l’estimation du Round-Trip Time (RTT) ainsi que les mécanismes d’ordonnancement temporel reposant sur les paramètres Koffset et Kmac.

Il faut séparer deux ajustements temporels complémentaires : •

  • Ajustement précis par le calcul du TA afin de se synchroniser au niveau de la station de base afin d’éviter les interférences inter-symboles
  • Ajustement grossier pour l’ordonnancement afin de laisser plus de temps au récepteur d’envoyer sa réponse. Cet ajustement a un impact sur la latence (Koffset et Kmac).

L’un des aspects les plus novateurs de cette évolution réside dans la capacité de l’UE à pré-calculer certaines corrections temporelles à partir de sa position géographique et des éphémérides satellites. Cette approche marque une rupture importante avec le fonctionnement des terminaux 5G terrestres traditionnels et soulève de nouveaux enjeux autour de la dépendance aux systèmes GNSS, de la complexité terminale et de l’expérience utilisateur.

À plus long terme, les travaux du 3GPP s’orientent vers des approches GNSS-free afin de supprimer la nécessité de pré-calculs basés sur la position de l’UE. Cette évolution est essentielle pour limiter la complexité des terminaux NTN et éviter qu’une dépendance aux capacités GNSS ne devienne un obstacle à la démocratisation du service satellite sur smartphone. On peut citer comme exemple l’échec de l’offre Unik qui imposait au client un changement de téléphone. L’offre Unik d’Orange était une offre de convergence fixe-mobile lancée vers 2006, basée sur la technologie UMA (Unlicensed Mobile Access), plus tard renommée GAN (Generic Access Network).

Dans cet article, nous allons analyser les principaux mécanismes temporels introduits pour la 5G NTN et comprendre comment le 3GPP adapte l’architecture NR afin de faire fonctionner efficacement des communications radio sur des liaisons satellitaires à très longue distance.

L’alignement de la trame

Le délai : UE – gNB terrestre

Dans un réseau terrestre classique (TN – Terrestrial Network), le délai  d’un signal entre un équipement utilisateur (UE) et une station de base (gNB) est typiquement de l’ordre de quelques microsecondes à quelques dizaines de microsecondes. L’allocation de ressource en 4G est basée sur la sous-trame d’une durée de 1 ms. L’allocation de ressource en 5G est basée sur le slot.

Si d est la distance entre l’UE et la station de base, le délai UE – gNB – UE est égal à 2*d/c, avec c la vitesse de la lumière (300 m en 1 µs).

Ainsi, pour une station de base située à 1,2 km, le temps de propagation radio RTT (Radio Round Trip Time ou two way radio latency) est de 8 µs.

On appelle :

  • RTT radio : Aller-retour UE ↔ gNB sur l’interface radio
  • End-to-end RTT : Aller-retour complet jusqu’au serveur/applicatif
  • HARQ RTT : Temps d’un cycle HARQ ACK/NACK
  • Ping RTT : RTT IP mesuré par ICMP

Le délai UE – Satellite – gNB

La situation change radicalement en NTN. Selon le 3GPP TS 38.821, les scénarios NTN considèrent :

Satellites LEO (Low Earth Orbit) :

  • Altitude : 400 kms à 1100 kms (600 km cas nominal)
  • Distance maximale UE-satellite : ~1 200 km (élévation minimale pour un satellite à 600 kms et un angle de 30°)
  • Delai UE – satellite – UE :  ~8 ms pour une distance de 1200 kms

Satellites GEO (Geostationary Earth Orbit) :

  • Altitude : 35 786 km
  • Distance maximale UE-satellite : ~41 000 km
  • Delai UE – satellite – UE maximal : ~270 ms

Ces valeurs de RTT sont supérieures à la durée d’un slot 5G NR (TS 38.211), ce qui pose des problèmes fondamentaux pour les mécanismes de synchronisation (alignement de trame) conçus initialement pour les réseaux terrestres.

Impact sur la Synchronisation Temporelle et l’effet Doppler

La durée élevée du délai UE – Satellite – UE et la vitesse élevée du satellite ont plusieurs conséquences critiques :

  1. Variation temporelle du délai : Pour les satellites LEO en mouvement, le délai change continuellement en raison du déplacement relatif du satellite par rapport à l’UE. Le délai de propagation devient asymétrique : Le signal montant (uplink) et le signal descendant (downlink) varie en fonction de la position du satellite pour les LEO non-géostationnaires.
  2. La fréquence Doppler : le satellite LEO se déplace à 28 000 km/h ce qui provoque un décalage élevé de la fréquence de réception.
  3. Budget temporel HARQ : Les mécanismes de retransmission automatique (HARQ) doivent être adaptés pour accommoder ces délais importants.

Le prochain article (Part2) mettra en avant les mécanismes pour pré-compenser le Timing Advance.

DM-RS du PBCH : Le signal de référence du bloc SSB

Posté le by - 157 vues
Répondre

Pourquoi un DM-RS dédié au PBCH en 5G NR ?

En LTE, le décodage du PBCH s’appuie sur le signal de référence CRS (Cell-specific Reference Signal). Le CRS nommé Cell Reference Signal est un signal de référence permanent diffusé sur l’ensemble de la bande à chaque sous-trame. Le CRS permet à l’UE d’estimer le canal avant même de savoir où se trouve le PBCH. Le CRS est utilisé en 4G-LTE, initialement pour du SISO mais le signal est transmis sur chaque antenne, jusqu’à 4 antennes. Au delà de 4 antennes, le signal de référence CSI-RS remplace le CRS. Ainsi pour 8 antennes, le signal de références CRS est émis sur les antennes 1 à 4 et CSI-RS est émis sur les antennes 5 à 8.

Les signaux CRS et CSI-RS sont utilisés pour remonter l’état du canal ressenti par l’UE en mode connecté. Cette connaissance est nécessaire à l’ordonnanceur situé sur la couche MAC (Medium Access Control) du gNB à choisir le format MCS (Modulation and Coding Scheme) adapté.

En mode de veillle, le mobile doit récuperer le canal de diffussion PBCH. Ce signal occupe les symboles OFDM 0–3 du premier slot de la sous-trame 0. Pour démoduler ce canal, l’UE effectue une égalisation du canal. La démodulation s’appuie sur les Cell-specific RS présents dans cette zone. Techniquement les CRS des antennes port 0 (et éventuellement 1, 2, 3 selon le rang) sont utilisés par l’UE pour l’estimation du canal, mais l’UE se limite aux positions qui tombent dans les 6 PRB centraux.

Dans un souci d’efficacité spectrale, la 5G-NR supprime le CRS : il n’existe plus de signal de référence qui couvre en permanence l’ensemble de la bande. Chaque canal physique embarque donc ses propres signaux de référence, étroitement localisés à ses ressources temps-fréquence.

En 5G, comme en 4G, le PBCH transporte le MIB (Master Information Block), premier message de configuration qu’un UE doit décoder lors de la procédure de synchronisation cellulaire. Il est contenu dans le SS/PBCH Block (SSB), une structure compacte de 4 symboles OFDM × 240 sous-porteuses. Puisque ce bloc transporte des informations essentielles pour l’UE, la transmission de ce bloc doit être auto-suffisant : les DM-RS PBCH en font partie intégrante.

Référence : TS 38.211 §7.4.1.4 (séquence et cartographie RE) — TS 38.211 §7.4.3 (structure du SSB) — TS 38.213 §4 (procédure UE)

Structure du SS/PBCH Block : vue d’ensemble

Le SSB occupe 4 symboles OFDM consécutifs (numérotés 0 à 3) et 240 sous-porteuses réparties sur 20 PRBs (12 sous-porteuses par PRB). Les 4 symboles se répartissent comme suit :

  • Symbole S0 — PSS sur les sous-porteuses 56 à 182 (127 SCs) + zéros sur les bords. Aucun DM-RS.
  • Symbole S1 — PBCH sur les 240 sous-porteuses. DM-RS répartis sur l’ensemble des 240 SCs à une densité de 1 RE sur 4.
  • Symbole S2 — SSS sur les sous-porteuses 56 à 182 (127 SCs) + PBCH sur les bords (SCs 0–55 et 192–239). DM-RS uniquement dans les zones PBCH, aucun DM-RS dans la zone SSS.
  • Symbole S3 — PBCH sur les 240 sous-porteuses. DM-RS répartis sur l’ensemble des 240 SCs à une densité de 1 RE sur 4.

La figure ci-dessous représente la grille réelle du SSB avec les 240 sous-porteuses individuelles pour chacun des 4 symboles. Chaque colonne correspond à une sous-porteuse ; les repères verticaux délimitent les PRBs (12 SCs). La figure est donnée pour v = 0 (PCI mod 4 = 0).

Fig. 1a : Grille SSB pour v=0, DM-RS sur SCs 0, 4, 8, …, 236]

Fig. 1b : Grille SSB pour v=1, DM-RS sur SCs 1, 5, 9, …, 237]

Fig. 1c : Grille SSB pour v=2, DM-RS sur SCs 2, 6, 10, …, 238]

Fig. 1d : Grille SSB pour v=3, DM-RS sur SCs 3, 7, 11, …, 239]

Cartographie précise des RE : densité et décalage fréquentiel

Règle de base : densité 1/4 avec décalage v

Sur les symboles portant du PBCH (S1, S2 partiel, S3), les DM-RS sont placés à raison d’un RE tous les 4 sous-porteuses. Le premier RE est décalé d’un offset fréquentiel v dépendant du Physical Cell ID :

v = N_IDcell mod 4, avec v ∈ {0, 1, 2, 3}

Les indices des RE DM-RS sont donc : k = v, v+4, v+8, v+12, …, v+236, soit 60 RE de DM-RS par symbole PBCH plein.

Ce mécanisme sert deux objectifs : répartir uniformément les DM-RS entre cellules voisines pour limiter les interférences inter-cellules, et encoder partiellement le PCI dans la position fréquentielle même des pilotes.

Symboles S1 et S3 : PBCH plein

Les 240 sous-porteuses sont entièrement dédiées au PBCH. Les 60 RE de DM-RS se positionnent aux indices k = v, v+4, …, v+236. Les 180 RE restants transportent les données PBCH encodées.

Symbole S2 : SSS au centre, PBCH sur les bords

Les 127 sous-porteuses centrales (indices 56 à 182) sont occupées par le SSS. Les zones PBCH se trouvent sur les sous-porteuses 0 à 55 et 192 à 239. Les DM-RS suivent le même motif k = v + 4m mais uniquement dans ces zones PBCH. La zone SSS ne contient aucun DM-RS.

Référence 3GPP TS 38.211 §7.4.1.4.2 : la cartographie est définie par k = 4·m + v pour m = 0, 1, …, 59 sur les symboles PBCH complets (S1, S3). Pour S2, les indices k ∈ [56, 182] sont exclus.

Récapitulatif de la cartographie

  • S0 — 0 RE DM-RS. PSS + zéros uniquement.
  • S1 — 60 RE DM-RS. Sous-porteuses 0 à 239, pas de 4, décalage v. PBCH plein.
  • S2 — environ 24 RE DM-RS. Sous-porteuses 0–55 et 192–239 uniquement, pas de 4, décalage v. Zone SSS (56–182) exclue.
  • S3 — 60 RE DM-RS. Sous-porteuses 0 à 239, pas de 4, décalage v. PBCH plein.

Visualisation du décalage selon v

La figure ci-dessous montre les 24 premières sous-porteuses (2 PRBs) d’un symbole PBCH plein pour les 4 valeurs de v. Chaque cellule correspond à exactement une sous-porteuse. Le numéro inscrit dans les cellules bordeaux indique l’indice de SC portant un DM-RS.

Fig. 2 : Décalage DM-RS selon v = PCI mod 4, zoom sur SCs 0 à 23 (2 PRBs). Cellules rouge = DM-RS PBCH. Cellules orange= données PBCH. Le motif se répète identiquement sur les 240 SCs du SSB. Cellules bleue : SSS/PSS.

Génération de la séquence DM-RS

La séquence des symboles DM-RS est générée par un générateur Gold de longueur 31, initialisé par une valeur c_init incorporant plusieurs informations cellulaires (TS 38.211 §7.4.1.4.2).

L’index SSB : identifiant du faisceau reçu

La valeur centrale encodée dans c_init est i_SSB, l’index du SS/PBCH Block au sein de la demi-trame radio. Ce paramètre est fondamental : chaque SSB candidat porte une séquence DM-RS distincte, ce qui permet à l’UE d’identifier non seulement la cellule, mais aussi quel faisceau il reçoit.

En 5G NR, la gNB peut émettre jusqu’à L_max SSB candidats par demi-trame de 5 ms, chacun pouvant correspondre à une direction de faisceau différente (beam sweeping). L_max dépend de la bande de fréquence :

  • FR1 sub-3 GHz (< 3 GHz) — L_max = 4 : 2 bits LSB de l’index SSB encodés dans les DM-RS (ī_SSB mod 4). Le numéro de demi-trame n_hf vaut 0 ou 1 selon la demi-trame considérée.
  • FR1 mid-band (3–7,125 GHz) — L_max = 8 : 3 bits LSB de l’index SSB encodés dans les DM-RS (ī_SSB mod 8). n_hf est toujours 0.
  • FR2-1 mmWave (24,25–52,6 GHz) — L_max = 64 : seulement 3 bits LSB de l’index SSB dans les DM-RS. Les 3 bits de poids fort sont transportés dans le PBCH. n_hf est toujours 0.
  • FR2-2 mmWave (52,6–71 GHz) — L_max = 64 : même fonctionnement que FR2-1.

Note sur FR2 : avec L_max = 64, il faut 6 bits pour indexer tous les faisceaux. Les DM-RS n’encodent que les 3 bits de poids faible (ī_SSB mod 8). L’UE effectue une corrélation sur un ensemble fini et connu de 8 DM-RS possible (8 séquences de Gold possible). Les 3 bits de poids fort (bits 3–5) sont transportés dans le contenu du PBCH après décodage canal. L’UE combine les deux sources pour reconstituer l’index SSB complet sur 6 bits.

Construction de i_SSB selon L_max

Cas L_max = 4 (FR1 sub-3 GHz) :
ī_SSB = 2 bits LSB de l’index SSB physique, soit ī_SSB ∈ {0, 1, 2, 3}
i_SSB = ī_SSB + 4·n_hf, avec n_hf = 0 ou 1 selon la demi-trame
→ i_SSB ∈ {0, 1, 2, 3, 4, 5, 6, 7} sur les deux demi-trames

Cas L_max = 8 (FR1 mid-band) :
ī_SSB = 3 bits LSB, soit ī_SSB ∈ {0, …, 7}, n_hf = 0
i_SSB = ī_SSB

Cas L_max = 64 (FR2-1 et FR2-2) :
ī_SSB = 3 bits LSB, soit ī_SSB ∈ {0, …, 7}, n_hf = 0
i_SSB = ī_SSB dans les DM-RS ; bits 3–5 transportés dans le PBCH

Pour L_max = 4, la demi-trame est encodée implicitement : deux SSBs avec le même ī_SSB mais émis dans des demi-trames différentes ont des i_SSB différents (écart de 4) et donc des séquences DM-RS différentes. C’est ce qui permet à l’UE de distinguer les deux demi-trames de la trame radio de 10 ms et de reconstituer le SFN complet.

Formule d’initialisation c_init

Une fois i_SSB déterminé, la valeur d’initialisation du générateur Gold est :

c_init = 2¹¹ · (i_SSB + 1) · (⌊N_IDcell / 4⌋ + 1) + 2⁶ · (i_SSB + 1) + (N_IDcell mod 4)

Source : TS 38.211 §7.4.1.4.2, équation (7.4.1.4.2-1)

Cette formule intègre simultanément :

  • Le Physical Cell ID (N_IDcell ∈ [0, 1007]) via son quotient par 4 et son reste (= v)
  • L’index du SSB / faisceau (i_SSB) — chaque faisceau produit une séquence DM-RS unique à la fois en fréquence (via v) et en valeur des symboles QPSK (via c_init)
  • Implicitement le numéro de demi-trame (n_hf) pour L_max = 4

Génération des symboles complexes r(m)

Une fois c_init déterminé, deux séquences binaires x₁(n) et x₂(n) sont générées par récurrences polynomiales (registres à décalage sur GF(2)), puis combinées en une séquence de scrambling c(n). Les symboles complexes DM-RS sont :

r(m) = (1/√2) · (1 − 2·c(2m)) + j · (1/√2) · (1 − 2·c(2m+1))

Il s’agit d’une constellation QPSK à puissance unitaire normalisée. Chaque DM-RS est un symbole QPSK dont la phase est pseudo-aléatoire mais parfaitement reproductible par l’UE dès que celui-ci connaît N_IDcell, i_SSB et n_hf. L’UE compare les symboles reçus aux symboles attendus pour estimer la réponse en fréquence du canal sur les 60 RE pilotes, puis interpole pour démoduler les 180 RE PBCH.

Rôle dans la procédure de synchronisation cellulaire

La procédure de cell search d’un UE 5G NR suit la séquence suivante :

  1. Détection du PSS (symbole S0) : synchronisation à 5 ms et identification du groupe PCI (N_ID² ∈ {0, 1, 2}).
  2. Détection du SSS (symbole S2) : identification complète du PCI selon N_IDcell = 3·N_ID¹ + N_ID².
  3. Estimation de canal via les DM-RS PBCH (symboles S1, S2 partiel, S3) : v = PCI mod 4 est désormais connu, permettant de localiser précisément les 60 pilotes. Corrélation sur les i_SSB candidats pour identifier le faisceau reçu.
  4. Décodage du PBCH : extraction du MIB, SFN, timing, bande passante initiale. En FR2, récupération des 3 bits de poids fort de l’index SSB.

En corrélant le signal reçu avec les séquences candidates, l’UE extrait sans décodage canal : l’index du SSB / faisceau reçu (2 ou 3 bits LSB selon L_max) ; le numéro de demi-trame n_hf pour L_max = 4 permettant de reconstituer le SFN complet ; une indication partielle du PCI via la position fréquentielle des DM-RS (v = PCI mod 4). En FR2 (L_max = 64), les 3 bits de poids fort de l’index SSB sont obtenus après décodage du PBCH.

Conclusion

Le DM-RS PBCH est un élément discret mais fondamental du SS/PBCH Block en 5G NR. Son existence découle directement de la suppression du CRS de LTE. Sa cartographie — 60 RE par symbole PBCH plein, espacés de 4 sous-porteuses et décalés par v = PCI mod 4 — lui confère une double fonction dans le domaine fréquentiel. Dans le domaine temporel, la séquence elle-même varie selon i_SSB : chaque faisceau du SSB burst porte une signature DM-RS distincte, permettant à l’UE d’identifier précisément lequel des L_max faisceaux candidats il reçoit. En FR1 sub-3 GHz (L_max = 4), cette identification inclut aussi le numéro de demi-trame. En FR2 (L_max = 64), seuls 3 bits sur 6 sont dans les DM-RS, les 3 restants étant dans le PBCH. L’UE exploite ainsi la position des RE et la valeur des symboles pour s’ancrer temporellement, spatialement (faisceau) et cellulairement dans le réseau, avant d’avoir décodé un seul bit de données.

Références

  • 3GPP TS 38.211 — NR; Physical channels and modulation, §7.4.1.4 et §7.4.3
  • 3GPP TS 38.213 — NR; Physical layer procedures for control, §4
  • 3GPP TS 38.212 — NR; Multiplexing and channel coding
  • ShareTechnote — 5G PBCH DMRS