Pourquoi le SMF interroge‑t‑il à nouveau l’UDM lors de la création d’une session PDU en 5G

Posté le 11 avril 2026 by flaunay - 190 vues

Pourquoi le SMF interroge‑t‑il à nouveau l’UDM lors de la création d’une session PDU en 5G ?

🔍 Problématique :
Dans une procédure 5G Stand‑Alone, l’AMF contacte l’UDM pendant l’enregistrement de l’UE. Puis, lors de la création d’une session PDU, le SMF contacte à nouveau l’UDM avec le même service Nudm_SDM_Get. Pourquoi l’AMF ne transmet‑il pas directement les informations au SMF ?

Cet article détaille d’abord les deux procédures (enregistrement puis session PDU), puis répond à cette question fondamentale d’architecture 5G.

1. Rappel : les acteurs 5G (NF) et leurs rôles

UE : terminal mobile
gNB : station de base 5G
AMF : Access & Mobility Management Function – gestion de l’enregistrement et de la mobilité
UDM : Unified Data Management – base de données d’abonnement (profil utilisateur)
AUSF : Authentication Server Function – gestion de l’authentification
SMF : Session Management Function – création et contrôle des sessions PDU
UPF : User Plane Function – plan utilisateur (routage IP/GTP)
PCF : Policy Control Function – règles de QoS et de facturation
NRF : NF Repository Function – annuaire dynamique des NF
NSSF : Network Slice Selection Function – sélection des tranches réseau (slices)

2. Première procédure : l’enregistrement de l’UE (5G attachment)

L’UE doit d’abord se rendre visible auprès du réseau 5G. Cette procédure est décrite dans la 3GPP TS 23.502 §4.2.2.2.

Étapes simplifiées (celles qui nous intéressent) :

UE → gNB → AMF : Registration Request (avec SUCI, Requested NSSAI)
AMF → NRF : découverte d’une AUSF
AMF → AUSF → UDM : authentification 5G‑AKA (échange de clés)
AMF → UE : Security Mode Command (protection NAS activée)
AMF → UDM : Nudm_SDM_Get (type Access and Mobility Subscription Data)

Que récupère l’AMF ?

AM Policy (règles de mobilité)
S‑NSSAI autorisées (tranches réseau)
GPSI (MSISDN ou email)
Restrictions de zone / RAT
UE‑AMBR (débit maximal)

L’AMF ne voit absolument pas les données de session (DNN, QoS, IP statique…).

3. Deuxième procédure : création d’une session PDU

Une fois l’UE enregistré, il peut demander une connexion à un réseau de données (ex. internet). Procédure TS 23.502 §4.3.2.

Étapes simplifiées :

UE → AMF : PDU Session Establishment Request (DNN, S‑NSSAI, type PDU)
AMF → NRF : sélection d’une SMF supportant ce DNN et cette S‑NSSAI
AMF → SMF : Nsmf_PDUSession_CreateSMContext (transmet SUPI, DNN, localisation…)
🔑 SMF → UDM : Nudm_SDM_Get (type Session Management Subscription Data)
SMF → PCF : récupération des PCC rules
SMF → UPF : établissement du tunnel PFCP (N4)
SMF → AMF → gNB → UE : configuration radio et acceptation de la session

4. Le cœur du problème : deux appels `Nudm_SDM_Get` différents

Le service Nudm_SDM_Get est générique. Il permet à une NF de demander un type spécifique de données d’abonnement.

Qui appelle ?	Quand ?	Type de données demandé	Données retournées (exemples)
AMF	Enregistrement	`Access and Mobility Subscription Data`	S‑NSSAI, GPSI, AM Policy, restrictions mobilité
SMF	Création session PDU	`Session Management Subscription Data`	Configuration DNN, QoS, SSC Mode, adresse IP statique

L’AMF n’a donc jamais reçu les données que le SMF demande. Il ne peut pas les lui transmettre.

5. Pourquoi l’architecture 5G a‑t‑elle été conçue ainsi ?

Trois raisons fondamentales (TS 23.501) :

Séparation des responsabilités (CUPS)
L’AMF gère la mobilité, le SMF gère les sessions. Chacun ne doit voir que ce dont il a besoin (principe du moindre privilège).
Volume de données
Un abonnement peut contenir des dizaines de DNN avec des configurations QoS complexes. Charger l’AMF avec tout cela serait inefficace.
Confidentialité
Certaines données (adresse IP statique, clés de facturation) ne concernent que le SMF et le PCF, pas l’AMF.

6. Ce que l’AMF transmet réellement au SMF

Lors de l’étape Nsmf_PDUSession_CreateSMContext, l’AMF donne au SMF :

SUPI (identifiant de l’abonné)
DNN et S‑NSSAI demandés
PDU Session ID
Localisation de l’UE (TAI, cellule)
RAT Type

Aucune donnée d’abonnement de session n’est transmise. Le SMF va donc les chercher lui‑même auprès de l’UDM.

7. Schéma récapitulatif

[UE] --Registration--> [AMF] --Nudm_SDM_Get(Access&Mobility)--> [UDM]
                            │
                            │ (données mobilité)
                            ▼
                        S‑NSSAI, GPSI, AM Policy

[UE] --PDU Session--> [AMF] --CreateSMContext--> [SMF] --Nudm_SDM_Get(Session)--> [UDM]
                                                                 │
                                                                 ▼
                                                     DNN, QoS, SSC Mode, IP statique

8. Conclusion

Le SMF refait un Nudm_SDM_Get à l’UDM non pas par redondance, mais par nécessité fonctionnelle :

L’AMF ne récupère que les données de mobilité.
Le SMF récupère les données de session PDU.
L’AMF ne peut transmettre au SMF ce qu’il ne possède pas.

Cette séparation est un choix délibéré de la 3GPP pour garantir une architecture modulaire, sécurisée et scalable.

Références : 3GPP TS 23.501, TS 23.502, TS 29.503.
📚 Article basé sur le support de cours “5G Stand‑Alone (SA) – Procédure d’enregistrement & création de session PDU” – Université de Poitiers.

6G et réseaux AI-native : vers une connectivité intelligente et autonome

Posté le 22 mars 2026 by flaunay - 314 vues

Répondre

L’article précédent a permis de donner une définition simple de l’IA native. Nous allons maintenant reprendre l’évolution des réseaux vers la 6G-native.

Introduction

Alors que la 5G continue de se déployer à l’échelle mondiale, la recherche sur la 6G est déjà bien engagée. Cette future génération de réseaux mobiles ne se contentera pas d’améliorer les performances en termes de débit ou de latence : elle introduira une transformation bien plus profonde. Au cœur de cette évolution se trouve un concept clé : celui de réseau “AI-native”, où l’intelligence artificielle devient une composante fondamentale de l’architecture réseau.

Cet article propose d’explorer cette notion et de comprendre en quoi elle redéfinit la manière dont les réseaux sont conçus, exploités et optimisés.

De la 5G à la 6G : un changement de paradigme

Les réseaux actuels, y compris la 5G, intègrent déjà des mécanismes d’intelligence artificielle. On parle alors de réseaux “AI-enabled” (assistés par l’IA). Dans ces systèmes, l’IA est utilisée pour améliorer certaines fonctions spécifiques, comme :

la prédiction des congestions,
l’optimisation des handovers,
ou la gestion du trafic.

Cependant, le fonctionnement global du réseau reste basé sur des règles définies par des ingénieurs. L’IA agit comme un outil d’optimisation, mais elle n’est pas indispensable au fonctionnement du système.

Avec la 6G, cette logique change radicalement.

Le concept de réseau AI-native

Un réseau AI-native est conçu dès l’origine pour intégrer l’intelligence artificielle à tous les niveaux de son fonctionnement. L’IA n’est plus un module ajouté a posteriori : elle est une propriété intrinsèque du réseau.

Concrètement, cela signifie que :

des algorithmes d’apprentissage sont présents à tous les niveaux (du terminal utilisateur jusqu’au cœur de réseau),
les décisions sont prises de manière dynamique et autonome,
les données sont exploitées en continu pour adapter le comportement du réseau.

Dans un tel système, certaines fonctions critiques reposent entièrement sur l’IA, sans solution de secours basée sur des règles fixes.

Une intelligence distribuée et collaborative

Contrairement à une idée reçue, un réseau AI-native ne repose pas sur une intelligence centralisée unique. L’intelligence y est distribuée et hiérarchisée :

au niveau des appareils (edge), pour des décisions ultra-rapides,
au niveau des stations de base ou des clouds en périphérie,
au niveau central (cœur de réseau et data centers), pour des optimisations globales.

Ces différentes instances d’IA collaborent entre elles. Par exemple, des appareils peuvent effectuer des inférences locales à très faible latence, tandis que des systèmes centraux agrègent les données pour entraîner des modèles globaux. Ce type de coopération s’inscrit dans des approches comme l’apprentissage fédéré.

Le rôle essentiel de l’écosystème de gestion de l’IA

Pour fonctionner efficacement, un réseau AI-native nécessite une infrastructure dédiée à la gestion de l’intelligence artificielle. Cela inclut notamment :

des mécanismes d’orchestration pour déployer et mettre à jour les modèles,
des systèmes de collecte et de gestion des données,
des outils de suivi des performances.

Cette couche, parfois appelée “plan de gestion de l’IA”, est essentielle pour garantir la cohérence, la fiabilité et l’évolutivité du réseau. Sans elle, la multiplication des modèles d’IA entraînerait un système difficile à contrôler.

L’apprentissage en boucle fermée : vers l’autonomie

Un des piliers des réseaux AI-native est le fonctionnement en boucle fermée. Le réseau :

observe en continu son environnement (trafic, conditions radio, usages),
analyse ces données grâce à l’IA,
ajuste automatiquement ses paramètres,
et répète ce cycle en permanence.

Ce processus se déroule à différentes échelles de temps :

en millisecondes pour les ajustements radio,
en minutes pour la gestion du trafic,
en heures pour des optimisations globales.

L’objectif est de créer un réseau capable de s’adapter en temps réel, sans intervention humaine constante.

Gouvernance et contrôle humain

Malgré ce haut niveau d’autonomie, les réseaux AI-native ne sont pas totalement indépendants des humains. Les opérateurs jouent toujours un rôle clé en définissant :

des objectifs,
des politiques,
et des contraintes.

On parle ici de “réseaux basés sur l’intention” : les humains spécifient ce qu’ils veulent (par exemple, garantir une certaine latence), et l’IA détermine comment atteindre ces objectifs.

AI-native vs “network for AI”

Il est important de distinguer les réseaux AI-native des réseaux simplement conçus pour supporter des applications d’IA. La 6G offrira effectivement des capacités avancées (haut débit, edge computing) pour des usages comme :

la réalité augmentée,
la robotique connectée,
les systèmes autonomes.

Mais ces capacités relèvent du concept de “network for AI”. Un réseau AI-native, lui, concerne l’intelligence intégrée dans le fonctionnement interne du réseau.

Conclusion

La 6G marque une évolution majeure dans l’histoire des réseaux de télécommunications. En intégrant l’intelligence artificielle comme élément central de leur architecture, les réseaux AI-native promettent un niveau d’autonomie, d’adaptabilité et d’efficacité inédit.

Ces réseaux ne se contenteront plus de transporter des données : ils deviendront des systèmes intelligents capables de percevoir, d’apprendre et d’agir de manière coordonnée. Cette transformation ouvre la voie à une nouvelle génération de services et d’applications, tout en posant des défis importants en matière de gouvernance, de sécurité et de confiance.

La 6G ne sera pas seulement plus rapide. Elle sera, avant tout, plus intelligente.

Si vous avez besoin de comprendre la transition vers la 6G, je propose une formation de 2,5 jours sur l’évolution des réseaux 4G vers la 6G et une formation de 2 jours sur la 6G. Si vous êtes intéressés, contactez moi frederic.launay@univ-poitiers.fr

6G IA native

Posté le 22 mars 2026 by flaunay - 194 vues

Répondre

Définition d’un réseau AI-natif

1 Qu’est-ce que l’AI-natif ?

Un réseau AI-natif est un réseau dans lequel l’intelligence n’est pas une application externe ou un outil d’optimisation, mais une propriété native de l’architecture et des opérations du réseau. En pratique, cela signifie que les algorithmes d’IA et les fonctions d’apprentissage sont intégrés à toutes les couches et domaines du réseau, depuis l’interface radio jusqu’au cœur, depuis les appareils utilisateurs jusqu’aux serveurs cloud. Le réseau est conçu, dès la phase de conception, pour exploiter les données et la prise de décision basée sur l’IA à chaque opportunité.

Lors de la journée France6G, organisée par Hakima Chaouchi le 20 mars 2026, Dorin Panaitopol (Thales) a présenté une architecture 5G-NTN avec une vision 6G et une intégration de l’IA à tous les niveaux, même satellitaire.

Dans un réseau 5G AI-assisté, si l’on retire le modèle d’apprentissage automatique qui optimise les paramètres de handover, le réseau continue de fonctionner. Dans un réseau 6G AI-natif, certaines boucles de contrôle et optimisations n’ont pas d’algorithme de repli déterministe, parce qu’elles sont conçues pour être gérées par des agents IA en apprentissage continu.

2 Caractéristiques clés d’un réseau AI-natif

Intelligence distribuée et hiérarchique : des agents IA au niveau des appareils (edge), des stations de base, des clouds de périphérie et des centres de données centraux, tous coordonnés de manière cohérente.
Apprentissage fédéré : les instances d’IA collaborent et fédèrent leur apprentissage sans centraliser les données brutes, préservant ainsi la confidentialité.
Boucle fermée autonome : le réseau capte en continu les données de télémesure, les alimente dans des algorithmes d’apprentissage, et ajuste de manière autonome les configurations ou politiques réseau.
Écosystème de support IA intégré : orchestration des modèles, cycle de vie (entraînement, déploiement, surveillance, retrait), gestion des données et référentiel de connaissances.
Interfaces basées sur des intentions (Intent-Based) : les opérateurs formulent des objectifs de haut niveau (« assurer une latence vidéo < 20 ms pour cet événement »), et les agents IA déterminent comment les atteindre.

Conclusion

Un réseau AI-natif ne désigne pas simplement un réseau qui offre un bon support pour les applications IA (c’est un concept complémentaire souvent formulé comme « réseaux pour l’IA »). Il ne signifie pas non plus « entièrement autonome dans l’absolu » : les humains conservent la définition des objectifs, politiques et contraintes. En revanche, l’IA détermine les moyens de les satisfaire, sans intervention manuelle sur les contrôles de bas niveau.

Posté le 9 février 2026 by flaunay - 183 vues

Répondre

eRedCap : L’évolution de la 5G pour l’IoT à coût réduit

Introduction

eRedCap (enhanced Reduced Capability) a été introduit dans la Release 18,et vient compléter RedCap pour offrir une connectivité 5G encore plus économique et efficace énergétiquement.

Contexte et motivations

Le continuum des technologies cellulaires IoT

L’écosystème 5G propose désormais un continuum de technologies adaptées aux différents besoins :

NB-IoT et LTE-M : Technologies LPWAN (Low-Power Wide-Area Network) pour les communications à très faible débit
RedCap (Release 17) : Dispositifs à capacités réduites remplaçant les catégories LTE Cat-2/3/4
eRedCap (Release 18) : Dispositifs à capacités encore plus réduites ciblant les catégories LTE Cat-1/1bis

eRedCap

Suite à l’introduction de RedCap dans la Release 17 en 2022, le 3GPP a mené une étude approfondie qui a révélé qu’un débit plafonné à 10 Mbps serait suffisant pour de nombreux cas d’usage IoT. Cette constatation a conduit à la spécification d’eRedCap dans la Release 18, finalisée en juin 2024, avec pour objectif de créer un nouveau type de dispositif encore plus économique tout en préservant les avantages fondamentaux de la 5G.

Caractéristiques techniques d’eRedCap

Simplifications principales

eRedCap introduit plusieurs simplifications par rapport à RedCap et à la 5G NR standard :

1. Limitation du débit de pointe

La caractéristique la plus distinctive d’eRedCap est le plafonnement du débit à 10 Mbps en liaison descendante (downlink) et montante (uplink), indépendamment des autres fonctionnalités optionnelles supportées par le dispositif. Cette approche diffère de RedCap, où le débit dépend des choix de conception (nombre d’antennes, bande passante).

2. Bande passante flexible

Principe de la double bande passante

L’une des innovations les plus significatives introduites par eRedCap dans la 3GPP Release 18 réside dans son architecture de bande passante hybride, qui dissocie intelligemment deux aspects complémentaires du système radio :

2.1 La bande passante RF (RadioFréquence) : 20 MHz

La partie radiofréquence (frontend RF) du dispositif eRedCap maintient une capacité de 20 MHz, identique à RedCap. Cette caractéristique n’est pas anodine : elle permet au dispositif de recevoir et de décoder l’ensemble du spectre de 20 MHz utilisé par la station de base pour transmettre les signaux de contrôle et d’information système.

Concrètement, cela signifie que le dispositif eRedCap peut :

Recevoir les canaux de diffusion (PBCH – Physical Broadcast Channel)
Décoder les signaux de synchronisation (PSS/SSS – Primary/Secondary Synchronization Signals)
Lire les informations système (SIB – System Information Blocks)
Traiter les canaux de contrôle (PDCCH – Physical Downlink Control Channel)

Ces signaux de contrôle et de synchronisation, spécifiés dans les releases précédentes de la 5G NR, occupent des positions fixes dans la bande passante de 20 MHz. En maintenant cette capacité RF complète, eRedCap assure une rétrocompatibilité totale avec l’infrastructure réseau 5G existante.

2.2. La bande passante des canaux de données : 5 MHz (option réduite)

Parallèlement, la Release 18 introduit la possibilité pour un dispositif eRedCap de limiter la bande passante utilisée spécifiquement pour les canaux de données (PDSCH en downlink et PUSCH en uplink) à environ 5 MHz. Cette limitation se traduit par une restriction du nombre de PRB (Physical Resource Blocks) alloués pour la transmission des données utilisateur.

Pour un dispositif eRedCap configuré avec une bande passante de données réduite :

Frontend RF complet (20 MHz) : Le dispositif maintient la capacité de recevoir sur toute la bande de 20 MHz
- Filtre RF : 20 MHz
- Convertisseur analogique-numérique (ADC) : fréquence d’échantillonnage correspondant à 20 MHz
- FFT (Fast Fourier Transform) initiale : taille correspondant à 20 MHz
Traitement des canaux de contrôle : Sur les 20 MHz complets
- Détection et décodage du PDCCH
- Réception des SIB et messages de paging
- Synchronisation et estimation de canal
Traitement des canaux de données : Limité à ~25 PRB (≈ 5 MHz)
- L’allocation de ressources (Resource Allocation) est restreinte
- Le traitement en bande de base (égalisation, démodulation, décodage canal) ne s’applique que sur ces 25 PRB
- La complexité de traitement est proportionnellement réduite

3. Réduction du nombre d’antennes

Comme RedCap, eRedCap peut fonctionner avec :

1 branche de réception (1Rx) : supportant 1 couche MIMO en liaison descendante
2 branches de réception (2Rx) : supportant 2 couches MIMO en liaison descendante
1 antenne d’émission : pas de diversité ou MIMO en liaison montante

Cette réduction du nombre d’antennes (comparé aux 4 antennes minimales de la 5G NR standard) permet de concevoir des dispositifs beaucoup plus compacts.

4. Modulation simplifiée

eRedCap rend obligatoire uniquement la modulation 64QAM (contre 256QAM ou même 1024QAM pour la 5G NR standard). Cette simplification réduit les exigences de traitement et permet au dispositif de fonctionner dans des conditions de canal moins favorables.

5. Optimisations énergétiques avancées

La Release 18 améliore considérablement les mécanismes d’économie d’énergie :

eDRX étendu (extended Discontinuous Reception) : cycles de réception discontinue encore plus longs que dans la Release 17, permettant d’atteindre une autonomie de batterie de plusieurs années pour les capteurs industriels et les objets connectés portables
Cycles eDRX supérieurs à 10,24 secondes : pour les dispositifs en état RRC inactif
Optimisations de couche physique : réduction de la consommation en mode veille et actif

Architecture réseau

eRedCap s’appuie exclusivement sur l’architecture 5G Standalone (SA), ce qui permet de bénéficier de fonctionnalités avancées :

Network slicing : isolation et garanties de qualité par tranche réseau
URLLC (Ultra-Reliable Low-Latency Communications) : pour les applications critiques
API natives cloud : intégration facilitée avec les plateformes IT
Orchestration native cloud : déploiement et gestion automatisés

Cas d’usage d’eRedCap

Applications industrielles

Capteurs industriels sans fil eRedCap est particulièrement adapté aux capteurs de surveillance d’équipements, de température, de vibrations ou de qualité environnementale dans les usines. Le débit de 10 Mbps est largement suffisant pour transmettre des données de télémétrie, tandis que la faible consommation énergétique permet des déploiements sur batterie durant plusieurs années.

Automatisation industrielle Dans les environnements de production, eRedCap permet la connexion de dispositifs de contrôle-commande ne nécessitant pas de latence ultra-faible mais requérant une connexion fiable et sécurisée.

Ville intelligente et santé connectée

Compteurs intelligents Les réseaux électriques intelligents peuvent utiliser eRedCap pour la télémétrie des sous-stations et l’automatisation de la distribution, bénéficiant particulièrement du profil de trafic orienté liaison montante.

Dispositifs médicaux portables Les moniteurs de santé, capteurs physiologiques et dispositifs de télésurveillance médicale représentent un marché majeur pour eRedCap. Ces dispositifs nécessitent une connexion fiable mais avec des débits modérés, tout en étant extrêmement contraints en termes de taille et d’autonomie.

Infrastructure urbaine Éclairage public connecté, gestion des déchets, surveillance environnementale : autant d’applications où eRedCap offre un excellent compromis entre performance et coût.

Objets connectés grand public

Wearables et accessoires connectés Montres connectées, trackers d’activité, vêtements intelligents et dispositifs de localisation bénéficient de la compacité et de l’efficacité énergétique d’eRedCap.

Terminaux point de vente (POS) Dans le secteur de la distribution, les terminaux de paiement mobiles et caisses enregistreuses sans fil constituent un cas d’usage privilégié.

Comparaison avec les autres technologies

eRedCap vs RedCap

Caractéristique	RedCap (Rel-17)	eRedCap (Rel-18)
Débit DL	Jusqu’à 226 Mbps	10 Mbps (plafonné)
Débit UL	Jusqu’à 120 Mbps	10 Mbps (plafonné)
Bande passante RF	20 MHz (FR1), 100 MHz (FR2)	20 MHz (FR1 uniquement)
Bande passante données	20 MHz	5 MHz ou 20 MHz
Équivalent LTE	Cat-2/3/4	Cat-1/1bis
Réduction complexité	~65% (FR1)	~70%

eRedCap vs LTE Cat-1/1bis

eRedCap offre plusieurs avantages par rapport à LTE Cat-1/1bis :

Architecture end-to-end 5G native
Accès au spectre 5G (bandes FR1)
Gestion QoS améliorée et network slicing
Latence réduite
Efficacité spectrale supérieure
Support de VoNR (Voice over NR)
Sécurité renforcée (authentification basée SIM, chiffrement fort)

Déploiement et écosystème

Compatibilité dual-mode

Les spécifications eRedCap facilitent les implémentations dual-mode supportant à la fois 4G (Cat-1/1bis) et 5G (eRedCap), grâce à l’alignement des exigences matérielles. Cette caractéristique permet une migration progressive et économique de la 4G vers la 5G.

Calendrier de disponibilité

2022 : Introduction de RedCap (Release 17)
Juin 2024 : Finalisation des spécifications eRedCap (Release 18)
2025-2026 : Déploiements commerciaux des premiers dispositifs eRedCap
2030 : Projections indiquent qu’eRedCap pourrait représenter jusqu’à 8% des modules IoT cellulaires

Perspectives et évolutions futures

Release 19 et au-delà

Le 3GPP poursuit l’évolution d’eRedCap dans les releases suivantes :

Wake-up receiver : récepteur de réveil ultra-basse consommation pour optimiser davantage l’efficacité énergétique
Améliorations de couverture : techniques avancées pour étendre la portée
Optimisations pour réseaux privés : fonctionnalités spécifiques aux campus industriels

Vers la 6G

eRedCap fait partie de la 5G-Advanced et constitue une brique fondamentale de la transition vers la 6G. Les concepts d’optimisation de complexité et de différenciation des classes de dispositifs développés pour eRedCap influenceront les futures générations de technologies cellulaires.

Enjeux et défis

Plusieurs défis subsistent pour une adoption massive d’eRedCap :

Scalabilité : gestion d’un grand nombre de dispositifs eRedCap tout en maintenant la qualité de service
Coexistence : optimisation du partage de ressources entre dispositifs eRedCap et 5G NR haute performance
Standardisation continue : coordination avec l’évolution des use cases industriels
Écosystème de modules : développement d’une offre diversifiée et compétitive

Conclusion

eRedCap représente une avancée majeure dans l’écosystème 5G, comblant le fossé entre les technologies LPWAN (NB-IoT, LTE-M) et les dispositifs 5G haute performance. En offrant un débit de 10 Mbps avec une complexité réduite de 70% par rapport à la 5G NR standard, eRedCap ouvre la voie à une nouvelle génération de dispositifs IoT 5G économiques, compacts et énergétiquement efficaces.

Cette technologie permet la migration des catégories LTE Cat-1/1bis vers la 5G tout en bénéficiant de l’architecture 5G Standalone et de ses fonctionnalités avancées (network slicing, faible latence, sécurité renforcée). Avec un calendrier de déploiement commercial prévu pour 2026 et des projections optimistes pour 2030, eRedCap est appelé à jouer un rôle central dans la transformation numérique industrielle et l’expansion massive de l’IoT cellulaire.

L’alignement des exigences matérielles avec LTE Cat-1/1bis facilite les implémentations dual-mode et assure une transition en douceur pour les fabricants de dispositifs. Couplé aux améliorations continues du 3GPP dans les releases futures, eRedCap constitue une solution pérenne et évolutive pour répondre aux besoins diversifiés de connectivité de l’ère IoT 5G.

Références 3GPP :

TS 38.306 : UE radio access capabilities
TS 38.300 : NR overall description
Release 17 : Spécifications RedCap
Release 18 : Spécifications eRedCap (finalisées juin 2024)

Les Réseaux Autonomes : Appréhender une évolution vers la 6G

Posté le 27 décembre 2025 by flaunay - 475 vues

Répondre

La Transformation Digitale des Réseaux

Cet article vous propose de découvrir cette évolution majeure qui va redéfinir la manière dont les opérateurs télécoms gèrent leurs infrastructures et répondre principalement à ces deux questions :

Comment les réseaux peuvent-ils devenir « autonomes »
Quel rôle joue l’Intelligence Artificielle dans cette transformation ?

Le Contexte : Des Réseaux Entièrement Numériques

Aujourd’hui, les réseaux de communications sont quasiment tous numériques et basés sur l’IP (par exemple, nous avons assisté au déploiement de la TNT et actuellement au DAB+). Les opérateurs interagissent entre eux et avec leur client via des solutions SDWAN.

Ces réseaux transportent du contenu numérisé et la transmission s’appuie sur des protocoles de signalisation numérique.

Dans ce contexte, les Réseaux Autonomes représentent la prochaine étape logique. L’objectif est ambitieux : capturer une connaissance détaillée et en temps réel du réseau pour intégrer le contrôle directement dans son comportement natif. Autrement dit, faire en sorte que le réseau puisse se gérer lui-même, de manière autonome.

Les 5 Niveaux d’Autonomie : Une Progression vers l’Intelligence

Le TM Forum [1] a défini un cadre structuré autour de 5 niveaux d’autonomie. Comprendre ces niveaux permet de mesurer où nous en sommes et vers quoi nous nous dirigeons.

Niveau 0 : Gestion Manuelle

À ce stade, il n’y a aucune automation. Tout est géré manuellement par les opérateurs humains : configurations, interventions, modifications. C’est lent, coûteux et sujet aux erreurs. Heureusement, ce niveau appartient de plus en plus au passé.

Niveau 1 : Automation Assistée

Les premières briques d’automation apparaissent. Quelques tâches répétitives sont automatisées grâce à des scripts simples, mais toujours sous supervision humaine. L’opérateur décide, le système exécute. On commence à gagner en efficacité, mais le potentiel reste limité.

Niveau 2 : Automation Partielle

L’automation s’étend à des domaines spécifiques du réseau avec l’introduction de systèmes en boucle fermée. Le réseau peut analyser certaines situations et prendre des décisions dans des périmètres bien définis. C’est ici qu’apparaissent les premiers réseaux auto-organisants (SON – Self-Organizing Networks) dans le domaine radio, capables d’optimiser automatiquement certains paramètres ou de se « guérir » face à des problèmes connus.

Niveau 3 : Autonomie Conditionnelle

Nous entrons dans une dimension nouvelle : l’automation devient cross-domaine. Le système peut gérer de manière autonome plusieurs domaines du réseau et prendre des décisions complexes. L’Intelligence Artificielle et le Machine Learning font leur apparition pour prédire les comportements et optimiser les performances. L’opérateur ne définit plus comment faire, mais ce qu’il veut obtenir : on parle alors de pilotage par intention (intent-based networking).

Niveau 4 : Haute Autonomie

Le réseau devient largement autonome avec une intelligence cognitive avancée. Il s’auto-optimise en continu, s’auto-guérit de manière sophistiquée, et s’adapte dynamiquement aux conditions changeantes. L’opérateur définit simplement les objectifs business, et le réseau se gère lui-même pour les atteindre. C’est ce niveau que visent actuellement les opérateurs, car c’est là que se trouvent les gains les plus significatifs.

Niveau 5 : Autonomie Complète

La vision ultime : une autonomie totale du réseau dans tous les domaines et toutes les situations. Le réseau possède une capacité cognitive complète, apprend en continu, anticipe les besoins futurs et s’adapte même à des situations jamais rencontrées. Le rôle humain devient minimal, se concentrant sur la stratégie globale et les principes éthiques. Cette vision à long terme n’est pas encore atteinte, mais elle guide les développements actuels.

Le Rôle Central de l’Intelligence Artificielle

Une précision importante s’impose : conceptuellement, les Réseaux Autonomes n’impliquent pas nécessairement l’Intelligence Artificielle. Les concepts fondamentaux sont indépendants :

Les capacités Self-X (auto-configuration, auto-optimisation, auto-guérison)
Les boucles fermées (Closed Loop) qui permettent au système d’observer, décider et agir
Le pilotage par intention (Intent-driven)
L’intelligence réseau distribuée

Cependant, dans la pratique, l’IA représente un catalyseur extraordinaire pour accélérer la progression vers l’autonomie complète. Sans IA, atteindre les niveaux 4 et 5 serait extrêmement difficile, voire impossible. L’apprentissage automatique permet notamment de :

Analyser des volumes massifs de données en temps réel
Détecter des patterns complexes invisibles à l’œil humain
Prédire les pannes avant qu’elles ne surviennent
Optimiser automatiquement des milliers de paramètres simultanément
Adapter le réseau à des situations nouvelles jamais programmées

L’Intent-Based Networking : Parler Business, Pas Technique

Au cœur des Réseaux Autonomes se trouve un changement de paradigme fondamental incarné par l’Intent-Based Networking (IBN), ou réseau piloté par intention.

Le Changement de Perspective

Traditionnellement, un opérateur devait spécifier précisément comment configurer le réseau :

« Configure le VLAN 100 sur les ports 1-24, active la QoS avec priorité 5, configure le routage OSPF avec area 0, ajuste les paramètres de bande passante à 10 Gbps… »

Avec l’approche Intent-Based, l’opérateur exprime simplement ce qu’il veut obtenir :

« Je veux que l’application vidéo du service client ait une latence inférieure à 50ms et une disponibilité de 99,9% »

Le système se charge ensuite automatiquement de traduire cette intention en configurations techniques concrètes sur tous les équipements concernés.

Les Quatre Piliers de l’IBN

Un système Intent-Based repose sur quatre composantes essentielles :

1. La Traduction
Le système traduit les intentions de haut niveau (souvent exprimées en termes business) en configurations techniques détaillées. Une intention comme « assurer une connectivité sécurisée entre le site A et le datacenter B » se transforme automatiquement en VPN, règles de pare-feu, QoS, routage et chiffrement.

2. L’Activation
Une fois la traduction effectuée, le système configure automatiquement tous les équipements nécessaires : routeurs, switches, pare-feu, mais aussi ressources cloud et fonctions virtualisées.

3. Le Monitoring Continu
Le système surveille en permanence que l’intention est bien respectée. Il mesure les indicateurs clés (latence, débit, disponibilité) et détecte toute dérive par rapport à l’objectif fixé.

4. L’Assurance et l’Auto-correction
Si l’intention n’est plus respectée, le système se corrige automatiquement : réoptimisation des chemins réseau, allocation dynamique de ressources, auto-guérison en cas de panne.

Un Exemple Concret : Le Network Slicing 5G

Imaginons qu’un opérateur veuille créer un service pour les véhicules connectés. Avec l’approche Intent-Based, il exprime simplement son intention :

« Créer un network slice pour véhicules connectés avec une ultra-faible latence (< 10ms), une haute fiabilité (99,999%), une isolation totale du trafic, et une couverture sur les autoroutes de la zone Sud »

Le système Intent-Based va alors automatiquement :

Allouer les ressources radio nécessaires (RAN slicing)
Configurer le cœur de réseau dédié (Core slicing)
Mettre en place la QoS end-to-end
Assurer l’isolation et la sécurité
Activer un monitoring spécifique pour vérifier en permanence que les objectifs sont atteints

Tout cela sans que l’opérateur n’ait eu à configurer manuellement des milliers de paramètres sur des centaines d’équipements.

Les Bénéfices Business : Pourquoi Investir dans l’Autonomie ?

Une enquête récente menée auprès des principaux opérateurs télécoms révèle que l’objectif prioritaire est d’atteindre le niveau 4 d’autonomie. Pourquoi cet engouement ? Parce que c’est à ce niveau que se trouvent les gains business les plus significatifs :

Réduction des Coûts Opérationnels

L’automation avancée permet de réduire drastiquement les coûts d’exploitation. Moins d’interventions manuelles signifie moins d’erreurs, moins de temps perdu, et des équipes qui peuvent se concentrer sur des tâches à plus forte valeur ajoutée plutôt que sur des opérations répétitives.

Amélioration de la Durabilité

Les Réseaux Autonomes optimisent en permanence la consommation énergétique. L’IA peut, par exemple, désactiver temporairement des cellules radio peu utilisées, ajuster les puissances d’émission, ou optimiser les flux de climatisation dans les datacenters. Dans un contexte où la sobriété énergétique devient cruciale, ces gains sont essentiels.

Nouveaux Services et Agilité

La capacité à déployer rapidement de nouveaux services devient un avantage compétitif majeur. Avec l’Intent-Based Networking, ce qui prenait des semaines de configuration peut se faire en quelques minutes. Les opérateurs peuvent ainsi répondre plus rapidement aux demandes de leurs clients entreprises et proposer des services innovants.

Amélioration de l’Expérience Client

Un réseau qui s’auto-optimise en permanence, qui prévoit les pannes avant qu’elles n’affectent les utilisateurs, et qui s’adapte automatiquement à la charge, c’est l’assurance d’une meilleure qualité de service. L’expérience utilisateur s’améliore sans que le client ne s’en rende compte.

Les Technologies Clés à Maîtriser

Pour réaliser cette vision des Réseaux Autonomes, plusieurs briques technologiques doivent converger :

L’Intelligence Artificielle et le Machine Learning : pour l’analyse prédictive, l’optimisation et la prise de décision
Les boucles fermées (Closed-Loop Automation) : pour observer, décider et agir de manière autonome
SDN et NFV : pour rendre le réseau programmable et flexible
La télémétrie en temps réel : pour avoir une vision précise et instantanée du réseau
L’orchestration multi-domaine : pour coordonner tous les éléments du réseau

Où en Sommes-nous Aujourd’hui ?

La majorité des opérateurs se situent actuellement entre les niveaux 1 et 2 d’autonomie. Les investissements se concentrent massivement sur l’atteinte des niveaux 3 et 4, où se trouvent les gains les plus importants. Le niveau 5 reste une vision à long terme, mais il guide dès aujourd’hui les choix technologiques et architecturaux.

La progression n’est pas linéaire. Certains domaines du réseau peuvent atteindre un niveau d’autonomie élevé (par exemple, l’optimisation radio) tandis que d’autres restent plus manuels. L’objectif est d’harmoniser progressivement l’ensemble vers une autonomie cross-domaine.

Conclusion : Une Révolution en Marche

Les Réseaux Autonomes ne sont pas une simple évolution technologique : ils représentent un changement profond dans la manière de concevoir, d’exploiter et de gérer les infrastructures de télécommunications. En libérant les opérateurs de tâches manuelles complexes, en optimisant continuellement les performances, et en permettant une agilité sans précédent, ils ouvrent la voie à une nouvelle ère des télécommunications.

L’Intelligence Artificielle joue un rôle de catalyseur essentiel dans cette transformation, même si elle n’est pas conceptuellement indispensable aux principes d’autonomie. Couplée au pilotage par intention, elle permet aux opérateurs de se concentrer sur leurs objectifs business plutôt que sur les détails techniques de mise en œuvre.

La route vers l’autonomie complète (niveau 5) est encore longue, mais le chemin est tracé. Les bénéfices observés dès le niveau 4 justifient amplement les investissements actuels. Dans les années à venir, nous verrons probablement émerger des réseaux toujours plus intelligents, capables non seulement de s’adapter à notre monde en constante évolution, mais aussi de l’anticiper.

La 6G sera autonome, intelligente et pilotée par l’intention.

Références

[1] https://www.tmforum.org/topics/an-resources/

U-DESERVE 5G : Démonstration de la 5G directe par satellite pour le CNES

Posté le 5 octobre 2025 by flaunay - 618 vues

Résumé

Le projet U-DESERVE 5G (Unified Direct-to-device Satellite Radio Enhanced Virtual Environment) a été lancé par le CNES dans le cadre du programme France 2030. Piloté par Thales Alenia Space en consortium avec Capgemini et Thales, ce projet vise à démontrer la faisabilité des communications directes entre satellites en orbite basse et terminaux mobiles ou fixes selon le standard 5G Release 17 du 3GPP.

La latence radio sera donc de 26 ms soit 52 ms RTT car la R17 propose l’architecture Transparent Payload. Le satellite LEO est donc un relai RF et cette approche se différencie de l’architecture présentée dans l’article précédent.

Introduction

Le CNES a sélectionné Thales Alenia Space, en partenariat avec Capgemini et Thales, dans le cadre d’un appel à projets lancé pour le compte de l’État au titre du programme France 2030, afin de mettre en œuvre une démonstration innovante de service de télécommunications par satellite selon le standard 5G.

Le projet dénommé U-DESERVE 5G a pour objectif de démontrer la faisabilité des communications directes entre satellites et terminaux mobiles ou fixes (5G Direct to Device ou D2D). Dans cette optique, un satellite de démonstration en orbite basse sera déployé afin de tester l’interopérabilité entre les réseaux 5G terrestres et non-terrestres.

Contexte et enjeux

Dans un contexte où la connectivité en tout temps et en tous lieux est devenue une priorité stratégique, à la fois pour répondre aux attentes du marché et garantir la résilience des infrastructures face aux crises, les technologies satellitaires apparaissent comme une solution complémentaire et essentielle aux réseaux terrestres.

Architecture technique du démonstrateur

Charge utile satellitaire

Au cœur du projet, une charge utile 5G innovante dotée d’antennes actives sera embarquée sur le satellite. Elle permettra de passer des appels et d’échanger des données directement entre le terminal mobile de test et le satellite, et ce sans passer par une station sol.

Composants du système

Le démonstrateur comprendra l’ensemble des éléments de la chaîne :

Satellite de test
Charge utile
Segment sol NTN (Non-Terrestrial Network)
Terminaux mobiles de tests

Le segment sol NTN désigne l’ensemble des infrastructures terrestres qui permettent de communiquer avec les réseaux non terrestres, comme les satellites, les drones à haute altitude (HAPS), ou les ballons stratosphériques.

Conformité aux standards

Le démonstrateur sera compatible avec la Release 17 du standard 5G 3GPP et fournira une plateforme d’essai de bout en bout, destinée à évaluer les performances du système 5G NTN/TN et à expérimenter des cas d’usages, notamment autour de l’Internet des objets (IoT).

Le consortium

Fort de son expertise dans le domaine des télécommunications et des actions menées avec succès en faveur de la normalisation de la 5G par satellite, Thales Alenia Space dirigera le consortium rassemblant :

Capgemini : En charge des solutions d’accès radio et des cœurs de réseau 4G/5G.

Thales : Étudiera la faisabilité d’un terminal 5G D2D à antenne directive fonctionnant dans la future bande C.

Orange : L’expertise d’opérateur est mise à profit et accueillera la démonstration sur son site de Bercenay.

SES : Pour l’étude de la mise en œuvre des services D2D.

Qualcomm : Fournira un terminal de test mobile compatible 5G NTN.

Loft Orbital : Responsable de la plateforme, de l’AIT (Assemblage, Intégration et Test), de la réservation de lancement et de l’exploitation du satellite pendant la phase de démonstration.

Objectifs du projet

Couverture étendue

Selon Stéphane Anjuère, 5G Venture Leader de Thales Alenia Space : « Ce nouveau projet relatif à la 5G directe par satellite ouvre à Thales Alenia Space la voie à une couverture haut débit étendue aux zones non desservies par les réseaux terrestres, mais aussi à des services de secours ou bien de continuité en cas de crise. »

Il ajoute : « En capitalisant sur son expertise dans les domaines des télécommunications géostationnaires et des constellations en orbites moyenne et basse, Thales Alenia Space a joué un rôle déterminant dans la normalisation de la 5G par satellite et a de ce fait toutes les cartes en main pour accompagner des futurs projets de grande envergure liés à la 5G « Direct to Device » par satellite. »

Innovation technologique

Alexandre Bottero, VP Réseaux et Systèmes d’infrastructure de Thales, a déclaré : « Ce projet pionnier de 5G par satellite représente une avancée majeure pour Thales et l’industrie des télécommunications. En développant des solutions modem 5G NTN D2D permettant une connectivité haut-débit, même dans les zones les plus isolées, nous posons les fondations pour l’avenir des communications mondiales et renforçons notre engagement pour un monde plus connecté et résilient. »

Engagement de Capgemini

Angélique Lallouet, Directrice Exécutive de Capgemini Engineering en France, a souligné : « Ce projet illustre parfaitement l’engagement de Capgemini à repousser les frontières de la connectivité. Grâce à notre expertise unique dans l’intégration des réseaux terrestres et non terrestres, ainsi qu’à notre maîtrise des solutions d’accès radio et des cœurs de réseau 4G/5G, Capgemini joue un rôle clé dans la démonstration de la 5G par satellite. Nous sommes particulièrement fiers de contribuer à cette initiative stratégique aux côtés de Thales Alenia Space, Thales et de l’ensemble des partenaires, et de collaborer à nouveau avec le CNES pour faire avancer la souveraineté technologique française et européenne. »

Applications visées

Le projet prévoit notamment de tester des scénarios de mobilité entre la couverture satellitaire et la couverture terrestre 5G, un enjeu clé dans la perspective d’une connectivité mondiale fluide et sans interruption.

Les cas d’usage expérimentés incluront l’Internet des objets (IoT).

Financement

Ce projet a été financé par le Gouvernement dans le cadre de France 2030, opéré conjointement pour le compte de l’État par le CNES et BpiFrance.

France 2030

France 2030, pensé en concertation avec les acteurs économiques, académiques, locaux et européens, offre à la France des moyens exceptionnels pour répondre aux défis écologiques, démographiques, économiques, industriels et sociaux d’un monde en mutation permanente.

Ce plan inédit d’innovation et d’industrie traduit une double ambition :

D’une part, transformer durablement des secteurs clés de l’économie (énergie, automobile, aéronautique, numérique ou encore espace) par l’innovation et l’investissement industriel
D’autre part positionner la France non pas seulement en acteur, mais bien en leader de l’économie de demain

Les acteurs du projet

Thales Alenia Space

Thales Alenia Space combine plus de quarante ans d’expérience et une diversité unique en termes d’expertise, de talents et de cultures. Les architectes de Thales Alenia Space conçoivent et délivrent des solutions innovantes pour les télécommunications, la navigation, l’observation de la Terre et la surveillance de l’environnement, l’exploration, les sciences et les infrastructures orbitales.

Société commune entre Thales (67%) et Leonardo (33%), Thales Alenia Space forme également la Space Alliance avec Telespazio pour proposer une offre complète de solutions incluant les services. Thales Alenia Space a réalisé un chiffre d’affaires de 2,23 milliards d’euros en 2024 et emploie plus de 8100 personnes dans 7 pays, avec 14 sites en Europe.

Thales

Thales est un leader mondial des hautes technologies pour les secteurs de la Défense, de l’Aérospatial et de la Cybersécurité & Digital. Son portefeuille de produits et de services innovants contribue à répondre à plusieurs défis majeurs : souveraineté, sécurité, durabilité et inclusion.

Le Groupe investit plus de 4 milliards d’euros par an en Recherche & Développement dans des domaines clés, en particulier pour les environnements critiques, tels que l’Intelligence Artificielle, la cybersécurité, le quantique et les technologies du cloud. Thales compte plus de 83 000 collaborateurs dans 68 pays. En 2024, le Groupe a réalisé un chiffre d’affaires de 20,6 milliards d’euros.

Capgemini

Capgemini, partenaire de la transformation business et technologique de ses clients, les accompagne dans leur transition vers un monde plus digital et durable, tout en créant un impact positif pour la société. Le Groupe, responsable et multiculturel, rassemble 350 000 collaborateurs dans plus de 50 pays.

Depuis plus de 55 ans, ses clients lui font confiance pour répondre à l’ensemble de leurs besoins grâce à la technologie. Capgemini propose des services et solutions de bout en bout, allant de la stratégie et du design jusqu’à l’ingénierie, en tirant parti de ses compétences de pointe en intelligence artificielle et IA générative, en cloud, et en data, ainsi que de son expertise sectorielle et de son écosystème de partenaires. Le Groupe a réalisé un chiffre d’affaires de 22,1 milliards d’euros en 2024.

Liens avec les travaux de recherche sur la 5G NTN

Le projet U-DESERVE 5G s’inscrit dans un contexte de recherche active sur les réseaux 5G non-terrestres (NTN). Plusieurs aspects techniques font l’objet de travaux approfondis dans la communauté académique et industrielle :

La gestion des cellules en environnement satellitaire

Un des défis majeurs des réseaux NTN concerne la gestion des cellules (ou faisceaux) projetées au sol par les satellites. Contrairement aux réseaux terrestres où les antennes sont fixes, les satellites en orbite basse se déplacent à plus de 27 000 km/h. La Release 17 du 3GPP a introduit le concept de Tracking Area Identifier (TAI) géofixe, où le TAC est associé à une zone géographique fixe au sol plutôt qu’au satellite mobile.

L’architecture du cœur de réseau 5G

L’architecture du cœur de réseau 5G repose sur une Service-Based Architecture (SBA) qui facilite l’intégration des réseaux non-terrestres. Les fonctions essentielles comme l’AMF (Access and Mobility Management Function), le SMF (Session Management Function) et l’UPF (User Plane Function) peuvent être déployées de manière distribuée.

Le NRF (Network Repository Function) fournit un contrôle des fonctions virtuelles et des services proposés. Le NSSF (Network Slice Selection Function) sélectionne le jeu de tranches réseau que l’utilisateur va pouvoir utiliser.

Les états du terminal en 5G

La spécification Release 15 relative à la 5G a introduit un état supplémentaire RRC_INACTIVE en plus des états RRC_CONNECTED et RRC_IDLE. Cet état a été introduit pour les terminaux IoT dans le but de réduire le nombre de requêtes de signalisation et par conséquent la consommation énergétique.

L’interface radioélectrique 5G-NR

L’interface radioélectrique 5G-NR utilise la modulation OFDM (Orthogonal Frequency Division Multiplexing). Une station de base 5G peut moduler au plus 3300 sous-porteuses. L’espacement entre sous-porteuses SCS (SubCarrier Spacing) est défini par la formulation : SCS=2^µ*15 kHz, avec µ la numérologie.

Le bloc de ressource RB (Resource Block) correspond à une allocation de N=12 sous-porteuses contiguës. Un slot est composé de 14 symboles OFDM consécutifs (trame normale).

Le Network Slicing

Le découpage réseau (network slicing) est l’une des caractéristiques différenciatrices majeures de la 5G afin de supporter une multitude de cas d’usage avec des exigences très différentes. Dans la spécification Release 17, une fonction spécifique a été ajoutée pour gérer les ressources des slices : le Network Slice Admission Control Function (NSACF).

Conclusion

Le projet U-DESERVE 5G représente une initiative majeure pour la démonstration de la 5G directe par satellite en France. Soutenu par le programme France 2030 et piloté par un consortium d’industriels de premier plan, ce projet vise à valider la faisabilité technique des communications 5G Direct to Device conformes aux standards 3GPP Release 17.

Cette démonstration s’inscrit dans la stratégie France 2030 qui vise à renforcer la position de la France dans les secteurs technologiques et industriels clés, dont l’aéronautique et l’espace. Elle contribue également à faire avancer la souveraineté technologique française et européenne dans le domaine des télécommunications spatiales.

Références

Sources officielles :

Communiqué de presse Thales Alenia Space : « Thales Alenia Space pilote la démonstration 5G directe par satellite pour le CNES » (septembre 2025)
Petites Affiches des Alpes Maritimes : « U DESERVE 5G : Thales Alenia Space pilote une démonstration de 5G directe par satellite pour le CNES » (9 septembre 2025

Standards 3GPP :

Release 17 : Première spécification complète pour les communications 5G par satellite
TS 23.501 : System Architecture for the 5G System
3GPP (3rd Generation Partnership Project) : Organisme de normalisation

Spécification UE-SAT-UE Communication

Posté le 8 septembre 2025 by flaunay - 458 vues

Nous allons maintenant présenter la solution proposée par la 3GPP pour la mise en oeuvre de la fonction de communication Direct-UE communication, c’est à dire un appel audio/vidéo entre 2 UE via un satellite.

Cet article nécessite une relecture, merci de m’informer si vous notez des erreurs ou des incohérences. J’ai exploité les spécifications TS23.501 TS23.502 et TS23.228 pour écrire cet article et plus précisément la section 5-4.14 de la spécification TS 23.501 de la R.19 (celle-ci n’existe pas dans la R.18) et l’annexe AE1 de la TS 23.228.

Pour comprendre cet article, il est nécesaire de lire l’article précédent.

Cet article se limite à la gestion de la session média sans détailler l’apport du réseau IMS. Toutefois, le P-CSCF est l’entité qui sélectionne la fonction IMS AGW au sol et si la communication par satellite est possible, le P-CSCF relâche l’IMS AGW au sol et sélectionne l’IMS AGW du satellite.

Lors d’un appel IMS, le P-CSCF négocie le codec avec le PCF. Dans le cas d’un appel provenant d’un UE via satellite, le PCF communique au P-CSCF l’identifiant du satellite qui couvre l’UE, et il reçoit de la part du P-CSCF de l’appelé, l’identifiant du satellite qui couvre l’appelé. C’est à partir de ces informations que le P-CSCF détermine s’il peut ou non activer un routage média optimisé (UE-SAT-UE). C’est également le PCF qui informe le P-CSCF en cas de changement de satellite.

Enfin, la spécification 23.501 R.19-j40 propose une procédure d’appel entre 2 UE qui appartiennent au même HPLMN et n’autorise pas l’appel entre deux terminaux sur le même PLMN dont un est en roaming. Ces évolutions seront proposées ultèrieurement mais à la date d’écriture de cet article, la spécification ne prend pas en compte les autres cas d’usage.

Communication UE-Satellite-UE dans les réseaux 5G : Architecture et Mécanismes

Introduction

La communication UE-Satellite-UE (User Equipment-Satellite-User Equipment) représente une avancée significative dans l’évolution des réseaux 5G, permettant des communications directes entre équipements utilisateurs via des satellites. Cette technologie ouvre de nouvelles perspectives pour les services de communication dans des zones géographiques difficiles d’accès ou lors de situations d’urgence.

Figure 1 : UE-SAT-UE communication

Architecture de référence

Déploiement des fonctions réseau

Pour supporter la communication UE-Satellite-UE, la fonction UPF (User Plane Function) doit être déployée directement à bord des satellites en plus du gNB (architecture regénérative). Ces satellites assurent la liaison de service vers les deux équipements utilisateurs impliqués dans la communication.

La signalisation IMS est supportée par le coeur de réseau IMS de l’opérateur sur terre, et la fonction UPF va permettre de gérer le flux RTP de l’UE1 vers l’UE2 sans passer par le coeur de réseau pour que la latence soit tolérable.

Figure 2 : Optimisation du plan média IMS pour un appel via satellite

Contraintes et limitations actuelles

Dans cette première version de la spécification, plusieurs limitations importantes sont à noter :

Services supportés : Seuls les services IMS voix/vidéo sont pris en charge
Périmètre réseau : Les communications sont limitées aux UE appartenant au même PLMN (Public Land Mobile Network)
Mobilité : Seuls les scénarios de non-itinérance sont considérés
Types de satellites : Uniquement les satellites LEO (Low Earth Orbit) et MEO (Medium Earth Orbit) sont supportés

Mécanismes de fonctionnement

Établissement de session

Pour maintenir l’adresse IP de l’UE inchangée lors des services IMS, une approche hybride est adoptée :

Sélection UPF au sol : Un UPF terrestre est sélectionné comme PSA UPF (Packet Data Network Session Anchor UPF) durant la procédure d’établissement de session PDU
UPF satellite : L’UPF embarqué sur le satellite ne sert que comme UL CL/BP (Uplink Classifier/Branching Point) et PSA local pour router le trafic IMS

L’adresse IP allouée à l’UE est fournie par l’UPF au sol (nommée aussi PSA (PDU Session Anchor). Ainsi l’@IP de l’UE ne change pas si on change de satellite.

Gestion des informations satellites

L’AMF (Access and Mobility Management Function) joue un rôle central en rapportant l’identifiant du satellite desservant l’UE au SMF (Session Management Function) lors des procédures d’établissement et de mise à jour de session PDU (PDU Session establishment).

Le processus implique également :

La souscription du PCF (Policy Control Function) aux rapports d’informations du réseau d’accès
La transmission de l’identifiant du satellite via les rapports d’informations du réseau d’accès
L’utilisation de ces informations par l’IMS pour déterminer l’activation possible de la communication UE-Satellite-UE

En effet, l’appel IMS est établi par une requête SIP INVITE. Le P-CSCF a besoin de connaitre l’identifiant du satellite qui couvre l’UE. Il fait donc sa demande au PCF, qui ne dispose pas de cette information. Le PCF va donc interroger le SMF. Le SMF récupère cette information auprès de l’AMF, qui lui, contient cette information. Le DNAI, pour le routage, est dérivé à partir de l’identifiant du satellite.

Gestion de la mobilité satellitaire

Changement de satellite desservant

Lorsque le satellite desservant un UE change (dû au mouvement de l’UE ou du satellite), plusieurs mécanismes sont mis en œuvre :

Procédure de handover : Une procédure de handover basée sur Xn/N2 peut être effectuée pour changer le gNB desservant du satellite source vers le satellite cible
Décision de routage : Le SMF décide si le trafic IMS doit être :
- Routé vers le PSA au sol
- Maintenu sur l’UL CL/L-PSA satellite

Scénarios de continuité

Routage vers le sol : Si le SMF décide de router le trafic vers le PSA au sol, une notification précoce sans ID satellite est envoyée au PCF, indiquant que le plan utilisateur 5GC doit basculer vers le sol.

Maintien sur satellite : Si le SMF décide de conserver l’UL CL/L-PSA sur le satellite, il fournit une notification précoce avec l’ID du satellite cible. L’IMS informe alors le 5GC si la communication UE-SAT-UE peut continuer ou non :

Continuation possible : Allocation d’UL CL/BP et L-PSA sur le satellite cible avec mise à jour des règles de transport
Continuation impossible : Suppression de l’UL CL/BP et L-PSA sur le satellite source

Implications et perspectives

Avantages technologiques

Cette architecture offre plusieurs avantages significatifs :

Réduction de latence : Traitement direct du trafic dans l’espace
Couverture étendue : Desserte de zones géographiques difficiles d’accès
Résilience : Continuité de service même en cas de défaillance des infrastructures terrestres

Défis techniques

Les principaux défis incluent :

Complexité de gestion : Coordination entre systèmes terrestres et spatiaux
Mobilité dynamique : Gestion des handovers entre satellites en mouvement
Ressources embarquées : Limitations de puissance et de traitement des satellites

Conclusion

La communication UE-Satellite-UE représente une évolution majeure des réseaux 5G, ouvrant la voie à des services de communication ubiquitaires. Bien que cette première implémentation soit limitée aux services IMS voix/vidéo dans des scénarios spécifiques, elle pose les fondations pour des développements futurs plus ambitieux.

L’intégration réussie de cette technologie nécessite une coordination étroite entre les composants terrestres et spatiaux du réseau, ainsi qu’une gestion intelligente de la mobilité des satellites et des utilisateurs. Cette approche hybride sol-espace annonce une nouvelle ère pour les télécommunications mobiles globales.

Les acronymes

UL CL (Uplink Classifier)
BP (Branching Point)
L-PSA (Local Packet Data Network Session Anchor),
DNAI (DN Access Identifier).

DNN et DNAI – Cas du MEC et du satellite

Posté le 8 septembre 2025 by flaunay - 551 vues

Répondre

Introduction

Pour se connecter à un service (Internet, IMS, VPN entreprise), l’UE établit une session PDU. Avec l’avènement du Multi-Access Edge Computing (MEC), il devient crucial de pouvoir connecter l’utilisateur non seulement au bon réseau, mais aussi à l’instance locale de ce réseau la plus proche. Cela repose sur deux identifiants clés : le DNN et le DNAI.

DNN (Data Network Name)

Le DNN est l’identifiant qui spécifie le réseau de données auquel un équipement utilisateur (UE) souhaite se connecter. En 5G, les réseaux de données sont spécifiquement identifiés en utilisant un DNN, qui prend typiquement la forme d’un APN (Access Point Name). Cela peut être Internet, l’IMS, un VPN auquel l’UE souhaite se connecter (ex: « internet.mon-operator.com » ou « vpn-entreprise.com »).

Rôle : Utilisé conjointement avec le S-NSSAI (identifiant de tranche de réseau network slice), il permet à l’AMF de sélectionner le SMF approprié et au SMF de sélectionner les UPF qui donneront accès à ce réseau.

Caractéristiques du DNN :

Une session PDU (Protocol Data Unit) est associée à un S-NSSAI et un DNN (Data Network Name)
Il remplace le concept d’APN utilisé en 4G
Il est utilisé conjointement avec le S-NSSAI pour sélectionner les fonctions réseau appropriées
Le SMF utilise le DNN et le S-NSSAI pour la sélection des UPF

DNAI (Data Network Access Identifier)

Le DNAI est un identifiant défini par l’opérateur qui spécifie un point d’accès local à un réseau de données, typiquement pour supporter des applications MEC.

Rôle : Il ne remplace pas le DNN mais vient s’y superposer pour aiguiller le trafic vers une instance locale optimale. Alors que le DNN répond « vers quel réseau ?« , le DNAI répond « par quel point d’accès local ?« .
Format : Une chaîne de type URI ou FQDN (ex: « mec.edge8.city3.region1.5g.example.com »).

Caractéristiques du DNAI :

Le DNAI sert d’étiquette unique pour l’accès du plan utilisateur et identifie les réseaux de données spécifiques où résident les applications
Il permet au réseau 5G de diriger le trafic vers le serveur local (initialement MEC) approprié, basé sur le réseau d’accès aux données auquel l’UE se connecte
Le DNAI est crucial pour la sélection du SMF (Session Management Function) basée sur l’identifiant d’accès au réseau de données. Le DNAI est simplement un identifiant. Il ne représente pas le DN lui-même, mais un point d’accès à un DN.
Il est typiquement représenté sous forme de chaîne, similaire à un URI ou un FQDN

Différences principales :

Niveau d’abstraction :
- DNN : Identifie le réseau de données de destination
- DNAI : Identifie le point d’accès spécifique à ce réseau
Usage :
- DNN : Utilisé pour l’établissement de session et la sélection de services
- DNAI : Utilisé pour l’optimisation du routage et le support MEC
Granularité :
- DNN : Plus global, identifie le service ou le réseau
- DNAI : Plus spécifique, identifie le point d’accès local optimal

Pour résumer :

DNAI = Identifiant d’un point d’accès réseau de données où sont les applications.
UPF = Fonction réseau qui route le trafic vers ce point d’accès
MEC = Applications déployées à ce point d’accès

Clarification importante : Le DNAI ne remplace pas le DNN, mais vient s’y superposer pour aiguiller le trafic vers un accès local optimisé dans un contexte MEC.

Procédure d’établissement de session

Initiation : L’UE envoie une demande d’établissement de session PDU (message NAS) à l’AMF, incluant le DNN et le S-NSSAI.
Sélection du SMF : L’AMF sélectionne un SMF responsable de la gestion de la session (ancrage, adresse IP).
Influence de l’Application (MEC) : Pour du trafic Edge, le serveur MEC (vu comme un AF) communique ses exigences (latence, DNAI cible) au PCF via le NEF. Le PCF génère alors des règles PCC (Policy and Charging Control) et les envoie au SMF.
Sélection de l’UPF et routage : Le SMF utilise le DNN et, si applicable, le DNAI fourni par le PCF pour sélectionner l’UPF optimal qui pourra router le trafic utilisateur vers le point d’accès réseau local (DNAI) désiré.

La configuration/provision des DNAI

L’opérateur configure ses équipements réseau via ses systèmes d’exploitation et de maintenance (O&M – Operation and Maintenance) et son système de support opérationnel (OSS – Operational Support System).

Les DNAI sont publiés via le NRF et connus des SMF, I-SMF, AMF et du PCF

Le MEC (vu comme un AF) s’enregistre auprès du NEF avec ses capacités (latence, bande passante, services disponibles) ou communique directement avec le PCF les informations suivantes :

Exigences de QoS / latence (par ex. contraintes de délai E2E).
Filtres de trafic (IP, Ethernet, Flow Descriptions) pour identifier les flux applicatifs.
DNAI cible (via « AF Influence on Traffic Routing ») : l’AF peut demander un routage vers un point d’accès réseau spécifique où réside l’application (MEC).
Priorité de service ou contraintes de bande passante.

Une fois que le PCF reçoit les informations du MEC/AF (via éventuellement le NEF), il gère la :

Création des règles PCC : Le PCF génère des règles PCC basées sur les demandes AF : informations de filtre IP ou informations de filtre de paquets Ethernet pour identifier le flux de données de service pour le contrôle de politique et/ou la tarification différenciée ; exigences de bande passante média/application pour le contrôle QoS
Transmission au SMF/I-SMF : Npcf et Nsmf permettent au PCF d’avoir un contrôle dynamique sur le comportement de politique et de tarification au niveau du SMF

L’I-SMF est un SMF intermédiaire inséré entre l’AMF et le SMF principal quand :

L’UE est en dehors de la zone de service SMF, ou le SMF actuel ne peut pas servir le DNAI cible pour le routage du trafic pour l’accès local au DN
Le SMF principal ne peut pas contrôler directement certains UPF locaux

L’AMF (Access and Mobility Management Function) peut fournir au SMF des informations de localisation qui permettent de déterminer le DNAI approprié :

Informations de la cellule radio (Cell ID)
Zone de routage (Routing Area)
Zone de localisation (Tracking Area)

Exemple pratique

Insertion I-SMF : L’UE se déplace vers une zone où le SMF principal ne peut pas servir localement
Annonce capacités : L’I-SMF dit au SMF : « Je peux servir les DNAI A, B, C dans cette zone »
Sélection intelligente : Le SMF répond : « Pour cette session PDU, utilise le DNAI B car l’application MEC de l’UE s’y trouve »
Implémentation locale : L’I-SMF configure les UPF locaux pour router le trafic vers le DNAI B

Mécanismes officiels selon 3GPP

1. Via l’I-SMF (Intermediate SMF)

L’I-SMF fournit la liste des DNAI qu’il supporte au SMF : « Voici tous les points d’accès locaux que je peux gérer dans ma zone : DNAI-A, DNAI-B, DNAI-C« .

Le SMF fait ensuite son choix : le SMF fournit le ou les DNAI d’intérêt pour cette session PDU à l’I-SMF basé sur les informations de liste DNAI reçues de l’I-SMF. « Pour cette session spécifique, parmi ta liste, utilise le DNAI-B car c’est là que se trouve l’application MEC dont l’UE a besoin«

Cet échange se fait lors de l’établissement de session ou de la mobilité.

2. Via les règles PCC (Policy and Charging Control)

Selon les règles PCC relatives au mécanisme d’influence du trafic AF concernant les DNAI, le SMF détermine le DNAI cible qui est applicable à la localisation UE actuelle. Le PCF (Policy Control Function) peut fournir des règles PCC contenant des informations DNAI.

3. Via l’AMF pour la sélection I-SMF

L’AMF est responsable de détecter quand ajouter ou supprimer un I-SMF ou V-SMF pour une session PDU. À cette fin, l’AMF obtient du NRF des informations sur la zone de service et les DNAI supportés des SMF.

4. Sélection UPF basée sur DNAI

Les informations concernant les terminaisons de plan utilisateur correspondant aux DNAI sont considérées par le SMF pour la sélection UPF, permettant au SMF de connaître quels UPF peuvent servir quels DNAI.

Processus de notification

Si le SMF sélectionné ne peut pas servir le DNAI cible demandé par la règle PCC, le SMF émet un Nsmf_PDUSession_SMContextStatusNotify pour fournir les informations DNAI cible à l’AMF, qui sélectionne alors un I-SMF approprié.

La découverte et gestion des DNAI s’appuie donc sur l’interaction entre SMF, I-SMF, AMF et PCF via les interfaces standardisées N11, N16a et N7, avec une coordination via le NRF pour la découverte des capacités.

Application au satellite

La gestion de la mobilité et du routage dans un contexte satellite (NTN) repose sur un mapping dynamique entre la cellule radio et la zone géographique.

Configuration du réseau cœur (O&M) : L’opérateur configure statiquement dans l’AMF (et éventuellement le NRF) une table de correspondance qui associe des plages d’identifiants de cellules (Cell ID) à des DNAI. Ce DNAI représente le point d’accès au réseau de données localisé dans la zone géographique couverte par la cellule satellite.
Rôle du gNB-NTN : Le gNB-NTN, alimenté périodiquement par des informations d’éphémérides du satellite utilise ces données pour calculer la position du satellite à tout instant (prédiction continue) et construit un « Cell ID » qui représente la zone géographique couverte par la cellule à un instant t.
- Cell Global Identity (CGI) pour l’identification unique
- Tracking Area pour le regroupement géographique
- Location Area dans certains contextes

Cette cartographie en temps réel permet l’adaptation continue des paramètres radio (timing advance, correction Doppler) et la gestion proactive des handovers inter-faisceaux selon la trajectoire prédictive du satellite.

Processus de sélection :
1. Lors de l’établissement de la session, le gNB transmet ce Cell ID à l’AMF.
2. L’AMF consulte sa table de configuration pour dériver le DNAI correspondant à ce Cell ID.
3. L’AMF utilise ensuite ce DNAI comme facteur clé pour sélectionner un SMF dont la zone de service (Service Area) inclut ce DNAI. Ce SMF sera alors responsable de sélectionner l’UPF désigné par le DNAI dans le satellite.

Ainsi, le DNAI n’est pas dérivé directement d’un identifiant de satellite, mais indirectement via le Cell ID mappé fourni par le gNB-NTN, permettant au réseau cœur d’adapter le routage en fonction de la localisation géographique cible de l’UE, malgré la nature non stationnaire de l’accès satellite.

Suivi temps réel :
- L’AMF utilise ces informations pour déterminer le DNAI optimal
Optimisation dynamique :
- Pour les satellites en mouvement, l’AMF anticipe les changements de couverture
- Sélection du DNAI du satellite le plus proche géographiquement
Handover inter-satellites :
- Quand un satellite sort de la zone de couverture optimale
- L’AMF initie un handover vers le satellite/DNAI le plus approprié

Les références

Mécanismes DNAI de base :

3GPP TS 23.501 V16.9.0 (Release 16) – clause 5.6.7 (DNAI)
3GPP TS 23.502 V16.9.0 (Release 16) – clause 4.3.2 (PDU Session Establishment)

AF Influence et règles PCC :

3GPP TS 23.503 V16.9.0 (Release 16) – clause 6.1.3.16 (AF influence on traffic routing)
3GPP TS 29.513 V16.9.0 (Release 16) – Npcf_PolicyAuthorization API

I-SMF et mécanismes inter-SMF :

3GPP TS 23.501 V16.9.0 (Release 16) – clause 5.6.9 (Intermediate SMF)
3GPP TS 29.502 V16.9.0 (Release 16) – Nsmf_PDUSession API

NTN et satellites :

3GPP TS 23.501 V17.6.0 (Release 17) – clause 5.6.15 (Non-Terrestrial Networks)
3GPP TS 38.300 V17.2.0 (Release 17) – clause 10 (NTN architecture)

UE-SAT-UE Communication

Posté le 8 septembre 2025 by flaunay - 337 vues

Répondre

ATTENTION : Cet article suit une recommandation et non une spécification. C’est donc seulement une étude qui a pour objectif de préparer l’écriture d’un autre article sur la communication UE-UE par satellite mais qui sera défini par la spécification R.19.

Cet article est écrit suite à la publication d’un essai de communication satellitaire 5G-NTN : Ericsson, Qualcomm et Thales Alenia Space franchissent une étape clé dans la connectivité par satellite : « Parmi les applications potentielles, cette technologie pourrait prendre en charge les appels vocaux de haute qualité et les services de streaming vidéo en temps réel. »

https://www.ericsson.com/fr/press-releases/3/2025/ericsson-qualcomm-thales-achieve-space-connectivity-milestone

L’article décrit ici s’appuie sur la recommandation TR 23.700-29.

Cette solution permet la communication directe entre équipements utilisateurs via satellites sans transit par les réseaux terrestres. Elle répond au problème concernant le support de la communication UE-satellite-UE.

I) Architecture et principes

L’architecture déploie des gNB (stations de base 5G) et des **UPF (User Plane Functions) directement sur les satellites. Les UE peuvent être desservis par le même satellite ou par des satellites différents connectés via des liens inter-satellites (ISL).

Principe fondamental : La signalisation des UE transite vers les réseaux 5GC et IMS au sol, mais le trafic utilisateur entre les deux UE est routé uniquement par les satellites.

Ces deux points sont fondamentaux et nécessite des hypothèses importantes :

Hypothèses principales
– Les deux UE sont servis par le même PLMN (réseau domestique)
– Les deux UE utilisent la même instance SMF ou I/V-SMF
– Le système IMS détermine pendant l’établissement d’appel s’il faut utiliser la communication UE-Satellite-UE
– La passerelle média IMS (IMS AGW) reste au sol, ce qui signifie que le transcodage n’est pas supporté

Sélection intelligente des UPF

Le document décrit un mécanisme d’association de satellites organisés en groupes. Chaque groupe comprend :
– Des satellites avec gNB embarqués
– Un satellite avec UPF embarqué accessible via ISL
– Des DNAI (Data Network Access Identifier) accessibles

Le SMF sélectionne les UL CL/BP/PSA UPF locaux basés sur :
– L’ID du satellite embarquant le gNB
– Les informations d’association de satellites préconfigurées
– Le DNN fourni par l’UE

Gestion de l’itinérance satellite (Section 6.28.2.3)

La procédure I/V-SMF commun au sol traite un cas complexe d’itinérance où UE1 est dans son réseau domestique et UE2 est en itinérance home-routed dans le PLMN de UE1.

Étapes critiques de la procédure :

1. Établissement séparé des sessions PDU : Chaque UE établit sa session avec des UPF terrestres différents (UPFx pour UE1, UPFy pour UE2 en itinérance)

2. Détection de non-service : SMF1 servant UE1 détecte qu’il ne sert pas l’UE pair (UE2) lors de la demande de communication UE-SAT-UE

3. Sélection I-SMF coordonné : Un SMF dédié (I/V-SMF) supportant la communication UE-SAT-UE est sélectionné pour coordonner les deux sessions

4. Insertion UPF satellites : L’I/V-SMF insère UPF1 sur SAT1 pour UE1 et UPF2 sur SAT2 pour UE2

5. Re-sélection V-SMF : Le SMF2 servant UE2 déclenche également la sélection du même I/V-SMF

6. Chemin média optimisé : Le trafic final suit : UE1 ↔ SAT1(gNB1+UPF1) ↔ SAT2(gNB2+UPF2) ↔ UE2

Innovation technique : Cette procédure montre comment maintenir l’optimisation du trafic spatial même dans des scénarios d’itinérance complexes, en utilisant un SMF coordonnateur qui comprend les spécificités satellite.

Gestion des handovers satellite

Quand le satellite de service change, la procédure maintient la communication en :
– Sélectionnant un nouveau UPF sur le satellite cible
– Mettant à jour les chemins de signalisation
– Gérant la libération des ressources source avec un timer de garde pour éviter les pertes de paquets

Posté le 7 septembre 2025 by flaunay - 225 vues

Répondre

ATTENTION : Cet article suit une recommandation et non une spécification. C’est donc seulement une étude et rien de spécifié.

Article dans la suite des articles précédents.

Solution Store and Forward (SSF) par Satellite avec Proxies UE et Point Terminal

Vue d’ensemble

Cette solution technique permet aux satellites de fournir des services de communication même sans liaison directe continue avec le réseau terrestre. Le principe est de stocker temporairement les données sur le satellite, puis de les retransmettre quand une connexion avec le réseau terrestre redevient disponible.

Principe de fonctionnement

Mode Store and Forward (SSF)

Stockage : Le satellite reçoit et stocke les données des utilisateurs
Retransmission : Plus tard, quand le satellite a accès au réseau terrestre, il transmet toutes les données stockées
Communication différée : Les messages n’arrivent pas instantanément mais avec un délai

Architecture principale

UE (Téléphone) ↔ Satellite en mode SSF ↔ Centre SSF ↔ Destinataire final

Composants clés

1. Satellite en mode SSF

Le satellite contient :

Fonctions RAN (comme une antenne-relais classique)
Cœur de réseau embarqué (CN)
Proxy de point terminal : stocke les données et simule les réponses

2. Centre SSF (SSFC)

Station au sol qui contient :

Proxy UE : simule la présence de l’utilisateur sur le réseau
Serveurs de stockage pour les données en attente

Processus détaillé

Phase 1 : Communication UE → Satellite

Connexion initiale
- Le satellite diffuse un indicateur SSF dans ses signaux
- L’UE se connecte en mode SSF (comme une connexion réseau normale)
- Authentification sécurisée avec clés spéciales
Envoi de données (MO = Mobile Originated)
- L’utilisateur envoie : SMS, données, messages vocaux, requêtes internet
- Le satellite stocke tout dans son « proxy de point terminal »
- Le satellite renvoie des réponses automatiques pour éviter les timeouts
Perte de couverture
- Avant de perdre le contact, le satellite déconnecte proprement l’UE
- Toutes les données restent stockées dans le satellite

Phase 2 : Satellite → Réseau terrestre

Connexion au réseau terrestre
- Quand le satellite a accès à une liaison terrestre
- Il transfère toutes les données UE vers le Centre SSF
Simulation de présence UE
- Le « proxy UE » du Centre SSF se connecte au réseau comme si c’était l’utilisateur réel
- Il envoie tous les messages stockés vers leurs destinataires

Phase 3 : Réponses et retour

Réception des réponses
- Les destinataires peuvent répondre
- Le Centre SSF stocke ces réponses (MT = Mobile Terminated)
Retour vers l’UE
- Le Centre SSF envoie les réponses vers des satellites qui passeront près de l’UE
- Quand l’UE se reconnecte à un satellite, elle reçoit ses messages

Types de communications supportées

✅ Services compatibles

SMS (avec délai)
Messages vocaux unidirectionnels
Transfert de données (fichiers, images)
Requêtes HTTP (navigation internet basique)

❌ Limitations

Pas d’appels téléphoniques en temps réel
Pas de vidéoconférence
Pas de navigation internet interactive
Communication principalement unidirectionnelle

Aspects de sécurité

Solution IOPS (Interoperator Security)

Clés de sécurité spéciales (K*) dérivées de la clé principale
Cartes SIM adaptées ou cartes SIM duales
Double authentification : sur le satellite ET sur le réseau terrestre
Protection de la clé maître contre l’exposition

Optimisations pour la couverture discontinue

Regroupement de données

Packaging : Combiner plusieurs messages en un seul paquet
Transmission rapide pendant les courtes fenêtres de couverture
Dépackaging automatique à la réception

Liste de surveillance S&F

L’UE peut spécifier ses préférences de satellites
Économie d’énergie : surveiller seulement certains satellites
Optimisation des transmissions selon la position et les besoins

Avantages

Couverture étendue : Service même sans infrastructure terrestre
Fiabilité : Les messages finissent par arriver
Zones isolées : Communication possible partout
Efficacité énergétique : Optimisation de la consommation UE

Inconvénients

Délais importants : Pas de communication temps réel
Complexité : Architecture technique sophistiquée
Limitations fonctionnelles : Services restreints
Coût : Infrastructure satellite et centres SSF

Cas d’usage typiques

Zones polaires ou océaniques sans couverture
Situations d’urgence où les réseaux terrestres sont défaillants
Communications IoT dans des zones isolées
Messages de sécurité pour les transports maritimes/aériens

Cette solution représente un compromis intelligent entre couverture universelle et limitations techniques, permettant des communications basiques mais fiables partout sur Terre.