5G « sans couture » : ce qui se cache derrière le mot

Posté le 18 octobre 2026 by flaunay - 67 vues

Introduction

« Sans couture » (seamless) est l’un des mots les plus utilisés dans les présentations 5G, et l’un des moins définis. Derrière l’adjectif se cachent pourtant des mécanismes normalisés très précis, répartis sur plusieurs couches du système.

L’idée commune est simple : la discontinuité existe dans le réseau, mais elle reste invisible pour l’application. L’UE change de cellule, de gNB, d’ancre dans le cœur, voire de technologie d’accès ou de satellite, sans que la session ne soit perçue comme coupée.

L’IMT-2020 (ITU-R M.2410) chiffre cette ambition : un mobility interruption time de 0 ms. Cet article passe en revue les mécanismes 3GPP qui s’en approchent, de la couche radio jusqu’au cœur de réseau et au NTN.

Seamless ou lossless : une distinction 3GPP souvent oubliée

Dans les spécifications, seamless et lossless ne sont pas synonymes. La distinction remonte au LTE (TS 36.300) et se retrouve en NR (TS 38.300).

Seamless : on minimise le temps d’interruption, quitte à perdre quelques paquets pendant la bascule. C’est le choix pour les flux temps réel portés en RLC-UM (voix, vidéo interactive), où un paquet en retard est un paquet inutile.
Lossless : on garantit zéro perte de paquets, quitte à ajouter un peu de latence. La source transfère les PDCP SDU non acquittés vers la cible (data forwarding sur Xn), la numérotation PDCP (SN) est conservée et l’UE envoie un PDCP status report. C’est le choix pour les bearers RLC-AM (données).

Un handover peut donc être lossless sans être seamless, et inversement. Les mécanismes Rel-16 et suivants cherchent à obtenir les deux à la fois.

Côté radio : réduire l’interruption du handover

Dans un handover classique (break-before-make), l’UE coupe le lien avec la cellule source, puis se synchronise et fait un accès aléatoire sur la cible. Cette fenêtre, typiquement de l’ordre de quelques dizaines de millisecondes, est le « trou » que la 5G cherche à refermer. Trois mécanismes y contribuent.

DAPS : garder deux liens en parallèle (Rel-16)

Le Dual Active Protocol Stack handover est un vrai make-before-break. À réception de la commande de handover, l’UE conserve sa liaison avec la source pendant qu’il accède à la cible.

L’UE crée une seconde pile (MAC/RLC/PHY) vers la cible ; chaque DRB DAPS possède une entité PDCP commune, avec des clés de sécurité distinctes pour la source et la cible.
En voie descendante, il reçoit des deux côtés pendant la transition ; le PDCP réordonne et élimine les doublons.
Une fois l’accès aléatoire réussi sur la cible, la voie montante bascule vers la cible, puis la source est relâchée.

L’interruption tend vers 0 ms, au prix d’une capacité terminal accrue (deux chaînes actives) et d’une contrainte de puissance en UL.

CHO : préparer avant d’en avoir besoin (Rel-16)

Le Conditional Handover traite une autre cause de coupure : la commande de handover qui arrive trop tard, quand le lien source est déjà dégradé. Le réseau envoie à l’avance une liste de cellules candidates préparées, chacune associée à une condition d’exécution (événements de type A3 ou A5).

L’UE évalue lui-même ces conditions et exécute le handover dès qu’une est remplie, sans attendre de commande. Le CHO réduit surtout les échecs de handover (RLF, ping-pong), ce qui compte autant que la durée d’interruption pour la perception de continuité. Il peut être combiné au DAPS.

LTM : un changement de cellule piloté en L1/L2 (Rel-18)

La L1/L2 Triggered Mobility pousse la logique plus loin. Les configurations des cellules candidates sont envoyées à l’avance en RRC ; la décision repose ensuite sur des mesures L1 et la bascule est déclenchée par un simple MAC CE.

L’UE peut acquérir à l’avance la synchronisation DL et l’avance temporelle (TA) des candidates, ce qui permet un changement de cellule sans accès aléatoire (RACH-less). La reconfiguration L3 disparaît du chemin critique. Le Rel-18 cible la mobilité intra-CU (entre DU), le Rel-19 étend l’approche à l’inter-CU.

Côté cœur : la continuité de session (SSC modes)

Un handover radio parfait ne suffit pas si l’ancre IP change. En 5GC, la session de données (PDU session) est ancrée sur un UPF appelé PSA (PDU Session Anchor). Avec le MEC, on veut parfois déplacer cette ancre au plus près de l’utilisateur. Le 3GPP (TS 23.501) définit trois modes de continuité de session et de service (SSC modes) :

Mode	Comportement de l’ancre	Adresse IP	Usage typique
SSC 1	Le PSA est conservé pendant toute la session	Inchangée	Continuité stricte (IMS, voix)
SSC 2	L’ancienne session est relâchée, puis une nouvelle est établie (break-before-make)	Change	Applications tolérantes à une reconnexion
SSC 3	Une nouvelle session (ou un nouveau préfixe IPv6) est établie avant de relâcher l’ancienne (make-before-break)	Change, avec recouvrement	MEC, relocalisation d’application

Le mode 3 est le plus intéressant pour le « sans couture » : pendant une fenêtre de temps, l’UE dispose des deux ancres et l’application migre ses flux. La coupure perçue dépend alors de la capacité de l’application à gérer un changement d’adresse.

Entre accès : 5G et Wi-Fi dans la même session (ATSSS)

Le « sans couture » ne concerne pas que la mobilité entre cellules 5G. Depuis le Rel-16, ATSSS (Access Traffic Steering, Switching and Splitting) permet à une même session de s’appuyer simultanément sur un accès 3GPP et un accès non-3GPP, typiquement du Wi-Fi raccordé au 5GC via un N3IWF.

L’UE établit une MA PDU session (Multi-Access) : une seule session logique, deux chemins. Des règles fournies par le réseau (ATSSS rules côté UE, N4 rules côté UPF) décident, flux par flux, comment répartir le trafic :

Active-Standby : un accès principal, l’autre en secours ;
Smallest Delay : le trafic suit l’accès de plus faible latence mesurée ;
Load-Balancing : répartition selon des pourcentages ;
Priority-based : un accès prioritaire, débordement sur l’autre en cas de congestion.

La bascule d’un accès à l’autre se fait sans changer d’ancre ni d’adresse IP. Le transport repose sur MPTCP, ATSSS-LL pour le trafic non-TCP, puis MPQUIC à partir du Rel-18.

En NTN : quand c’est la cellule qui bouge

Avec les satellites LEO, le problème s’inverse : ce n’est plus seulement l’utilisateur qui se déplace, c’est la cellule qui défile à environ 7,5 km/s. Un UE immobile subit des handovers à intervalles réguliers, et en masse : tous les UE d’une même cellule basculent au même moment.

Le 3GPP a adapté les outils terrestres à cette situation prévisible :

CHO temporel et géographique (Rel-17) : les conditions d’exécution peuvent dépendre de l’heure (fenêtre de visibilité du satellite) ou de la distance entre l’UE et le centre de la cellule, et non plus seulement du niveau reçu, peu discriminant en NTN.
Changement de satellite avec resynchronisation (Rel-18) : en cellule quasi fixe au sol, quand un nouveau satellite reprend la même empreinte, la cellule (même PCI) est conservée. L’UE se resynchronise sur le nouveau lien de service sans procédure de handover complète.
Handover RACH-less (Rel-18) : l’UE, qui connaît sa position (GNSS) et les éphémérides, précompense délai et Doppler et évite l’accès aléatoire sur la cible.
Mobilité TN–NTN : à partir du Rel-18, des améliorations de la mobilité en mode connecté et en mode veille entre réseau terrestre et satellite visent une couverture sans couture, le satellite prenant le relais là où le terrestre s’arrête.

Le seamless NTN est donc surtout une affaire d’anticipation : la géométrie orbitale étant connue, le réseau peut préparer les bascules avant qu’elles ne deviennent critiques.

En résumé

« Sans couture » ne désigne pas un mécanisme unique, mais une propriété de bout en bout. Une session ne l’est réellement que si chaque couche traversée l’est aussi.

Couche	Discontinuité masquée	Mécanismes clés	Release
PDCP	Perte ou désordre des paquets	Data forwarding Xn, continuité des SN, status report	LTE / Rel-15
Radio (RRC/MAC)	Interruption pendant le handover	DAPS, CHO, LTM	Rel-16 à Rel-19
Cœur (5GC)	Changement d’ancre UPF/PSA	SSC modes 1, 2, 3	Rel-15
Inter-accès	Passage 5G ↔ Wi-Fi	ATSSS, MA PDU session	Rel-16 et suivantes
NTN	Défilement des satellites LEO, passage TN ↔ NTN	CHO temporel, satellite switch, RACH-less	Rel-17 / Rel-18

Lorsqu’on lit « sans couture » dans une présentation, la bonne question est donc : à quel niveau, et pour quel type de trafic ? Une interruption nulle n’est pas une perte nulle, et une radio parfaite ne protège pas d’un changement d’adresse IP. La 6G, qui vise l’intégration native terrestre–satellite, devra traiter ces couches ensemble plutôt que les empiler.

Références : ITU-R M.2410 ; 3GPP TS 38.300 (NR, architecture et mobilité) ; TS 36.300 (LTE) ; TS 23.501 (5GC, SSC modes et ATSSS).

EDGEAPP : comment la 5G permet-elle aux applications d’exploiter l’Edge Computing ?

Posté le 26 septembre 2026 by flaunay - 101 vues

Répondre

L’Edge Computing constitue une évolution importante introduite avec la 5G. Son principe paraît simple : plutôt que d’envoyer systématiquement les données d’une application vers un serveur situé dans un cloud central, une partie des traitements peut être réalisée dans une infrastructure informatique située plus près de l’utilisateur.

Cette proximité peut réduire la latence, raccourcir le chemin suivi par les données dans le réseau et améliorer l’expérience utilisateur. Le principe devient particulièrement intéressant pour des applications telles que la réalité étendue (XR), le cloud gaming, les applications industrielles, les véhicules connectés ou encore certaines applications utilisant l’intelligence artificielle.

Mais rapprocher les serveurs des utilisateurs introduit un nouveau problème : dans une architecture cloud classique, une application peut connaître à l’avance le serveur sur lequel elle doit se connecter. Dans un environnement Edge, il peut au contraire exister plusieurs instances du même service, déployées dans différents sites géographiques.

Le serveur optimal pour un utilisateur situé à Poitiers n’est donc pas nécessairement celui qu’il devra utiliser quelques minutes plus tard s’il se déplace vers Tours.

Il faut pouvoir déterminer :

quels environnements Edge sont accessibles ;
quels services y sont disponibles ;
quel serveur Edge convient à l’application ;
comment exploiter les informations fournies par le réseau 5G ;
et éventuellement comment changer de serveur lorsque l’utilisateur se déplace, sans interrompre son service.

C’est précisément l’un des objectifs de l’architecture EDGEAPP, spécifiée par le 3GPP dans la TS 23.558.

Le 3GPP définit EDGEAPP comme une architecture de couche applicative destinée à permettre le déploiement et l’utilisation d’applications Edge au-dessus des réseaux 3GPP. Elle complète donc les mécanismes Edge du réseau 5G définis dans la TS 23.548.

L’objectif de cet article est de comprendre cette architecture de bout en bout.

1. Pourquoi une architecture spécifique pour les applications Edge ?

Imaginons une application de réalité augmentée. La caméra d’un terminal capture une scène. L’application transmet certaines données à un serveur qui réalise des traitements complexes : reconstruction de la scène, reconnaissance d’objets, génération d’éléments graphiques ou inférence par intelligence artificielle.

Avec un cloud central, le chemin pourrait être schématiquement : UE transmet ses données au gNB vers l’UPF jusqu’au serveur applicatif dans le cloud

Une partie importante de la latence provient du transport des données jusqu’au centre de données. Avec l’Edge Computing, le serveur applicatif peut être rapproché du réseau d’accès. Mais le service peut disposer de plusieurs serveurs, l’un sur Paris, l’autre sur Bordeaux, un autre sur Lyon et un dernier sur Marseille ou Malestroit.

Cette sélection ne dépend pas uniquement de la distance géographique. Elle peut également prendre en compte la topologie du réseau, les ressources disponibles, la zone de service, les caractéristiques de l’application et les politiques du fournisseur Edge.

Deux problématiques complémentaires apparaissent alors :

La découverte applicative : comment le terminal identifie-t-il les environnements Edge et les serveurs capables de fournir le service demandé ?
La connectivité réseau : comment le système 5G permet-il d’acheminer les paquets vers les ressources Edge sélectionnées ?

Le terminal doit donc pouvoir découvrir une instance du service appropriée à son contexte, en fonction de sa localisation, de la topologie réseau et des caractéristiques du service.

2. Architecture générale EDGEAPP

L’architecture EDGEAPP, définie par le 3GPP dans la spécification TS 23.558, permet à une application exécutée sur un terminal mobile d’accéder à des services hébergés à la périphérie du réseau (Edge Computing).

L’architecture repose sur cinq entités complémentaires.

Le terminal utilisateur (UE) héberge :

l’Application Client (AC)
l’entité Edge Enabler Client (EEC).

Le réseau Edge (EDN) héberge :

l’entité Edge Application Server (EAS)
l’entité Edge Enabler Server (EES).

Enfin, l’entité Edge Configuration Server (ECS) fournit les informations permettant au terminal de découvrir les environnements Edge disponibles.

Le principe consiste à séparer les échanges applicatifs des mécanismes nécessaires à leur établissement. L’architecture distingue donc deux niveaux.

La couche applicative assure les échanges entre l’AC et l’EAS. Elle fournit le service effectivement utilisé : jeu vidéo, réalité augmentée, application industrielle ou traitement d’intelligence artificielle.
La couche Edge Enabler Layer (EEL) facilite l’accès à ces services. Elle regroupe les entités fonctionnelles EEC, EES et ECS, qui interviennent dans la configuration de l’environnement Edge, la découverte des serveurs applicatifs et certaines procédures de continuité de service.

2. Deux architectures complémentaires : EDGEAPP et 5GC

La TS 23.558 (EDGEAPP) définit les mécanismes applicatifs de découverte, de configuration et de continuité.

La TS 23.548 décrit les mécanismes du système 5G permettant la sélection du chemin utilisateur, l’utilisation d’un UPF local, l’identification des points d’accès aux réseaux de données par les DNAI et la découverte DNS des serveurs applicatifs.

3. Les fonctions du EDGEAPP

3.1 AC – Application Client

L’Application Client est l’application présente dans le terminal.

Il peut s’agir par exemple d’une application :

XR ;
cloud gaming ;
industrielle ;
automobile ;
multimédia ;
d’intelligence artificielle.

L’AC communique avec son serveur applicatif. L’AC est une application téléchargée d’un store (Google Play, Apple Store).

L’AC échange les données nécessaires à son fonctionnement avec un serveur applicatif, appelé Edge Application Server (EAS).

Cependant, l’AC n’a pas nécessairement connaissance des mécanismes permettant de découvrir l’infrastructure Edge. Il peut s’appuyer sur l’EEC pour identifier un serveur adapté à ses besoins.

L’interface EDGE-5 gère les interactions entre l’AC et l’EEC.

3.2 Entité EEC – Edge Enabler Client

L’entité Edge Enabler Client est située dans le terminal. Elle joue un rôle central dans l’accès aux services Edge.

L’entité EEC participe :

au service provisioning ;
à l’enregistrement auprès d’une entité EES ;
à la découverte des serveurs EAS ;
à certaines procédures de continuité de service.

Un terminal peut contenir plusieurs entités EEC. Une même entité EEC peut également communiquer avec plusieurs entités EES.

L’entité EEC utilise principalement deux interfaces : EDGE-4 pour communiquer avec l’entité ECS et EDGE-1 pour communiquer avec l’entité EES.

3.3 L’entité ECS – Edge Configuration Server

L’entité Edge Configuration Server intervient en amont de la découverte des applications.

Son rôle principal est de fournir à l’entité EEC les informations de configuration nécessaires pour accéder à un environnement Edge approprié, l’identification du réseau EDGE -EDN, sa zone de service et les informations permettant de joindre un ou plusieurs entités EES.

Le service provisioning permet précisément de configurer l’entité EEC avec les informations relatives aux services Edge disponibles en fonction :

de la localisation de l’UE ;
des besoins du service ;
des préférences ;
de la connectivité.

Une entité ECS peut prendre en charge plusieurs réseaux EDN et fournir à l’entité EEC les informations relatives à plusieurs entités EES.

Il ne faut donc pas confondre l’entité ECS et l’entité EES : la première permet de découvrir et de configurer l’accès à l’environnement Edge, tandis que la seconde facilite la découverte des applications hébergées dans cet environnement.

3.4 Entité EES – Edge Enabler Server

L’entité Edge Enabler Server est déployée dans l’environnement Edge.

Il fournit aux entités EEC les fonctions nécessaires à l’utilisation des services Edge.

L’entité EES connaît les serveurs EAS qui lui sont associés. Les serveurs EAS peuvent s’enregistrer auprès de l’entité EES avec leurs informations de disponibilité, y compris certaines contraintes temporelles ou géographiques. Il permet ensuite à l’entité client EEC de découvrir un serveur EAS.

On peut donc considérer l’entité EES comme un point d’entrée vers les services applicatifs d’un environnement Edge. Mais son rôle va au-delà d’un simple annuaire : il intervient également dans l’exposition de capacités réseau, certaines demandes de QoS et la continuité de service.

3.5 Le Serveur EAS – Edge Application Server

L’Edge Application Server constitue le serveur applicatif avec lequel l’Application Client communique.

Plusieurs instances d’un même service peuvent être déployées dans différents réseaux EDN. Chacune peut posséder ses propres caractéristiques, sa zone de service et ses conditions de disponibilité.

Le serveur EAS peut également exploiter certaines capacités du réseau 3GPP, directement lorsque les conditions de confiance le permettent, par l’intermédiaire de l’entité EES ou au moyen des fonctions d’exposition du réseau, telles que la NEF.

3.6. L’Edge Data Network : où sont hébergées les applications ?

L’EDN – Edge Data Network correspond au réseau de données dans lequel les ressources Edge sont accessibles.

Il peut héberger une ou plusieurs entités EES et plusieurs serveurs EAS. Un fournisseur Edge peut ainsi proposer différents services applicatifs au sein d’un même EDN.

L’EDN constitue donc l’environnement réseau dans lequel les applications Edge sont déployées et rendues accessibles aux terminaux.

4. Les interfaces EDGEAPP

Pour permettre à ces fonctions de coopérer, la spécification TS 23.558 définit plusieurs points de référence appelés EDGE-1 à EDGE-9

L’interface EDGE-1 permet l’enregistrement/désenregistrement de l’EEC, la récupération d’informations de configuration EAS, la découverte des EAS et certaines procédures de continuité de service.

L’interface EDGE-2 relie l’Edge Enabler Server (EES) aux fonctions du cœur de réseau 3GPP. Elle permet à l’entité EES d’accéder aux capacités réseau exposées par l’opérateur, par exemple pour obtenir des informations de localisation ou interagir avec des mécanismes de QoS et d’influence sur le routage du trafic. Selon le modèle de déploiement, ces interactions peuvent passer par le NEF, qui expose certaines capacités du 5GC aux applications autorisées, ou utiliser des interfaces directes lorsque l’entité EES appartient au domaine de confiance de l’opérateur.

L’interface EDGE-3 permet l’enregistrement des EAS, la découverte d’un EAS cible lors d’une relocalisation, l’accès à certaines informations réseau et des opérations relatives à la QoS et à la continuité.

L’interface EDGE-4 permet à l’entité EEC de récupérer les environnements Edge auxquels il peut accéder auprès de l’entité ECS; A partir de ces informations, l’entité EEC pourra contacter les entités EES appropriées. Cette interface intervient donc en amont de la découverte des EAS.

L’interface EDGE-5 permet à l’application de s’enregistrer auprès de l’entité EEC, de demander la découverte d’un EAS, de déclencher une procédure de relocalisation du contexte applicatif (ACR) ou de s’abonner aux services proposés par l’EEC.

L’interface EDGE-6 permet à une entité EES de s’enregistrer auprès de l’entité ECS avec les informations correspondantes. L’entité EES peut évidemment se désenregistrer ou récupérer des informations concernant un EES cible (Target EES, T-EES).

Les interfaces EDGE-7 et EDGE-8 permettent de communiquer avec le cœur de réseau.

L’interface EDGE-9 permet la coopération entre plusieurs entités EES.

5. Comment un terminal découvre-t-il son environnement Edge

Lorsqu’un utilisateur démarre une application compatible Edge, plusieurs opérations peuvent être nécessaires avant que l’AC communique avec son serveur applicatif.

Découverte de l’ECS : c’est le premier problème de la phase d’initialisation qui permet à l’EEC de savoir quel ECS contacter pour commencer à utiliser EDGEAPP.
Service Provisioning : L’ECS fournit les informations relatives aux environnements Edge et aux EES appropriés.
EEC Registration : L’EEC s’enregistre auprès de l’EES sélectionné si cet enregistrement est requis.
EAS Discovery : L’EEC interroge l’EES afin de découvrir un serveur applicatif correspondant aux besoins de l’AC.
Communication applicative : L’AC peut commencer ses échanges avec l’EAS découvert.

5.1. Première étape : découvrir l’ECS

Avant de demander les informations relatives aux environnements Edge, l’EEC doit savoir quel ECS contacter.

La TS 23.558 prévoit plusieurs possibilités pour obtenir ses informations de configuration. Elles peuvent être préconfigurées dans l’EEC, fournies par une application compatible Edge, renseignées par l’utilisateur ou provisionnées par l’opérateur au travers du système 5G.

Les informations peuvent comprendre une URI, un FQDN, une adresse IP ou encore l’identifiant du fournisseur ECS.

Une possibilité particulièrement intéressante consiste à obtenir l’adresse de l’ECS directement auprès du réseau 5G.

Comment le 5GC peut-il fournir l’adresse de l’ECS ?

La TS 23.548 prévoit un mécanisme appelé ECS Address Provisioning.

Lors de l’établissement d’une session PDU, un terminal compatible peut indiquer sa capacité à recevoir des informations de configuration ECS et à les transmettre à son EEC.

Le SMF peut alors fournir ces informations au terminal au moyen des PCO (Protocol Configuration Options), lors de l’établissement ou de la modification de la session PDU.

Les informations fournies peuvent être associées à certaines conditions de validité, notamment géographiques.

Cette procédure permet au réseau 5G de contribuer à la découverte de l’infrastructure Edge. Elle n’est toutefois pas l’unique méthode de configuration de l’ECS.

5.2. Deuxième étape : le Service Provisioning

Une fois l’ECS identifié, l’EEC peut demander les informations nécessaires pour accéder à un environnement Edge.

Cette opération, appelée Service Provisioning, permet d’obtenir les informations relatives aux EDN et aux EES appropriés.

L’ECS peut tenir compte de plusieurs paramètres : le profil de l’Application Client, la localisation du terminal, les besoins du service, la connectivité disponible et les politiques du fournisseur Edge.

Les zones de service

La proximité d’un serveur Edge ne se résume pas à une distance géographique.

EDGEAPP distingue plusieurs zones de service :

L’EDN Service Area définit la zone depuis laquelle l’accès à un EDN est autorisé.
L’EES Service Area correspond à la zone de service d’un EES. Elle est égale ou incluse dans celle de l’EDN.
L’EAS Service Area définit la zone de service d’un EAS. Elle est égale ou incluse dans celle de l’EES qui le dessert.

Ces zones peuvent être exprimées à partir d’informations géographiques ou topologiques, selon leur nature.

Un serveur géographiquement proche du terminal n’est donc pas nécessairement éligible. Il faut également qu’il soit accessible dans la zone considérée et qu’il puisse fournir le service demandé.

Le rôle du fournisseur Edge

Le fournisseur de services Edge, ou ECSP (Edge Computing Service Provider), peut être l’opérateur mobile lui-même ou un fournisseur tiers.

Un opérateur peut conclure des accords avec plusieurs ECSP et un ECSP peut travailler avec plusieurs opérateurs.

L’ECS est configuré selon la politique de Service Provisioning de l’ECSP. Le 3GPP définit le cadre permettant d’appliquer cette politique, mais ne spécifie pas son contenu détaillé.

5.3. Deux modèles de Service Provisioning

La TS 23.558 prévoit deux modèles de fonctionnement : Request/Response et Subscribe/Notify.

Request/Response Une demande ponctuelle

L’EEC interroge l’ECS pour obtenir les informations de configuration nécessaires. L’ECS retourne les informations correspondant à la demande. L’EEC peut ensuite conserver certaines informations reçues pendant leur durée de validité afin d’éviter de répéter inutilement la procédure.

Subscribe/Notify Une mise à jour sur événement

L’EEC peut s’abonner aux notifications de l’ECS afin d’être informé lorsque des changements justifient une nouvelle configuration.

Par exemple, le 5GC peut signaler un changement du chemin utilisateur. À partir d’un nouveau DNAI, l’ECS peut déterminer que d’autres EES sont devenus plus appropriés et en informer l’EEC.

Le second modèle présente un intérêt particulier pour les applications mobiles. Le terminal n’a pas besoin d’interroger constamment l’ECS pour savoir si son environnement Edge est toujours approprié.

Enregistrement et découverte du serveur applicatif

Après le Service Provisioning, l’EEC dispose des informations lui permettant de contacter un ou plusieurs EES.

Il reste à déterminer quel serveur applicatif pourra fournir le service demandé.

6.1. L’enregistrement de l’EEC

L’EEC peut effectuer une procédure d’enregistrement auprès de l’EES sélectionné.

Cet enregistrement permet de fournir à l’EES les informations nécessaires à certains services Edge. Il n’est cependant pas systématiquement obligatoire : la procédure générale prévoit que l’EEC s’enregistre lorsque le profil de l’EES indique que cet enregistrement est requis.

Il convient de distinguer trois types d’enregistrement dans l’architecture : l’enregistrement de l’EEC auprès de l’EES, celui de l’EAS auprès de l’EES et celui de l’EES auprès de l’ECS.

6.2. L’enregistrement des EAS

Pour répondre aux demandes de découverte, l’EES doit disposer d’informations concernant les serveurs applicatifs disponibles.

Les EAS peuvent donc s’enregistrer auprès de l’EES par l’interface EDGE-3.

Ils transmettent leurs informations de disponibilité, leurs caractéristiques et certaines contraintes géographiques ou temporelles.

L’EES dispose ainsi des informations nécessaires pour identifier les EAS susceptibles de répondre aux demandes des EEC.

6.3. EAS Discovery : trouver le serveur applicatif

À ce stade, l’EEC connaît l’ECS, dispose des informations relatives à l’EDN et sait quel EES contacter.

Il lui reste à découvrir un EAS correspondant au service demandé par l’Application Client.

L’EEC envoie une demande de découverte à l’EES via EDGE-1. L’EES identifie les EAS correspondant aux critères de la demande et retourne les informations nécessaires pour les joindre.

L’EEC peut alors transmettre à l’AC les informations dont il a besoin.

L’application dispose désormais des éléments nécessaires pour communiquer avec son serveur applicatif.

Comment le réseau 5G achemine-t-il les paquets vers l’Edge ?

La découverte d’un EAS ne suffit pas à garantir un chemin réseau approprié.

Il faut également que le trafic de la session PDU puisse être acheminé vers le réseau de données hébergeant le serveur applicatif.

La TS 23.548 définit plusieurs modèles de connectivité Edge permettant au système 5G de répondre à cette problématique.

7.1. Session Breakout et UPF local

Dans une architecture de Session Breakout, certains flux de la session PDU peuvent être dirigés vers un UPF local afin d’accéder à un EDN.

Un UL CL (Uplink Classifier) ou un Branching Point, selon le modèle de connectivité, permet de différencier les flux et de les orienter vers les points d’ancrage appropriés.

Le trafic destiné à un service Edge peut ainsi être acheminé vers un PSA UPF local, tandis que d’autres flux continuent à utiliser un chemin différent.

Ce mécanisme permet de rapprocher le point de sortie du trafic du serveur applicatif.

7.2. DNAI : identifier le point d’accès au réseau de données

Le DNAI (Data Network Access Identifier) identifie un point d’accès au réseau de données.

Il permet au système 5G de représenter les différents points d’accès possibles à un environnement Edge et intervient dans les mécanismes de sélection du chemin utilisateur.

Lorsqu’un terminal se déplace, le point d’accès approprié peut changer. Le 5GC peut alors adapter le chemin du trafic vers un autre point d’accès au réseau de données.

Cette évolution peut également avoir des conséquences au niveau applicatif : un autre environnement Edge ou un autre EAS peut devenir plus approprié.

C’est ici qu’apparaît l’une des principales complémentarités entre le 5GC et EDGEAPP.

7.3. Une autre méthode de découverte : DNS et EASDF

La TS 23.548 prévoit également un mécanisme de découverte des serveurs applicatifs reposant sur le DNS.

Il fait intervenir l’EASDF (Edge Application Server Discovery Function), qui permet au système 5G de coordonner certaines procédures de résolution DNS avec les informations de connectivité Edge.

Le terminal peut ainsi obtenir l’adresse IP d’un EAS approprié à partir d’une requête DNS.

Ne pas confondre EES et EASDF

Deux mécanismes de découverte situés à des niveaux différents.

EES TS 23.558 : Découverte applicative des EAS par l’intermédiaire de l’EEC, au sein de l’architecture EDGEAPP.

EASDF TS 23.548 Découverte des adresses IP des EAS par DNS, coordonnée avec les mécanismes Edge du système 5G.

La découverte DNS via l’EASDF ne constitue donc pas une étape supplémentaire obligatoire de la procédure EDGEAPP. Il s’agit de mécanismes distincts qui peuvent être utilisés selon le modèle de déploiement.

7.4. L’exposition des capacités du réseau 3GPP

La couche Edge Enabler peut également exploiter certaines capacités du cœur de réseau.

Les entités EDGEAPP peuvent avoir besoin d’informations relatives à la localisation du terminal, aux événements réseau, à la qualité de service ou aux changements du chemin utilisateur.

Trois interfaces interviennent principalement : EDGE-2 entre l’EES et le cœur 3GPP, EDGE-7 entre l’EAS et le cœur 3GPP, et EDGE-8 entre l’ECS et le cœur 3GPP.

Ces interactions peuvent s’appuyer sur les API exposées par les fonctions SCEF ou NEF. Dans certains modèles de déploiement, un accès direct à certaines fonctions du cœur peut également être possible lorsque les conditions de confiance appropriées sont réunies.

Mobilité et continuité de service

L’un des intérêts de l’Edge Computing est de pouvoir fournir des services à faible latence à des utilisateurs mobiles.

Cependant, lorsqu’un terminal se déplace, le serveur Edge initialement sélectionné peut ne plus être le plus approprié.

Un changement du chemin utilisateur, de DNAI ou d’environnement Edge peut alors nécessiter la découverte d’un autre serveur applicatif.

EDGEAPP prévoit des mécanismes permettant d’accompagner cette évolution, l’Application Context Relocation (ACR).

Lorsqu’une application possède un contexte d’exécution sur un serveur, un changement d’EAS peut nécessiter le transfert de ce contexte vers un nouveau serveur.

L’ACR permet d’organiser cette relocalisation entre un EAS source (S-EAS) et un EAS cible (T-EAS). Les EES source et cible peuvent également coopérer, au moyen de l’interface EDGE-9.

L’objectif est de permettre la poursuite du service avec une interruption minimale, sous réserve que l’application et l’infrastructure prennent en charge les mécanismes nécessaires.

Étude de cas : une application XR dans un véhicule connecté

Reprenons l’ensemble de l’architecture à travers un exemple.

Un passager utilise une application de réalité augmentée dans un véhicule circulant entre Poitiers et Tours. L’application transmet certaines données à un serveur Edge chargé de réaliser des traitements graphiques et de reconnaissance d’objets.

Du lancement de l’application à la mobilité

1- Établissement de la session PDU

Le terminal se connecte au réseau 5G. S’il prend en charge le mécanisme approprié, le SMF peut lui fournir les informations de configuration ECS par les PCO.

2- Découverte de l’ECS

Le terminal transmet les informations reçues à l’EEC. Celui-ci peut désormais contacter le serveur de configuration.

3- Service Provisioning

L’EEC transmet les informations nécessaires à l’ECS, le profil de l’application XR. L’ECS identifie les environnements Edge et les EES appropriés en tenant compte des paramètres disponibles.

4- Enregistrement auprès de l’EES

Si le profil de l’EES l’exige, l’EEC effectue son enregistrement auprès du serveur sélectionné.

5- Découverte de l’EAS

L’EEC demande à l’EES d’identifier un serveur capable de fournir le service XR. L’EES retourne les informations nécessaires pour joindre un EAS approprié.

6 – Début des échanges applicatifs

L’AC communique avec l’EAS découvert. Le trafic est acheminé par le système 5G vers le réseau de données hébergeant ce serveur.

7- Déplacement du véhicule

Lorsque le véhicule se rapproche de Tours, le chemin réseau initial peut devenir moins approprié. Le 5GC peut adapter le chemin utilisateur et déterminer un nouveau DNAI.

Dans le modèle Subscribe/Notify, l’ECS peut exploiter les informations réseau reçues pour déterminer si d’autres EES sont désormais plus adaptés et notifier l’EEC.

8 – Relocalisation du contexte applicatif

Si l’application prend en charge les mécanismes de continuité nécessaires, un nouvel EAS peut être sélectionné. Le contexte applicatif peut être transféré de l’EAS source vers l’EAS cible au moyen des procédures ACR.

Cet exemple montre que la mobilité Edge ne se limite pas à modifier le routage des paquets. Elle peut nécessiter une coordination entre les mécanismes du réseau 5G et les procédures applicatives EDGEAPP.

Conclusion

L’Edge Computing ne consiste pas uniquement à rapprocher les serveurs des utilisateurs. Il nécessite également des mécanismes permettant aux applications de découvrir les ressources disponibles, d’y accéder et, lorsque cela est nécessaire, de poursuivre leur service lors des déplacements.

L’architecture EDGEAPP, définie dans la TS 23.558, apporte les mécanismes de configuration, de découverte et de continuité au niveau applicatif grâce à l’EEC, l’ECS et l’EES.

La TS 23.548 complète cette architecture en définissant les mécanismes du système 5G nécessaires à l’accès aux ressources Edge, la sélection du chemin utilisateur, les UPF locaux, les DNAI et la découverte DNS via l’EASDF.

La complémentarité entre ces deux spécifications permet de relier la découverte des services applicatifs à la connectivité réseau, afin de rendre les environnements Edge accessibles aux applications mobiles.

Références

[1] 3GPP TS 23.558 — Architecture for enabling Edge Applications Architecture EDGEAPP, fonctions, interfaces, Service Provisioning, découverte et continuité de service.

[2] 3GPP TS 23.548 — 5G System Enhancements for Edge Computing- Connectivité Edge, découverte DNS, EASDF, DNAI et provisioning de l’adresse ECS.

[3] 3GPP TS 23.501 — System Architecture for the 5G System

[4] 3GPP TS 23.502 — Procedures for the 5G System

[5] 3GPP TS 23.503 — Policy and Charging Control Framework for the 5G System

De la 5G à la 6G : vers une nouvelle génération d’algorithmes de chiffrement avec l’AEAD ?

Posté le 14 septembre 2026 by flaunay - 137 vues

Répondre

La 6G va permettre de nouveaux usages nécessitant des débits très élevés et des temps de réponse très faibles. Dans ce contexte, la protection des données ne doit pas devenir un facteur limitant : il faut pouvoir chiffrer et authentifier les données avec une latence et une consommation énergétique aussi faibles que possible.

C’est dans ce cadre que le 3GPP étudie l’utilisation d’une approche cryptographique appelée AEAD – Authenticated Encryption with Associated Data, que l’on peut traduire par chiffrement authentifié avec données associées.

Pour comprendre l’intérêt de cette évolution, commençons par regarder comment les données sont protégées aujourd’hui.

1. Les algorithmes de sécurité en 5G ?

Dans un réseau mobile, deux propriétés de sécurité doivent être assurées :

la confidentialité : un utilisateur non autorisé qui intercepte les données ne doit pas pouvoir les comprendre ;
l’intégrité : le récepteur doit pouvoir vérifier que les informations reçues n’ont pas été modifiées.

En 5G, ces deux fonctions reposent sur des mécanismes cryptographiques distincts.

Le 3GPP définit notamment :

128-NEA1, 128-NEA2 et 128-NEA3 pour le chiffrement ;
128-NIA1, 128-NIA2 et 128-NIA3 pour la protection de l’intégrité.

Dans la pile protocolaire radio, ces mécanismes sont notamment appliqués au niveau de la couche PDCP – Packet Data Convergence Protocol.

De manière très simplifiée :

Données PDCP
      |
      +----> chiffrement
      |
      +----> protection d'intégrité

Ces mécanismes sont déjà fortement optimisés. Le problème posé par la 6G n’est donc pas que la cryptographie 5G serait inefficace, mais que les nouvelles contraintes du réseau conduisent à étudier une autre manière d’organiser ces fonctions de sécurité.

2. Pourquoi AEAD pour la 6G ?

Une piste consiste à assurer le chiffrement et l’authentification au sein d’une même construction cryptographique.

Une opération AEAD peut être représentée simplement :

Message
   +
Clé
   +
Nonce
   +
Données associées
   |
   v
  AEAD
   |
   v
Message chiffré + Tag d'authentification

Le message est chiffré et le tag d’authentification permet au récepteur de vérifier qu’il n’a pas été modifié.

L’intérêt d’AEAD réside dans la conception d’une primitive assurant conjointement chiffrement et authentification. Selon l’algorithme et son implémentation, cette intégration peut permettre de mutualiser certains traitements.

Et les « Associated Data » ?

AEAD permet également d’authentifier des informations sans nécessairement les chiffrer.

Prenons un exemple volontairement simplifié :

En-tête
visible mais authentifié
        +
Données utilisateur
chiffrées et authentifiées

Certaines informations peuvent ainsi rester accessibles pour permettre le traitement du paquet, tout en étant protégées contre une modification.

Dans un véritable réseau 6G, déterminer quelles informations pourraient jouer le rôle d’Associated Data sera une question d’architecture.

Avec le network slicing, différentes classes de service ou de nouvelles fonctions distribuées, certaines métadonnées peuvent devoir rester accessibles à certaines entités du réseau.

La question est alors : quelles informations le réseau doit-il pouvoir lire tout en étant certain qu’elles n’ont pas été modifiées ?

3. Comment AEAD pourrait-il s’intégrer dans la 6G ?

Introduire AEAD ne consiste pas seulement à choisir un algorithme. Il faut aussi déterminer comment le terminal et le réseau négocient son utilisation et comment la protection est activée.

En 5G, la mise en place de la sécurité repose notamment sur :

le NAS Security Mode Command, entre l’AMF et l’UE ;
l’AS Security Mode Command, entre le gNB et l’UE.

Le principe général est le suivant :

UE                              gNB
 |                               |
 |---- capacités de sécurité --->|
 |                               |
 |<---- Security Mode Command ---|
 |                               |
 |---- Security Mode Complete -->|
 |                               |
 |       Sécurité activée         |

Une piste pour la 6G consiste à faire évoluer ce principe plutôt qu’à reconstruire entièrement les procédures de sécurité.

Le futur aNB pourrait par exemple sélectionner un algorithme AEAD parmi ceux supportés par le terminal :

UE                                     aNB
 |                                      |
 |---- capacités AEAD supportées ------>|
 |                                      |
 |<---- Security Mode Command ----------|
 |      algorithme AEAD sélectionné     |
 |                                      |
 |---- Security Mode Complete --------->|
 |                                      |
 |                              Activation
 |                              protection

L’algorithme négocié pourrait ensuite être utilisé au niveau où la protection est requise, notamment pour le trafic utilisateur au niveau PDCP selon l’architecture finalement retenue.

Il ne s’agit pas d’une architecture 6G déjà normalisée. Le 3GPP étudie encore plusieurs possibilités dans le cadre des travaux FS_AEAD, menés au sein du groupe SA3 chargé de la sécurité.

L’intérêt est surtout de constater qu’AEAD pourrait s’inscrire dans la continuité des mécanismes existants, plutôt que provoquer une rupture complète avec la 5G.

4. Rocca-S et SNOW-Axn : des algorithmes pour le très haut débit

En parallèle des travaux de normalisation 3GPP menés dans SA3 (FS_AEAD), plusieurs équipes académiques proposent des constructions AEAD alternatives adaptées aux très hauts débits. Deux d’entre elles retiennent particulièrement l’attention : Rocca-S et SNOW-Axn.

Ces propositions n’ont pas le statut d’algorithmes normalisés : il s’agit
de candidates académiques en phase de recherche et d’évaluation. Leur
intérêt réside dans les débits qu’elles peuvent théoriquement atteindre,
mais le choix final du 3GPP reste ouvert.

Rocca-S

Rocca-S s’appuie notamment sur certaines opérations cryptographiques utilisées dans AES. Celles-ci peuvent être accélérées directement par des instructions disponibles dans les processeurs modernes, ce qui permet d’atteindre des débits de traitement très élevés.

SNOW-Axn

La famille SNOW est particulièrement intéressante pour les télécommunications puisqu’elle est historiquement liée aux mécanismes cryptographiques des réseaux mobiles.

SNOW-Axn adapte cette approche au chiffrement authentifié et certaines variantes atteignent également plusieurs centaines de Gbit/s sur les plateformes testées.

Mesurées en C++ sur processeur Intel haute gamme (i5-1145G7,
single-thread) :

SNOW-Ax4 atteint **421 Gbps** en mode chiffrement seul sur
messages de 256 KB, mais descend à **184 Gbps** sur messages
de 16 KB (taille plus réaliste en trafic 6G).
En mode AEAD complet (chiffrement + authentification), SNOW-Ax4 mesure 311 Gbps sur grands messages.
Rocca-S atteint 197 Gbps en AEAD, soit une alternative compétitive mais moins ambitieuse en débit.

Important: Ces débits reflètent des conditions optimales (messages longs, cache warm, pas de contexte-switching). Le débit réel dépendra de la distribution des tailles de paquets et de la charge système.

Se référer à : https://cic.iacr.org/p/3/1/31/pdf

Ces chiffres doivent toutefois être interprétés correctement. Un débit cryptographique de 200 Gbit/s ne signifie pas qu’un smartphone pourra transmettre à 200 Gbit/s.

Ces benchmarks mesurent la vitesse de traitement de la primitive cryptographique sur une plateforme donnée. Ils ne représentent pas les performances de l’ensemble de la chaîne :

Le choix d’un futur algorithme devra donc également prendre en compte sa latence sur les petits paquets, sa consommation énergétique et son coût d’implémentation dans un équipement réel.

Rocca-S et SNOW-Axn illustrent les recherches actuelles mais, à ce jour, rien ne permet d’affirmer qu’ils seront retenus pour la 6G.

5. AEAD, mobilité et NTN : s’appuyer sur les mécanismes existants

La nécessité de disposer de paramètres cryptographiques variant avec les paquets n’est pas nouvelle dans les réseaux mobiles. En 5G, les algorithmes de chiffrement et d’intégrité utilisent déjà différents paramètres, notamment le COUNT, le bearer et la direction de transmission.

La pile protocolaire doit également maintenir correctement le contexte de sécurité lorsque le terminal change de cellule ou lorsque plusieurs chemins de transmission coexistent, par exemple avec le DAPS handover – Dual Active Protocol Stack ou la duplication PDCP.

L’introduction d’AEAD devra s’inscrire dans cette continuité. Un algorithme AEAD utilise notamment une clé et un nonce, dont les contraintes de réutilisation dépendent de la construction cryptographique retenue.

Une future intégration pourrait donc s’appuyer sur les informations déjà disponibles dans le contexte de sécurité et dans la pile protocolaire :

Contexte de sécurité
        +
Paramètres liés au paquet
(ex. COUNT, bearer, direction en 5G)
        ↓
Paramètres nécessaires à AEAD
        ↓
AEAD
        ↓
Données chiffrées + tag

Ce schéma reste volontairement conceptuel : la manière dont le nonce et les autres paramètres d’un futur algorithme AEAD seraient construits et gérés en 6G n’est pas encore définie.

L’enjeu n’est donc pas de réinventer la gestion du contexte de sécurité, mais de déterminer comment AEAD pourra s’intégrer aux mécanismes déjà utilisés dans les réseaux mobiles.

Et avec les réseaux NTN ?

La même logique peut s’appliquer aux NTN – Non-Terrestrial Networks.

Les communications par satellite introduisent des scénarios de mobilité supplémentaires : changement de satellite, changement de cellule ou transition entre réseau terrestre et réseau non terrestre.

Ces situations ne modifient pas directement le fonctionnement cryptographique d’AEAD. Elles nécessitent en revanche de maintenir correctement le contexte de sécurité au cours de ces transitions.

L’enjeu pour la 6G sera donc de faire en sorte que l’utilisation d’AEAD reste compatible avec les mécanismes de mobilité terrestres et non terrestres, tout en respectant les propriétés de sécurité de l’algorithme finalement retenu.

6. Pourquoi des clés de 256 bits ?

La préparation des réseaux aux futures capacités des ordinateurs quantiques constitue un autre enjeu.

Il faut cependant distinguer deux problématiques.

La cryptographie asymétrique, utilisée notamment pour l’authentification et l’établissement de secrets, pourrait être fortement affectée par un ordinateur quantique suffisamment puissant. C’est pourquoi de nouveaux algorithmes post-quantiques sont développés.
Pour la cryptographie symétrique, comme AES, le problème est différent.

L’algorithme de Grover permet théoriquement d’accélérer la recherche exhaustive d’une clé. L’utilisation de clés symétriques de 256 bits permet alors de conserver une marge de sécurité importante.

Certaines constructions AEAD étudiées, comme Rocca-S ou SNOW-Axn, utilisent ou peuvent utiliser des clés de cette taille.

Il faut cependant éviter un raccourci : AEAD n’est pas synonyme de cryptographie post-quantique.

AEAD et la migration post-quantique répondent à des problématiques différentes, même si elles participent toutes deux à l’évolution de la sécurité des futurs réseaux.

Conclusion

L’évolution vers AEAD ne signifie pas que les mécanismes cryptographiques de la 5G seraient devenus inefficaces.

La question posée par la 6G est différente : peut-on concevoir une protection mieux intégrée, capable d’assurer conjointement confidentialité et authentification tout en répondant aux nouvelles contraintes de débit, de latence et de consommation ?

AEAD constitue une piste particulièrement intéressante pour répondre à cette question.

Des constructions comme Rocca-S et SNOW-Axn montrent que le chiffrement authentifié peut atteindre des débits très importants. Mais les performances brutes ne suffiront pas.

Il faudra également déterminer comment AEAD s’intégrera concrètement aux mécanismes du réseau mobile : négociation de l’algorithme, gestion des clés et des paramètres cryptographiques, mobilité, handovers, NTN et définition des données qui pourront rester visibles tout en étant authentifiées.

La 6G étant encore en cours de définition, le choix des algorithmes et leur intégration dans les protocoles restent ouverts.

C’est précisément ce qui rend les travaux actuels du 3GPP intéressants : il ne s’agit pas seulement de choisir un algorithme plus rapide, mais de déterminer comment faire évoluer l’architecture de sécurité des réseaux mobiles pour accompagner la 6G.

Pour aller plus loin

3GPP – travaux SA3 et étude FS_AEAD – TR 33.771
3GPP TS 33.501 – Security architecture and procedures for 5G System
3GPP TS 38.323 – Packet Data Convergence Protocol (PDCP) specification
3GPP TS 38.331 – Radio Resource Control (RRC)
Travaux de recherche sur Rocca-S
Travaux de recherche sur SNOW-Axn
Travaux 3GPP sur les Non-Terrestrial Networks (NTN)

Du DSS au MRSS : le partage de spectre au cœur de la transition 5G vers 6G

Posté le 7 septembre 2026 by flaunay - 247 vues

Répondre

Introduction

Chaque nouvelle génération de réseau mobile s’accompagne d’une augmentation des débits. Or, le débit accessible dépend de la largeur de bande disponible. La 4G exploite ainsi des canaux pouvant atteindre 20 MHz, tandis que la 5G porte cette largeur jusqu’à 100 MHz en FR1 et 400 MHz en FR2.

Avec la 6G, cette tendance se poursuit. Des largeurs de canal d’au moins 200 MHz sont envisagées pour la 6G. Cependant la largeur de bande dépend de la fréquence de le porteuse :

pour les bandes basses (<2 GHz), la largeur de bande disponible est une dizaine de MHz;
pour les bandes au-dessus de 3 GHz (mid-band), la largeur de bande disponible est une centaine de MHz;
une nouvelle bande à 7 GHz (upper mid-band) pourrait permettre d’avoir jusqu’à 400 MHz de bande;
la bande FR3, nouvelle gamme de fréquences située autour de 7 à 15 GHz pourrait proposer des largeurs de bandes de 200 MHz;
les bandes FR2 (au-delà de 24 GHz, bande millimétrique) proposent des largeurs de 400 MHz.

La situation est cependant différente en FR1, en dessous de 2 GHz. Ces fréquences sont particulièrement importantes pour assurer une couverture étendue, mais le spectre disponible y est déjà largement occupé par les réseaux 4G et 5G.

Le mécanisme de partage de spectre entre 5G et 6G, appelé MRSS (Multi-RAT Spectrum Sharing), devra donc fonctionner sur des bandes plus étroites et déjà utilisées. Une porteuse partagée pourrait, par exemple, disposer d’une largeur totale de l’ordre de 10 à 100 MHz, dont seule une partie serait dynamiquement attribuée à la 6G en fonction de la charge du réseau 5G.

Pour atteindre les capacités attendues de la 6G, cette porteuse partagée en FR1 pourra être complétée par d’autres porteuses 6G situées en FR2 ou FR3 grâce à la Carrier Aggregation (CA).

La porteuse MRSS en FR1 joue alors principalement le rôle d’ancre de couverture, tandis que les porteuses situées dans les bandes de fréquences plus élevées apportent la capacité supplémentaire.

CBW — Channel Bandwidth
Le CBW correspond à la largeur totale de spectre allouée à une porteuse radio. Il est exprimé en MHz.

Quelques définitions 3GPP

Les spécifications 3GPP distinguent plusieurs notions qu’il est utile de ne pas confondre :

Channel Bandwidth (CBW) : largeur nominale totale du canal radio ;
Transmission Bandwidth (TBW) : largeur effectivement occupée par les Resource Blocks actifs ; elle peut donc être inférieure au CBW ;
Occupied Bandwidth : largeur spectrale réellement occupée par le signal, en tenant compte de la signalisation ;
RF Bandwidth : largeur de bande considérée du point de vue de la chaîne RF et de l’antenne, incluant les bandes de garde.

En 4G, le standard propose différentes largeurs de bande : 1,4 MHz, 3 MHz, 5 MHz, 10 MHz, 15 MHz et 20 MHz. Les plus petites largeurs ont facilité le refarming des anciennes bandes 3G. Une bande de 5 MHz précédemment utilisée en 3G peut ainsi être réaffectée à la 4G.

Chaque transition entre deux générations de réseaux mobiles soulève donc la même question fondamentale :

que faire du spectre déjà occupé par la génération précédente ?

Pour le passage de la 4G à la 5G, le 3GPP a introduit le Dynamic Spectrum Sharing (DSS), utilisé sur des porteuses dans les bandes 700 MHz et 2100 MHz.

Pour préparer la transition de la 5G vers la 6G, une approche plus ambitieuse est désormais étudiée : le Multi-RAT Spectrum Sharing (MRSS).

Cet article présente ces deux mécanismes et montre comment un principe introduit avec la 5G, le lean carrier (porteuse maigre), pourrait considérablement faciliter la coexistence entre les réseaux 5G et 6G.

1. Le Dynamic Spectrum Sharing (DSS)

1.1 Contexte et motivation

Le spectre disponible dans les bandes de fréquences basses étant déjà fortement occupé, l’augmentation des débits nécessite d’exploiter des fréquences plus élevées, où des largeurs de bande plus importantes peuvent être attribuées aux opérateurs.

En France, la 5G NR (New Radio) a ainsi été déployée dans la bande des 3,5 GHz. Selon les opérateurs, des largeurs de bande de 70 MHz, 80 MHz ou 90 MHz ont été attribuées afin d’augmenter les débits disponibles. Les ressources radio étant partagées entre les utilisateurs, chacun bénéficie d’une partie de cette bande en fonction de la charge du réseau et des décisions du scheduler.

Cette montée en fréquence présente cependant un inconvénient majeur : plus la fréquence porteuse augmente, plus les pertes de propagation deviennent importantes.

Cette contrainte est particulièrement sensible dans les zones rurales. La densité de population y étant plus faible qu’en ville, les stations de base sont moins nombreuses et donc plus espacées. Une couverture reposant uniquement sur la bande des 3,5 GHz nécessiterait alors un nombre de sites beaucoup plus important pour obtenir une qualité de service comparable à celle offerte par les bandes basses. En effet, pour couvrir l’ensemble du territoire français en 5G uniquement à 3,5 GHz il faudrait installer entre 5 à 25 fois plus de sites comparativement à une couverture à 700 MHz. Un tel déploiement représenterait un investissement considérable et demanderait de nombreuses années pour couvrir tout le territoire.

Une solution consiste donc à réutiliser les bandes de fréquences basses déjà exploitées par la 4G. Mais attendre le refarming complet du spectre LTE aurait retardé de plusieurs années le déploiement de la 5G.

C’est précisément pour répondre à cette difficulté que le Dynamic Spectrum Sharing (DSS) a été proposé en 2021.

Le DSS permet à LTE et à la 5G NR de coexister dynamiquement sur une même porteuse, les ressources radio étant réparties entre les deux technologies en fonction de la demande de trafic.

Les bandes NR correspondant à plusieurs bandes LTE de fréquences relativement basses sont définies dans la spécification 3GPP TS 38.101-1. On peut citer :

n28 (700 MHz), correspondant à la bande LTE B28 ;
n1 (2100 MHz), correspondant à la bande LTE B1 ;
n3 (1800 MHz), correspondant à la bande LTE B3.

En France, le DSS a été déployé dans les bandes n1 et n28.

À noter toutefois qu’une porteuse déclarée en NR dans une bande historiquement utilisée pour le DSS n’est pas nécessairement partagée simultanément avec LTE. En France, Orange exploite par exemple de la 5G à 700 MHz sans coexistence 4G sur la même porteuse : la 5G peut alors disposer de l’intégralité de la bande disponible, même si celle-ci reste relativement étroite, de l’ordre de 10 MHz.

1.2 Le problème central : les CRS LTE

À première vue, le principe du DSS semble simple : lorsque des ressources ne sont pas utilisées par la 4G, il suffirait de les attribuer à la 5G.

En pratique, la coexistence LTE/NR est beaucoup plus complexe.

La principale difficulté vient de la conception même de l’interface radio LTE. Le réseau LTE émet en permanence des Cell-specific Reference Signals (CRS). Ces signaux de référence occupent des positions temps-fréquence fixes et prévisibles dans les ressources radio, indépendamment de la présence ou non de données utilisateur à transmettre.

Le Feature group FG 5-28 « Rate matching » est une fonctionnalité décrité par la 3GPP TS 38.822 et spécifique au LTE CRS

Autrement dit, même lorsqu’une cellule LTE transporte peu de trafic, certaines ressources restent occupées par ces signaux.

Ce fonctionnement « always-on » des CRS pose plusieurs problèmes pour la coexistence avec NR :

les ressources occupées par les CRS LTE ne peuvent pas être utilisées directement par NR pour transmettre des données ;
un UE NR doit connaître la position de ces Resource Elements (RE) afin de ne pas tenter d’y décoder des données NR ;
les CRS génèrent également des interférences intercellulaires permanentes, même lorsqu’aucune donnée utilisateur LTE n’est transmise.

Le DSS doit donc permettre à la 5G NR de s’insérer dans une structure LTE qui n’avait initialement pas été conçue pour accueillir une nouvelle technologie radio.

1.3 Les trois mécanismes techniques du DSS

Le 3GPP a défini plusieurs mécanismes permettant à NR d’utiliser les ressources d’une porteuse LTE tout en évitant les collisions avec les signaux LTE.

Option 1 — Utilisation des sous-trames MBSFN

Le mécanisme MBSFN (Multimedia Broadcast Single Frequency Network) avait initialement été introduit en LTE, dès la Release 9, pour permettre la diffusion de contenus multicast.

Dans une sous-trame configurée en MBSFN, les CRS LTE sont principalement concentrés au début de la sous-trame. Une grande partie des symboles suivants peut alors être libérée du point de vue LTE et utilisée par NR pour ses propres transmissions, pour certaines transmissions liées au SSB (Synchronization Signal Block).

Cette solution présente toutefois une limitation : le nombre de sous-trames pouvant être configurées en MBSFN dans une trame LTE est limité. Une partie des sous-trames doit donc conserver la structure LTE normale avec ses CRS.

Option 2 — Scheduling en mini-slots

NR offre davantage de flexibilité temporelle que LTE grâce à la possibilité de transmettre sur des mini-slots, constitués de 2, 4 ou 7 symboles OFDM.

Le scheduler peut ainsi positionner une transmission NR de manière à éviter certains symboles occupés par les CRS LTE.

Cette approche offre une grande souplesse, mais elle entraîne également un overhead supplémentaire : les blocs de transport sont plus courts et des signaux de référence additionnels peuvent être nécessaires. Elle est donc moins adaptée aux transmissions eMBB lorsque l’objectif principal est de maximiser le débit.

Option 3 — Rate matching autour des CRS

Pour les transmissions de données, l’une des solutions essentielles consiste à effectuer du rate matching autour des CRS LTE.

Le principe est particulièrement intéressant : plutôt que de chercher à supprimer ou à déplacer les CRS LTE, la 5G apprend simplement à les éviter.

Le réseau informe l’UE NR de la position des ressources occupées par les CRS LTE à l’aide de rate matching patterns, définis dans la TS 38.214 et configurés par RRC selon la TS 38.331.

L’UE NR considère alors les RE correspondants comme indisponibles et les exclut lors du décodage du PDSCH.

La 5G peut ainsi exploiter une grande partie d’une sous-trame LTE normale tout en « contournant » les ressources réservées aux CRS.

Pour permettre ce fonctionnement, le réseau doit fournir à l’UE NR plusieurs informations relatives à la porteuse LTE : sa fréquence, sa largeur de bande, la configuration MBSFN, le nombre de ports d’antenne utilisés pour les CRS ainsi que le paramètre vShift (dépendant du Physical Cell ID via vShift = CellRefP mod 6), qui détermine la position fréquentielle des CRS au sein de chaque bloc de ressources.

Une difficulté supplémentaire peut apparaître lorsqu’un DMRS additionnel NR entre en collision avec un CRS LTE. Des mécanismes permettent alors de modifier la position de ce DMRS afin d’éviter le conflit.

1.4 Les limites du DSS

Le DSS a permis d’accélérer le déploiement de la 5G dans des bandes déjà utilisées par LTE. L’expérience acquise avec les premiers réseaux a cependant mis en évidence plusieurs limitations structurelles.

La première concerne la perte de ressources radio. Une partie des RE reste réservée aux signaux LTE et ne peut donc pas être exploitée librement par NR. Avec plusieurs ports CRS LTE, cette perte peut devenir significative par rapport à une porteuse exclusivement 5G.

Le PDCCH LTE constitue une autre contrainte. Contrairement à NR, où les ressources de contrôle sont beaucoup plus configurables, le canal de contrôle LTE occupe les premiers symboles de chaque sous-trame. Cette structure réduit la flexibilité dont dispose le scheduler NR.

Les CRS sont également à l’origine d’interférences intercellulaires. Leur position pouvant varier d’une cellule à l’autre, la coexistence devient plus complexe dans un environnement multicellulaire.

Enfin, plusieurs mécanismes d’optimisation du DSS ont été introduits progressivement au fil des releases 3GPP, alors que les premiers réseaux DSS étaient déjà déployés.

Ces limitations ont mis en évidence un enseignement essentiel : plus une interface radio comporte de signaux permanents et de structures rigides, plus il est difficile de partager son spectre avec une nouvelle technologie.

Cette constatation permet précisément de comprendre pourquoi la transition 5G–6G pourrait être différente.

La 5G NR a en effet été conçue autour d’un principe absent de LTE : le lean carrier design.

Vous pouvez retrouver plus de détail à partir de l’article : 5G – DSS – Partie 1

2. Le concept de « Lean Carrier » en 5G NR

Les difficultés rencontrées avec le DSS proviennent en grande partie de la structure même de l’interface radio LTE. Les CRS et certains canaux physiques sont transmis de manière régulière, voire permanente, ce qui laisse relativement peu de liberté lorsqu’une nouvelle technologie doit venir partager la même porteuse.

Cette problématique avait déjà été rencontrée lors de l’introduction de technologies comme LTE-M, qui devaient coexister avec les canaux physiques LTE existants.

Lors de la conception de la 5G NR, le 3GPP a donc cherché à adopter une approche différente : réduire autant que possible les transmissions permanentes et rendre les ressources radio plus flexibles. C’est le principe du lean carrier design.

Cette orientation apparaît dans les travaux du 3GPP RAN1 autour de la conception de NR, ainsi que dans le document R1-163105 — Overview of eMBB operation for NR access technology, présenté lors de la réunion RAN1 #84bis.

2.1 Définition

Un lean carrier peut être défini comme une porteuse radio conçue pour minimiser les transmissions always-on, c’est-à-dire les signaux transmis indépendamment de la présence effective de trafic.

L’objectif est simple : si aucune donnée n’a besoin d’être transmise, la station de base doit pouvoir réduire au maximum ses émissions radio.

Le principe retenu lors de la conception de NR consiste ainsi à maximiser les ressources temps-fréquence pouvant être utilisées de manière flexible — ou simplement laissées libres — tout en limitant les transmissions permanentes. Cette approche constitue une rupture importante avec LTE.

En LTE, la structure de la trame impose la présence régulière de plusieurs signaux, en particulier les CRS. Même lorsqu’aucune donnée utilisateur n’est transmise, la porteuse n’est donc jamais réellement « vide ».

Avec NR, l’objectif est au contraire de permettre à une partie beaucoup plus importante de la grille temps-fréquence de rester inutilisée lorsqu’elle n’est pas nécessaire.

2.2 Comment la 5G NR applique le principe lean

La 5G NR met en œuvre ce principe de plusieurs manières.

Suppression des CRS : contrairement à LTE, NR n’utilise plus de Cell-specific Reference Signals transmis en permanence. Les transmissions de données utilisent des DMRS (Demodulation Reference Signals), associés aux transmissions effectivement planifiées, tandis que les CSI-RS sont configurables.
SSB périodiques et configurables : les Synchronization Signal Blocks (SSB) ne sont pas transmis en permanence. Leur périodicité peut être configurée, ce qui libère des ressources entre deux transmissions.
Signaux de référence configurables : les CSI-RS, TRS (Tracking Reference Signals) ou PRS (Positioning Reference Signals) peuvent être configurés en fonction des besoins du réseau, plutôt que d’occuper systématiquement des positions fixes dans chaque trame.
Possibilité de mettre la station de base en sommeil : lorsque le trafic diminue, la réduction des transmissions permanentes permet à certains composants de la station de base d’entrer dans des modes de veille plus profonds, ce qui contribue à réduire sa consommation énergétique.

Le lean carrier design apporte ainsi un premier bénéfice évident : une meilleure efficacité énergétique du réseau.

Mais il présente également un second avantage, particulièrement important pour la transition vers la 6G.

Une porteuse 5G comportant beaucoup moins de transmissions permanentes offre davantage de ressources temps-fréquence susceptibles d’être laissées libres. Une future technologie radio peut donc plus facilement venir s’insérer dans ces espaces disponibles. C’est précisément ce qui différencie la transition 5G–6G de la transition LTE–5G.

Avec le DSS, la 5G devait apprendre à contourner les structures rigides du LTE, en particulier les CRS. Avec le MRSS, la 6G pourra au contraire s’appuyer sur une interface 5G NR qui a été conçue dès l’origine pour être beaucoup plus flexible.

On peut résumer cette évolution de la manière suivante :

LTE : « j’émets certains signaux même lorsque je n’ai rien à transmettre »

5G NR : « si une ressource n’est pas nécessaire, je peux la laisser libre »

Cette différence constitue l’une des clés du futur Multi-RAT Spectrum Sharing (MRSS) entre la 5G et la 6G.

3. Le Multi-RAT Spectrum Sharing (MRSS)

3.1 Statut au 3GPP

Le MRSS s’inscrit actuellement dans les travaux préparatoires à la 6G menés au sein du 3GPP.

La Release 20 correspond à une phase d’étude au cours de laquelle différentes solutions techniques sont évaluées. Lors des réunions plénières du 3GPP organisées à Prague en juin 2025, TSG RAN #108 et TSG SA #108, le processus d’étude de la future interface radio 6G a été engagé.

Le calendrier indicatif peut être résumé ainsi :

2025–2027 : études techniques dans le cadre de la Release 20 ;
2027–2029 : premières spécifications normatives 6G attendues dans le cadre de la Release 21 ;
autour de 2030 : premiers déploiements commerciaux 6G envisagés.

À ce stade, le MRSS n’est donc pas encore décrit par une spécification technique définitive.

Les principes présentés dans la suite de cet article correspondent aux orientations actuellement étudiées au 3GPP et dans les travaux industriels associés. Ils sont donc susceptibles d’évoluer au cours du processus de standardisation.

Le document TR 38.914 V20.0.0 (approuvé juin 2026, Release 20) pose explicitement l’exigence suivante : :

« The 6G RAN shall support Multi-RAT Spectrum Sharing between 6GR and NR. »

Le principe du partage de spectre entre NR et la future 6G est donc bien posé, même si les mécanismes précis permettant de le mettre en œuvre restent en cours d’étude.

3.2 Principes techniques du MRSS

Plusieurs principes se dégagent déjà pour permettre à la 5G et à la 6G de partager efficacement une même porteuse.

A ce jour, je ne peux identifier que des pistes d’études. Il faudra attendre les spécifications R.21 pour affirmer ces pistes.

Scheduling coordonné

Comme dans le DSS, le partage ne doit pas conduire à découper définitivement la bande en une partie 5G et une partie 6G.

L’objectif est au contraire de conserver un partage dynamique des ressources.

Lorsque le trafic 5G est faible, une plus grande partie des ressources peut être attribuée à la 6G. Inversement, lorsque la charge 5G augmente, celle-ci doit pouvoir récupérer davantage de ressources.

Cette approche nécessite une coordination étroite des schedulers 5G et 6G au sein de la station de base multi-standard, avec une allocation pouvant évoluer à l’échelle du slot.

Invisibilité des signaux 6G pour les UE 5G

Une autre contrainte fondamentale concerne les terminaux 5G déjà déployés.

Un UE 5G NR existant n’a pas été conçu pour interpréter les futurs signaux radio 6G. Le réseau doit donc garantir que l’introduction de la 6G sur une porteuse partagée ne perturbe pas son fonctionnement.

Les signaux 6G devront ainsi être placés dans des ressources compatibles avec le fonctionnement des UE 5G existants.

Cela concerne le futur SSB 6G (Synchronization Signal Block), dont la structure précise n’est pas encore finalisée. Une possibilité consiste à utiliser des occasions de transmission laissées libres par les SSB NR ; une autre consiste à réserver des ressources sur lesquelles aucune transmission NR destinée aux UE 5G n’est planifiée.

Le principe général est donc le suivant :

la 6G doit pouvoir utiliser la porteuse partagée sans nécessiter de modification des terminaux 5G déjà en service.

Cohérence temporelle, numérologie et structure de trame

Un partage dynamique efficace suppose également une forte cohérence entre les structures radio 5G et 6G.

Lorsque les deux RAT utilisent simultanément une même porteuse, leurs transmissions doivent pouvoir être positionnées précisément dans la grille temps-fréquence sans créer de collisions inutiles.

Cela implique une compatibilité suffisante en matière de timing, de numérologie et de structure de trame.

Ces contraintes dépassent le seul mécanisme MRSS : elles participent plus largement à la conception d’une radio multi-standard capable de faire coexister plusieurs générations de réseaux.

Nous reviendrons plus précisément sur ces mécanismes dans la section 4.

3.5 Bandes cibles et lien avec la Carrier Aggregation

L’un des principaux intérêts du MRSS concerne les bandes FR1, qui restent essentielles pour assurer la couverture.

Une porteuse MRSS située en FR1 peut ainsi jouer le rôle d’ancre de couverture 6G, tout en partageant le spectre avec la 5G.

Mais les performances attendues de la 6G nécessiteront également des largeurs de bande beaucoup plus importantes, disponibles dans les bandes de fréquences supérieures.

Le MRSS doit donc être considéré en complément de la Carrier Aggregation (CA).

Le principe peut être représenté simplement :

porteuse MRSS en FR1 → couverture

porteuses 6G en FR3/FR2 → capacité

La porteuse FR1 permet ainsi de maintenir une couverture étendue, tandis que des porteuses 6G disposant de bandes passantes beaucoup plus importantes peuvent apporter les débits supplémentaires.

C’est pourquoi le MRSS et la Carrier Aggregation constituent deux mécanismes étroitement liés dans la réflexion sur le déploiement de la 6G.

3.6 Coexistence avec NB-IoT et LTE-M

Une dernière difficulté concerne les technologies IoT déjà déployées dans certaines bandes basses, NB-IoT et LTE-M.

Ces équipements présentent des cycles de vie particulièrement longs. Certains terminaux installés aujourd’hui peuvent rester en service pendant dix à quinze ans, voire davantage.

Lors de l’arrivée de la 6G, une partie de ces équipements sera donc probablement encore active. Cette coexistence doit toutefois être considérée comme une contrainte de déploiement plutôt que comme la motivation principale du MRSS.

Dans certains marchés, les technologies NB-IoT ou LTE-M pourront continuer à utiliser des ressources LTE spécifiques, tandis que le partage MRSS entre 5G et 6G sera déployé sur d’autres bandes.

En Europe, certaines bandes sub-GHz pourraient ainsi continuer à accueillir des services LTE et IoT pendant une période prolongée, tandis que le MRSS serait privilégié dans des bandes FR1 plus élevées.

Dans les situations où NB-IoT ou LTE-M doivent néanmoins coexister avec NR et la 6G sur une même bande, des ressources pourront être protégées ou configurées de manière semi-statique afin de garantir le fonctionnement des terminaux existants.

3.7 La migration vers la 6G

Lors du passage de la 4G à la 5G, plusieurs architectures de migration avaient été définies. En pratique, deux approches se sont principalement imposées : la 5G NSA, reposant sur le cœur EPC de la 4G et sur une Dual Connectivity LTE–NR, puis la 5G SA reposant sur le nouveau 5G Core. Cette multiplication des options a cependant contribué à complexifier la transition vers une architecture 5G complète.

Pour la 6G, les opérateurs souhaitent donc éviter de reproduire cette situation. L’objectif est de réduire rapidement le nombre d’architectures de migration possibles, avec le MRSS comme solution de référence.

Le premier objectif est de permettre une introduction progressive de la 6G sans attendre la libération du spectre 5G. Une partie des ressources peut progressivement être transférée vers les utilisateurs 6G à mesure que leur nombre augmente.

Le deuxième objectif est de préserver les performances de la 5G. L’introduction de la 6G ne doit pas conduire à une dégradation importante du débit ou de l’expérience des utilisateurs 5G existants. Inversement, les premiers utilisateurs 6G doivent bénéficier d’un gain suffisamment tangible pour justifier l’introduction d’une nouvelle génération.

Le troisième objectif est de réduire l’overhead du partage de spectre. C’est l’un des enseignements majeurs du DSS. NGMN insiste sur la nécessité de partager finement les ressources associées aux canaux de contrôle : réserver systématiquement un symbole par slot au PDCCH de chaque technologie serait particulièrement coûteux lorsque le MRSS est utilisé sur plusieurs bandes.

Le FG 5-26 « Semi-static rate-matching resource set configuration for DL « est une fonctionnalité qui permet de configurer semi-statiquement des ressources que le PDSCH ne doit pas utiliser. La configuration peut s’appuyer sur des bitmaps temps/fréquence utilisé par les CORESET 5G. L’objectif est d’informer le terminal « Dans cette grille temps-fréquence, certaines ressources sont réservées à une autre transmission : ne considère pas ces RE/RB comme disponibles pour ton PDSCH. »

Le quatrième objectif concerne les ressources de calcul de la station de base. Contrairement à certaines implémentations DSS où les ressources baseband 4G et 5G doivent être dimensionnées séparément, la 3GPP envisage un partage dynamique des ressources de traitement entre 5G et 6G. L’objectif est à la fois de réduire les besoins matériels, la consommation énergétique et de permettre aux ressources de calcul de suivre dynamiquement la répartition du trafic entre les deux RAT.

Enfin, le MRSS doit fonctionner aussi bien sur des porteuses FDD que TDD et être associé dès le départ à des mécanismes avancés de Carrier Aggregation, afin qu’un terminal 6G puisse agréger plusieurs porteuses partagées ou dédiées.

4. Fonctionnement technique du MRSS

Sources : Stefan Parkvall & Zhou Du, Ericsson Blog, avril 2026 ; Xingqin Lin, arXiv:2604.26853, avril 2026

Le principe général du MRSS est désormais posé : permettre à la 5G et à la 6G de partager une même porteuse tout en conservant une allocation dynamique des ressources.

Sa mise en œuvre soulève cependant plusieurs difficultés. Pour que ce partage soit efficace, les deux technologies doivent disposer de structures temps-fréquence compatibles, coordonner leur scheduling et éviter que les nouveaux signaux 6G ne perturbent les terminaux 5G existants.

4.1 Alignement de la forme d’onde et de la numérologie

La première condition nécessaire au MRSS concerne la cohérence de la structure temps-fréquence entre la 5G et la 6G.

Les solutions actuellement envisagées reposent sur une continuité avec la famille de formes d’onde OFDM utilisée en 5G NR. Pour permettre un partage efficace, les sous-porteuses des deux RAT doivent pouvoir être suffisamment alignées et leurs espacements de sous-porteuses (SubCarrier Spacing, SCS) compatibles.

Cet alignement est essentiel.

L’expérience du DSS LTE-NR a montré que le partage de spectre devient beaucoup plus complexe lorsque les grilles temps-fréquence des deux technologies ne coïncident pas correctement. Certaines solutions de coexistence LTE-NR étaient ainsi particulièrement adaptées à un SCS de 15 kHz, pour lequel les structures LTE et NR pouvaient naturellement s’aligner.

Lorsque les numérologies divergent, il devient au contraire nécessaire de réserver ou d’éviter davantage de ressources, ce qui augmente l’overhead lié à la coexistence.

Le MRSS cherche donc à tirer une leçon importante du DSS :

plus les grilles temps-fréquence des deux RAT sont compatibles, plus le partage des ressources peut être fin et dynamique.

Si les transmissions 5G et 6G peuvent être alignées au niveau des symboles et des blocs de ressources, le scheduler dispose d’une plus grande liberté pour attribuer les ressources à l’une ou l’autre technologie.

Cette compatibilité concerne également le positionnement des porteuses dans le spectre. Ces contraintes concernent : (1) le channel raster (positionnement des porteuses, typiquement multiples de 100 kHz), (2) la synchronization raster (positionnement du SSB), et (3) la grille de Resource Blocks commune (CRB grid), qui doivent tous rester compatibles entre NR et 6G

L’objectif n’est donc pas seulement de faire coexister deux formes d’onde, mais de concevoir dès l’origine la grille radio 6G de manière à faciliter son partage avec NR.

4.2 Scheduling dynamique partagé

Le deuxième pilier du MRSS est le scheduling dynamique des ressources entre 5G et 6G.

L’objectif n’est pas de réserver, par exemple, une moitié de la bande à la 5G et l’autre moitié à la 6G. Une telle répartition serait simple à mettre en œuvre, mais elle conduirait à gaspiller du spectre dès que l’un des deux RAT présente une faible charge.

Le principe recherché est beaucoup plus dynamique.

Lorsque le trafic 5G diminue, la 6G doit pouvoir récupérer une grande partie des ressources disponibles. Inversement, une augmentation de la charge 5G doit permettre à NR de disposer à nouveau d’une part plus importante de la bande.

Cette coordination peut s’effectuer à une échelle temporelle fine, potentiellement à l’échelle du slot. À titre de référence, avec une numérologie NR μ = 0, un slot dure 1 ms.

On peut alors distinguer trois grandes catégories de ressources sur une porteuse MRSS :

Shared data pool : ensemble des ressources de données pouvant être attribuées dynamiquement à la 5G ou à la 6G. Dans un MRSS efficace, cette zone doit représenter la majeure partie des ressources disponibles ;
Reserved / protected resources : ressources nécessaires à certaines fonctions telles que la synchronisation ou l’accès initial. Elles ne peuvent pas toujours être réaffectées dynamiquement et doivent donc rester aussi limitées et configurables que possible ;
Control coexistence region : ressources utilisées par les canaux de contrôle. Selon les choix finalement retenus, les régions de contrôle 5G et 6G pourraient être séparées, partiellement superposées ou davantage mutualisées.

Le fonctionnement du MRSS repose ainsi sur une combinaison de deux niveaux de coordination : une configuration semi-statique minimale pour les ressources qui doivent rester protégées et une allocation dynamique pour la majorité des ressources de données.

L’objectif est de réduire autant que possible la première catégorie afin de maximiser la seconde.

4.3 Synchronisation et accès initial : rendre le SSB 6G compatible avec les UE 5G

L’accès initial constitue l’une des difficultés particulières du MRSS.

Les données utilisateur peuvent être positionnées dynamiquement par le scheduler. En revanche, les fonctions permettant à un terminal de découvrir une cellule, de se synchroniser avec elle et d’obtenir les premières informations système doivent être accessibles à des instants et sur des ressources suffisamment prévisibles.

En 5G NR, une partie de ces fonctions repose sur le SSB (Synchronization Signal Block).

La future 6G devra disposer de mécanismes équivalents, mais leur présence sur une porteuse MRSS ne devra pas perturber les UE 5G existants. Ces terminaux ont été conçus avant la définition de la 6G et ne pourront donc pas être modifiés pour interpréter les nouveaux signaux.

Le principe recherché consiste ainsi à rendre les transmissions nécessaires à l’accès initial 6G compatibles avec le comportement des terminaux 5G existants.

Plusieurs approches peuvent être envisagées. Une possibilité consiste à exploiter des occasions de transmission qui ne sont pas utilisées par les SSB 5G. Une autre consiste à protéger les ressources occupées par le signal de synchronisation 6G en évitant d’y programmer simultanément des transmissions NR incompatibles.

Un raisonnement similaire peut s’appliquer aux informations système et au paging 6G.

L’enjeu est donc de maintenir une empreinte temps-fréquence aussi faible et prévisible que possible pour ces nouveaux signaux afin de limiter l’overhead introduit par la coexistence.

4.4 Multiplexage du canal de contrôle PDCCH

Le partage des canaux de contrôle descendants constitue probablement l’un des enjeux les plus importants du MRSS.

En effet, le partage dynamique des données n’est réellement efficace que si les ressources nécessaires au contrôle peuvent elles aussi être organisées avec suffisamment de souplesse.

L’expérience du DSS est à nouveau instructive. En LTE, le PDCCH occupe toujours les premiers symboles de chaque sous-trame (1 à 3 symboles selon le Control Format Indicator — CFI), ce qui laisse peu de flexibilité au scheduler.

La 5G NR apporte une différence essentielle : le PDCCH est transmis dans des CORESET (Control Resource Sets) configurables.

Cette configurabilité ouvre plusieurs possibilités pour le MRSS. Les régions de contrôle 5G et 6G pourraient être :

séparées ;
partiellement superposées ;
ou, si la conception finale de la 6G le permet, davantage mutualisées.

La dernière solution serait particulièrement intéressante du point de vue de l’efficacité spectrale, puisqu’elle limiterait la quantité de ressources devant être réservées séparément aux deux technologies.

L’importance de cette question apparaît lorsque l’on examine l’overhead des différents signaux de contrôle et de référence.

Dans le scénario étudié dans les travaux cités — porteuse NR TDD de 100 MHz, structure DDDSU et SCS de 30 kHz — le PDCCH représente une part très importante de l’overhead descendant : environ 88,5 % de l’overhead considéré, soit approximativement 11,3 % de l’ensemble des Resource Elements. Les autres composantes étudiées, telles que SSB, CSI-RS et TRS, représentent une part beaucoup plus faible de cet overhead.

Ces valeurs dépendent naturellement du scénario et de la configuration retenus. Elles montrent néanmoins pourquoi l’optimisation du canal de contrôle constitue un enjeu majeur du MRSS.

Un partage efficace des données ne suffirait pas si chaque RAT devait conserver en parallèle une importante région de contrôle réservée.

4.5 Connaissance des signaux 5G par les UE 6G

La dernière composante du MRSS concerne la manière dont les futurs terminaux 6G pourront prendre en compte les signaux 5G présents sur la porteuse partagée.

La situation est ici asymétrique.

Les UE 5G déjà déployés ne connaissent pas la 6G et doivent continuer à fonctionner sans modification. En revanche, les futurs UE 6G pourront être conçus dès l’origine pour connaître l’existence de NR.

Un UE 6G opérant sur une porteuse MRSS pourra donc être informé de la présence et de la position de certaines structures 5G, telles que les SSB, les CSI-RS ou certaines ressources de contrôle.

Plusieurs mécanismes peuvent alors être envisagés.

Le premier est le rate matching. Les Resource Elements correspondant à des structures 5G connues peuvent être signalés comme indisponibles pour une transmission 6G. Le principe rappelle directement le mécanisme utilisé en DSS pour permettre à NR d’éviter les CRS LTE.

Le deuxième repose sur le scheduling coordonné. La station de base connaissant à la fois les transmissions 5G et 6G peut organiser leur allocation afin d’éviter dynamiquement les collisions.

Enfin, certaines situations pourraient être traitées par des mécanismes de mitigation des interférences côté récepteur, par exemple grâce à des techniques d’annulation d’interférence.

L’expérience du DSS incite cependant à ne pas faire reposer l’ensemble de la coexistence sur la seule capacité du récepteur à éliminer les interférences.

Une coexistence efficace doit avant tout être prise en compte dans la conception même du système et dans les mécanismes de scheduling.

C’est probablement l’une des différences fondamentales entre DSS et MRSS :

dans le DSS, la 5G a dû apprendre à coexister avec une technologie LTE qui n’avait pas été conçue pour elle ; dans le MRSS, la 6G peut être conçue dès l’origine pour coexister avec la 5G.

5. DSS vs MRSS : tableau comparatif

Le DSS et le MRSS répondent finalement à une problématique similaire : introduire une nouvelle génération de réseau mobile dans un spectre déjà occupé par la génération précédente.

La différence essentielle réside dans la conception de la technologie déjà en place. Dans le DSS, la 5G doit composer avec une interface LTE comportant de nombreuses structures fixes et des signaux always-on. Dans le MRSS, la 6G pourra s’appuyer sur une interface 5G NR beaucoup plus flexible et configurable.

Le tableau suivant résume les principales différences entre les deux approches.

Critère	DSS (LTE–NR)	MRSS (NR–6G)
Technologie déjà déployée	LTE, avec CRS always-on	5G NR, lean et configurable
Principe de coexistence	MBSFN, rate matching autour des CRS, mini-slots	Scheduling coordonné et protection des ressources nécessaires aux deux RAT
Flexibilité du partage	Limitée par les structures LTE	Potentiellement beaucoup plus élevée grâce au lean carrier design
Perte de ressources	Peut être importante, en présence de plusieurs ports CRS	Attendue plus faible grâce à l’absence de CRS permanents
Canal de contrôle	PDCCH LTE relativement rigide	CORESET NR configurable ; mécanismes 6G encore à définir
Terminaux existants	Les UE NR doivent connaître les ressources LTE à éviter	Les UE 5G doivent continuer à fonctionner sans modification ; les UE 6G pourront être conçus pour tenir compte de NR
Standardisation 3GPP	Spécifié depuis la Release 15 (2019), avec enhancements en Rel-16 et ultérieures	En cours d’étude dans le cadre des travaux 6G
Bandes d’intérêt	Principalement bandes FR1 déjà utilisées par LTE	FR1 pour la couverture, en complément de porteuses 6G en FR3/FR2
Technologies IoT existantes	Coexistence avec NB-IoT/LTE-M dans l’écosystème LTE	Coexistence à prendre en compte selon les bandes et les scénarios de déploiement

Le passage du DSS au MRSS traduit donc une évolution importante de la philosophie du partage de spectre.

Avec le DSS, la nouvelle technologie doit principalement s’adapter aux contraintes de l’ancienne.

Avec le MRSS, l’objectif est davantage de concevoir la nouvelle technologie pour qu’elle puisse partager efficacement le spectre avec celle qui la précède.

6 Les solutions de migration vers la 6G

Le MRSS n’est cependant pas la seule architecture de migration envisagée.

Deux autres familles de solutions sont discutées : la Dual Connectivity (DC) et les architectures Dual Stack.

Avec la Dual Connectivity, le terminal peut maintenir simultanément des connexions radio avec deux systèmes d’accès. Le principe rappelle l’approche utilisée lors du déploiement initial de la 5G NSA, où LTE et NR étaient utilisés conjointement. Appliquée à la transition 5G–6G, une telle architecture pourrait permettre d’utiliser simultanément des ressources 5G et 6G sans imposer nécessairement un partage aussi généralisé du spectre.

Une architecture Dual Stack consiste davantage à faire coexister deux piles technologiques, 5G et 6G, permettant au réseau et aux terminaux de prendre en charge les deux systèmes pendant la période de transition.

Ces approches peuvent réduire la quantité de spectre devant être exploitée en MRSS. Elles introduisent cependant une complexité supplémentaire dans les terminaux, le RAN ou le cœur de réseau.

Le MRSS devrait constituer la solution de migration de référence, tandis que la Dual Connectivity ou le Dual Stack ne devraient être retenus que s’ils répondent à des scénarios de déploiement que le MRSS ne peut pas traiter efficacement

Conclusion

Le déploiement d’une nouvelle génération de réseau mobile ne dépend pas uniquement des performances de sa nouvelle interface radio. Il dépend également de sa capacité à s’intégrer dans un environnement spectral déjà largement occupé.

Lors du passage de la 4G à la 5G, le Dynamic Spectrum Sharing (DSS) a permis à LTE et NR de partager une même porteuse sans attendre le refarming complet des bandes 4G. Cette solution a facilité l’introduction de la 5G dans des bandes offrant une bonne couverture, mais elle a également mis en évidence les limites d’une coexistence avec une technologie qui n’avait pas été conçue pour partager son spectre avec une génération future.

Les CRS always-on, la structure relativement rigide du PDCCH LTE et certaines contraintes de la grille radio ont imposé à NR de contourner une partie des ressources LTE, au prix d’une perte d’efficacité spectrale.

La situation pourrait être sensiblement différente pour la transition de la 5G vers la 6G.

La 5G NR repose en effet sur le principe du lean carrier design : les transmissions permanentes sont réduites et de nombreux signaux ou canaux sont configurables. Une plus grande partie de la grille temps-fréquence peut ainsi être utilisée dynamiquement ou laissée libre lorsqu’elle n’est pas nécessaire.

Le Multi-RAT Spectrum Sharing (MRSS) cherche à exploiter cette flexibilité pour permettre à la 5G et à la 6G de partager une même porteuse de manière plus efficace.

L’enjeu est particulièrement important dans les bandes FR1. Ces fréquences restent indispensables pour assurer une couverture étendue, mais elles seront encore largement utilisées par la 5G lors de l’arrivée de la 6G. Le MRSS pourrait permettre à une porteuse FR1 partagée de jouer le rôle d’ancre de couverture, tandis que la Carrier Aggregation avec des porteuses 6G plus larges en FR3 ou FR2 apporterait la capacité supplémentaire.

Le MRSS ne doit toutefois pas être considéré comme une technologie déjà figée. Les mécanismes précis de coexistence, le partage des canaux de contrôle, la structure des futurs signaux 6G ou encore les modalités de coordination avec NR font encore partie des travaux de standardisation.

La Release 20 constitue une étape d’étude de ces mécanismes, avant les premières spécifications normatives de la 6G attendues dans la Release 21.

Au-delà des solutions techniques qui seront finalement retenues, l’expérience du DSS aura donc apporté une leçon importante pour la conception des réseaux mobiles :

préparer la coexistence avec la génération suivante dès la conception de l’interface radio permet de rendre les futures migrations de spectre beaucoup plus souples.

C’est précisément cette philosophie, amorcée avec le lean carrier design de la 5G NR, que le MRSS cherche aujourd’hui à prolonger pour préparer la transition vers la 6G.

Pour les opérateurs, une migration réussie vers la 6G devra également limiter les investissements matériels. L’un des enjeux sera donc de déterminer dans quelle mesure les équipements radio et baseband déployés avant l’arrivée de la 6G pourront être mis à niveau par logiciel.

Le véritable critère de succès ne sera ainsi pas seulement le débit maximal obtenu avec la 6G, mais le gain de performance obtenu par rapport à une évolution 5G-Advanced, rapporté au coût de la migration.

Références

[1] Xingqin Lin, « A 3GPP Perspective on Spectrum Sharing for the 5G-to-6G Migration: From DSS to MRSS », arXiv:2604.26853, avril 2026. https://arxiv.org/abs/2604.26853

[2] Ericsson, « Multi-RAT spectrum sharing and 5G–6G migration », Ericsson Technology Review, avril 2026. https://www.ericsson.com/en/blog/2026/4/5g-6g-spectrum-sharing-mrss

[3] Nokia, « Simplifying spectrum migration from 5G to 6G » (white paper MRSS), 2025. https://www.nokia.com/asset/213378/

[4] InterDigital, « Paving the Path to 6G: Key Takeaways for 3GPP Release 20 », juin 2025. https://www.interdigital.com/post/paving-the-path-to-6g-key-takeaways-for-3gpp-release-20

[5] Samsung, « Dynamic Spectrum Sharing Technical White Paper », 2021. https://images.samsung.com/is/content/samsung/assets/global/business/networks/insights/white-papers/0122_dynamic-spectrum-sharing/Dynamic-Spectrum-Sharing-Technical-White-Paper-Public.pdf

[6] Microwave Journal, « NR and LTE Coexistence Through Dynamic Spectrum Sharing », 2019. https://www.microwavejournal.com/articles/33239-nr-and-lte-coexistence-through-dynamic-spectrum-sharing

[7] 3GPP TS 38.214 v16+ — Physical layer procedures for data (rate matching patterns DSS).

[8] 3GPP TS 38.331 v16+ — NR Radio Resource Control (RRC) specification (DSS configuration parameters).

[9] 3GPP TS 38.133 v16+ — NR Requirements for support of radio resource management.

[10] Free 6G Training, « 3GPP Release 20 Sets the Stage for 6G », août 2025. https://www.free6gtraining.com/2025/08/3gpp-release-20-sets-stage-for-6g.html

[11] Three design principles of 5G New Radio, https://www.ericsson.com/en/blog/2017/8/three-design-principles-of-5g-new-radio

Réduire le PAPR en uplink 5G/6G : la solution FDSS

Posté le 7 septembre 2026 by flaunay - 108 vues

Répondre

1. L’amplification de puissance au niveau du smartphone

Dans un réseau cellulaire, le bilan de liaison montre que la transmission sur le lien montant est plus difficile à assurer par rapport à la transmission sur le lien descendant.

Une station de base dispose généralement d’une puissance d’émission, d’un gain d’antenne et de capacités de beamforming bien supérieurs à ceux d’un terminal mobile. L’UE est au contraire fortement contraint en puissance d’émission, en consommation énergétique et par les exigences RF. En bord de cellule, chaque décibel de puissance uplink devient donc précieux.

Avec l’augmentation de la fréquence, l’atténuation est encore plus élevée. La mise en oeuvre du Massive MIMO permet d’apporter une couverture dans une direction donnée et d’apporter un gain vers le récepteur.

Ou alors, une solution proposée en 5G est la transmission SUL : Supplementary UpLink. Le smartphone est contrôlé par la station de base pour émettre sur une fréquence montante plus basse que la liaison de service.

Quoi qu’il en soit, chaque décibel de puissance UL devient donc précieux, et augmenter simplement la puissance moyenne du signal n’est pas toujours possible.

La raison tient notamment au Peak-to-Average Power Ratio, ou PAPR c’est à dire la puissance maximale sur la puissance moyenne :

Le PAPR mesure l’écart entre la puissance instantanée maximale du signal et sa puissance moyenne. Si le signal possède des pics importants, l’amplificateur de puissance du terminal risque d’entrer dans sa région non linéaire.

Ce problème est connu depuis la 3G, avec des solutions de prédistorsion du signal. Pour la 4G, la solution proposée est l’étalement DFT-S-OFDM dont l’objectif est de rendre l’enveloppe du signal la plus constante possible avant amplification.

D’autres solutions sont possibles comme diminuer la puissance moyenne transmise. En pratique, on applique un power back-off ce qui pénalise la couverture.

L’étalement DFT-s-OFDM

Le principe consiste à ajouter une transformée de Fourier discrète (DFT) avant la modulation OFDM. La DFT répartit l’énergie de chaque symbole de modulation sur l’ensemble des sous-porteuses allouées.

Le signal résultant conserve donc la structure fréquentielle de l’OFDM mais présente en temporel un comportement plus proche d’un signal single-carrier (SC-FDMA proposée en 4G – Single Carrier FDMA et conservée en 5G/6G). Cette propriété permet ainsi d’obtenir un PAPR inférieur à celui du CP-OFDM.

Mais avec les constellations QAM classiques, le PAPR reste suffisamment important pour continuer à limiter la puissance moyenne de l’UE. L’article [1] propose d’agir sur la forme spectrale du signal.

3 – Frequency-Domain Spectral Shaping (FDSS)

La 3GPP s’est intéressée au problème dans le cadre des travaux Further NR coverage enhancements. Le FDSS présente une caractéristique particulièrement intéressante pour NR : l’implémentation exacte du shaping peut rester interne à l’UE.

Le Frequency-Domain Spectral Shaping (FDSS) consiste à appliquer des coefficients $W[k]$ aux composantes fréquentielles du signal DFT-s-OFDM. Il s’agit d’un fenêtrage (Windowing). Cette idée n’est pas nouvelle, le fenêtrage permet d’atténuer progressivement les composantes situées vers les bords du spectre (par exemple des solutions comme le FFT–FBMC ( Filter Bank Multi-Carrier). La solution FBMC a été proposée comme alternative dans plusieurs projets de recherche (5GNOW, PHYDYAS, etc.), cependant cette solution n’a pas été retenue par la 5G NR car :

Complexité accrue d’implémentation
Problèmes de synchronisation et de décodage de canal plus complexes
OFDM avec CP reste plus robuste et pratique pour les déploiements
Écosystème et compatibilité avec les équipements existants

Pourtant elle offrait théoriquement :

Meilleure localisation temps-fréquence
Pas de cyclic prefix (gain en efficacité spectrale)
Moins d’émission hors-bande

Conceptuellement, les méthodes FBMC et FDSS appliquent un filtrage fréquentiel par sous-porteuse, mais ces méthodes n’ont pas le même objectif : les objectifs du FDSS : Shaping/spreading pour réduire PAPR ou réduire les interférences. L’avantage du FDSS est que cette méthode est moins complexe que le FBMC.

4- Le prix du FDSS : les pulses ne sont plus parfaitement orthogonaux

La fenêtre FDSS $W[k]$ pondère les coefficients fréquentiels issus de la DFT avant leur mapping sur les sous-porteuses et l’IFFT. Sans shaping, lorsque $W[k]=1$ , les pulses temporels associés aux symboles sont orthogonaux. L’application d’une fenêtre FDSS modifie leur forme et introduit généralement un chevauchement et une auto-interférence contrôlée.

En reprenant l’article sur la modulation OTFS, vous verrez l’importance de l’orthogonalité. Dans le cas de la technique FDSS, la perte d’orthogonalité est inévitable.

AInsi, le rôle du FDSS est de réduire le PAPR et de manière complémentaire, on utilise la technique SE Spectrum evolution pour réduire d’avantage le PAPR. C’est une technique de pré-distorsion connue qui consiste à rajouter des sous-porteuses (se référer aux travaux du laboratoire XLIM avec M Duvanaud et M Bachir).

5. Spectrum Extension : ajouter des composantes fréquentielles redondantes

Supposons que l’on dispose de $Ndata$ coefficients issus de la DFT. Au lieu de les mapper sur exactement $Ndata$ sous-porteuses, on construit un signal occupant Nsc sous-porteuses, avec Nsc>Ndata.

Ainsi, Ne=Nsc−Ndata représente la taille du Spectrum Extension.

Les coefficients supplémentaires ne transportent pas de nouvelles données. Ils sont obtenus par extension périodique de la séquence DFT.

Chaîne de transmission FDSS

6) Pourquoi cela peut-il diminuer le PAPR ?

On rappelle que la multiplication dans le domaine fréquentiel se traduit par une convolution dans le domaine temporel. A titre d’exemple, le spectre Y(f) d’un signal X(f) en sortie d’un filtre H(f) s’écrit Y(f)=H(f).X(f). En temporel, on écrit la convolution du signal x(t) avec la fonction de transfert h(t) du filtre h, soit en discret :

Le signal discret à l’instant n, y[n] se calcule par le produit de x[m] avec le décalage du filtre n-m.

Le Spectrum Extension quant à lui rajoute un nombre de sous porteuses supplémentaires. On injecte les Ndata symboles sur Nsc sous porteuses avec un décalage optimisé de L sous porteuses. Ainsi le symbole de la 1ère sous-porteuses Ndata(1) sera transmis sur la sous porteuses L+1 Nsc(L). Ce décalage circulaire se traduit par une rotation de la phase. La valeur de L reste à optimiser pour réduire la PAPR.

Pourquoi cela agit-il sur le PAPR ? Les pulses ne sont pas parfaitement localisés à un seul instant : ils possèdent un lobe principal ainsi que des lobes secondaires. Plusieurs pulses peuvent donc contribuer simultanément au signal $s[n]$ . Si leurs contributions complexes sont en phase, elles s’additionnent constructivement et peuvent produire un pic important. Si leurs phases diffèrent, elles peuvent au contraire se compenser partiellement. Le Spectrum Extension modifie la forme et le chevauchement de ces pulses, tandis que le shift $L$ modifie leurs phases relatives. Ces deux paramètres peuvent ainsi être optimisés afin de réduire les pics du signal temporel.

Par conséquent, en intégrant la convolution (le décalage n-m) et la rotation circulaire dans ue fonction nommée pulse le signal de sortie peut s’écrire sous la forme suivant:

Le pulse subit un décalage temporel et une rotation de phase par rapport à un pulse de référence.

Le choix de L est de réduire le PAPR mais il dépend de la constellation puisque les symboles modulés disposent déjà d’une rotation particulière (par exemple modulation pi/2 BPSK).

Ainsi, le signal s’écrit comme une superposition de pulses temporels décalés (cf. article [1]).

Les auteurs avaient déjà proposé cette approche dans les contributions Huawei/HiSilicon :

R1-2208412, RAN1 AH 110bis-e, octobre 2022 ;
R1-2300090, RAN1 #113, mai 2023.

Mais, il existe enfin une discussion intéressante autour de la métrique elle-même.

Historiquement, la 3GPP utilise largement le Cubic Metric (CM) pour estimer le power de-rating nécessaire à un amplificateur.

Lorsque le shaping devient plus agressif :

le PAPR évolue de manière cohérente ;
le CM peut présenter une évolution non monotone, notamment pour QPSK

Or, la grandeur réellement pertinente pour la conformité RF du groupe de travail RAN4 et la puissance exploitable reste le power de-rating/MPR.

[1] Renaud-Alexandre Pitaval, Fredrik Berggren and Branislav M. Popovic, Optimum Spectrum Extension for PAPR Reduction of DFT-s-OFDM, https://arxiv.org/pdf/2509.19064v1

[2] 3GPP TR 38.830 V17.0.0 (2020-12)

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

Posté le 18 juin 2026 by flaunay - 216 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 16 mai 2026 by flaunay - 198 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 :

Pré-compensée par l’UE (Common TA/Doppler pre-compensation)
Compensée par le satellite (si régénératif)
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 :

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.
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.
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.
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 13 mai 2026 by flaunay - 275 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 :

Slot n : Transmission downlink du PDSCH
Slot n+k : Réception de l’ACK/NACK dans le PUCCH uplink
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 :

Calculé par l’UE (mode pré-compensé) en fonction des éphémérides et de sa position
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 :

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

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

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 12 mai 2026 by flaunay - 512 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)

Slot n : DDDDDDDDDDDDD (tout DL)
Slot n+1 : DDDSUUUUUUUUU (DL + spécial + UL)
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 :

Les éphémérides du satellite : Position et vitesse du satellite, diffusées dans les System Information Blocks (SIB19 selon TS 38.331)
Sa propre position GNSS : Latitude, longitude, altitude obtenues via GPS/Galileo/etc.
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 N_TA,common entre le point de référence et le satellite à l’instant tepoch
La vitesse N_{TA,commondrift} entre le point de référence et le satellite à l’instant tepoch
L’accélération N_{TA,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 (N_TA,common, N_{TA,commondrift,}N_{TA,commondriftvariation)}sont toutes égales à 0.

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

N_TA,adj^UE: 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
N_TA,adj^commonest 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).

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

Posté le 5 octobre 2025 by flaunay - 730 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