De l’application mobile à la session PDU : comprendre la connectivité et la QoS en 5G

1. Introduction : que se passe-t-il lorsque nous ouvrons une application ?

Lorsqu’un utilisateur installe une application depuis un store, il ne se préoccupe généralement pas de la manière dont son smartphone communiquera avec les serveurs de l’application. Pourtant, plusieurs mécanismes interviennent :

  1. sélection du réseau de données,
  2. établissement éventuel d’une session PDU,
  3. identification des flux applicatifs et application des règles de qualité de service.

En 5G, ces opérations sont dissociées. Une application n’a pas nécessairement besoin de sa propre session PDU, et une même session peut transporter plusieurs flux bénéficiant de traitements QoS différents.
Cette possibilité de différencier les traitements QoS existait déjà en 4G, où une connexion PDN pouvait comporter plusieurs EPS bearers. La principale évolution introduite par la 5G réside dans une séparation plus souple entre la connectivité, les flux QoS et les ressources de transport. Les QoS flows constituent désormais l’unité de différenciation QoS et peuvent être associés aux ressources radio indépendamment de leur identification au sein de la session PDU (En 4G, chaque EPS bearer est associé à un E-RAB lorsqu’il est établi sur l’accès LTE. En 5G, plusieurs QoS flows peuvent être associés à un même DRB et partager un tunnel N3).

Prenons le cas d’une application de télémédecine. Elle peut transporter de la vidéo, de l’audio et des données médicales. Ces trois types de trafic n’ont pas nécessairement les mêmes exigences : l’audio est sensible au délai, la vidéo nécessite un débit suffisant et le transfert d’un document peut généralement tolérer davantage de latence.

Une session PDU, plusieurs traitements QoS

Exemple sur l’application de télémédecine : Audio · Vidéo · Documents

Cet exemple illustre une possibilité du modèle 5G, et non un comportement automatique. Un opérateur peut parfaitement transporter ces trois trafics dans un seul flux QoS lorsque leurs exigences et sa politique le permettent.

2. De l’installation de l’application au choix de la session

2.1. Que se passe-t-il lors du téléchargement d’une application ?

Le téléchargement depuis un store utilise une session PDU donnant accès à Internet ou une connexion Wi-Fi déjà disponible.

Lorsque l’application s’installe, l’OS du terminal récupère l’identifiant de l’application.Pour l’application de télémédecine, on suppose l’identifiant de package : com.hopital.telemedecine. Celui-ci permet d’identifier l’application dans un store.

Toutefois, cet identifiant Android ne doit pas être confondu avec l’identifiant applicatif utilisé dans les politiques de routage définies par la 3GPP.

La 3GPP définit le couple OSId/OSAppId

  • OSId identifie le système d’exploitation selon un format UUID de 128 bits.
  • OSAppId identifie une application ou une catégorie reconnue par l’OS

La 3GPP laisse au système d’exploitation le soin de définir la signification des OSAppId. Un OSAppId peut désigner une application particulière, mais aussi une catégorie d’applications. L’OSAppID n’est pas obligatoirement attribuée à chaque application.

La correspondance entre l’identifiant de package Android et l’OSAppId dépend de l’implémentation du système d’exploitation. L’installation d’une application ne garantit donc pas qu’elle possède un OSAppId exploitable par les règles URSP.

Par exemple, dans une implémentation Android prenant en charge le découpage réseau, la catégorie ENTERPRISE va permettre d’identifier certains trafics professionnels. Plusieurs applications peuvent donc être associées au même OSAppId si elles le demandent et que l’OS l’y autorise ou si la MDM (Mobile Device Management) l’a placée dans un profil professionnel.

Cette identification peut ensuite être utilisée par les règles URSP pour sélectionner une session PDU adaptée au trafic applicatif, lorsque le terminal prend en charge ce mécanisme.

Figure 2 : Installation d’une application et ses identifiants

2.2 L’installation d’une application ne crée pas nécessairement une session

L’installation de l’application ne provoque pas, à elle seule, la création d’une session PDU spécifique. C’est lorsque l’application commence à utiliser le réseau que le terminal doit déterminer comment acheminer son trafic.

Il faut distinguer deux décisions :

  • La sélection de la route : quelle session PDU doit transporter le trafic ?
  • La classification QoS : quel traitement les paquets doivent-ils recevoir à l’intérieur de cette session ?

Ces décisions relèvent de mécanismes différents.

2.3. Les règles URSP – UE Route Selection Policy : sélectionner la route du trafic applicatif

Les UE Route Selection Policy (URSP), définies dans la TS 23.503, permettent de définir des politiques de routage applicatif dans le terminal.

Une règle URSP comprend un Traffic Descriptor, qui permet d’identifier le trafic concerné, et un ou plusieurs Route Selection Descriptors (RSD), qui décrivent les caractéristiques de la route recherchée.

Le Traffic Descriptor peut exploiter :

  • un identifiant applicatif reconnu par le terminal (exemple com.hopital.telemedecine)
  • des informations de destination IP, exemple l’adresse du serveur mail
  • un domaine ou une capacité de connexion.

Le Route Selection Descriptor (RSD) définit les caractéristiques de la session PDU recherchée. Il peut notamment préciser :

  • le DNN, qui identifie le réseau de données ;
  • le S-NSSAI, qui identifie la tranche réseau ;
  • le type de session PDU (IPv4, IPv6, IPv4v6, Ethernet ou Unstructured) ;
  • le mode SSC, qui définit les modalités de continuité de la session ;
  • les préférences d’accès (3GPP, non-3GPP ou multi-accès).

Le terminal recherche alors une session PDU existante compatible avec le RSD retenu. S’il en trouve une, il peut la réutiliser ; sinon, il peut tenter d’en établir une nouvelle.

Figure 3 : Correspondance entre application et les règles de trafic

Si un paramètre n’est pas précisé dans le RSD, la session va s’établir avec les informations de configuration ou des valeurs par défaut du terminal.

L’opérateur fournit les règles URSP au terminal selon l’une des 3 manières suivantes :

  1. Par le PCF : les règles sont transmises dynamiquement au terminal par la signalisation du réseau 5G, via l’AMF.
  2. Par l’USIM : les règles sont préconfigurées dans la carte SIM de l’opérateur.
  3. Par le terminal (ME, Mobile Equipment) : les règles sont préconfigurées dans le terminal, par exemple au moyen d’une configuration logicielle de l’opérateur.

Ces trois méthodes ne sont pas équivalentes. La 3GPP définit l’ordre de priorité indiqué par la numérotation ci-dessus :

  1. Règles fournies par le PCF prévalent sur les règles préconfigurées.
  2. Règles préconfigurées dans l’USIM sont utilisées en l’absence de règles fournies par le PCF
  3. Règles préconfigurées dans le terminal (ME) sont utilisées lorsqu’aucune des deux sources précédentes ne fournit de règles applicables.

Leur application effective dépend également des capacités du terminal et de son système d’exploitation. Il ne faut donc pas supposer que toute application téléchargée possède un identifiant exploitable par l’URSP ou qu’elle bénéficie automatiquement d’une tranche dédiée.

2.4. DNN et S-NSSAI : deux informations complémentaires

Le DNN (Data Network Name) désigne le réseau de données auquel le terminal souhaite accéder. Le S-NSSAI (Single Network Slice Selection Assistance Information) identifie une tranche de réseau.

Le couple DNN/S-NSSAI contribue à déterminer les fonctions de réseau et les politiques applicables à la session. Il ne constitue toutefois pas, à lui seul, un identifiant unique de session : un terminal peut établir plusieurs sessions PDU vers un même DNN et un même S-NSSAI.

On rappelle que le couple DNN/S-NSSAI constitue un critère central de découverte et de sélection du SMF, mais il ne suffit généralement pas à identifier une instance SMF unique. L’AMF peut s’appuyer sur le NRF pour découvrir les SMF compatibles, puis tenir compte d’autres paramètres, la localisation du terminal, les données d’abonnement, les capacités et la charge des SMF ainsi que les politiques de l’opérateur. Plusieurs sessions PDU peuvent partager le même DNN et le même S-NSSAI, tout en étant distinguées par leurs PDU Session ID

La session est identifiée, du point de vue du terminal, par son PDU Session ID.

3. Comment le réseau établit-il la session PDU ?

Considérons maintenant le cas où aucune session existante ne répond aux critères de routage.

La procédure décrite ici est celle d’un établissement demandé par le terminal, en situation non itinérante, conformément à la TS 23.502, section 4.3.2.2.1.

Les grandes étapes de l’établissement

  1. Le terminal demande la session.

    Le UE transmet à l’AMF un message NAS contenant le PDU Session ID, le DNN et le S-NSSAI demandés lorsqu’ils sont fournis, ainsi qu’un conteneur N1 SM comprenant le PDU Session Establishment Request.

  2. L’AMF sélectionne le SMF.

    Il s’appuie sur les informations d’abonnement, le DNN, le S-NSSAI, la localisation et la découverte des fonctions réseau. Le NSSF peut contribuer à la sélection du contexte de tranche ; le NRF permet de découvrir des SMF compatibles.

  3. Le SMF vérifie et prépare la session.

    Il vérifie les données d’abonnement auprès de l’UDM, détermine les politiques applicables, éventuellement avec le PCF, sélectionne le ou les UPF et prépare l’adressage IP si la session est de type IP.

  4. Le SMF configure le plan usager.

    Par N4/PFCP, il installe dans le ou les UPF les règles nécessaires à la détection, à l’acheminement, à la QoS et éventuellement à la mesure du trafic.

  5. Le réseau configure l’accès radio et informe le terminal.

    Le SMF fournit les informations N2 destinées au gNB et le message N1 SM PDU Session Establishment Accept destiné au terminal. Le gNB configure les ressources radio nécessaires et retourne les informations de tunnel permettant de finaliser le chemin descendant.

À l’issue de cette procédure, le terminal dispose d’une session PDU avec au moins un QoS flow associé à la règle QoS par défaut. Il peut alors transmettre le trafic correspondant à cette session.

La session PDU n’est pas nécessairement établie à chaque ouverture d’application. Elle peut rester disponible et être réutilisée par plusieurs applications.

4. Comment la QoS est-elle attribuée aux flux ?

L’établissement de la session et l’attribution de la QoS sont deux opérations conceptuellement distinctes, même si elles peuvent intervenir au cours de la même procédure.

4.1. Du besoin applicatif aux règles PCC

Le PCF (Policy Control Function) peut fournir au SMF des règles PCC (Policy and Charging Control). Elles permettent de caractériser des flux de service, de définir leur traitement QoS et de préciser les conditions de tarification applicables.

Le SMF traduit ces règles en instructions destinées aux différentes entités du réseau.

Destinataire Informations et rôle
UE QoS rules pour classifier les paquets montants
UPF Règles PDR, FAR, QER et éventuellement URR
gNB QFI et profils QoS permettant de traiter les flux sur l’accès radio

Le SMF réalise l’association des règles PCC aux flux QoS . Plusieurs règles PCC peuvent être associées à un même flux QoS lorsqu’elles sont compatibles.

4.2. Ne pas confondre QFI et 5QI

Le QFI identifie un flux QoS à l’intérieur d’une session PDU. Le 5QI caractérise le traitement QoS attendu, à travers des paramètres tels que la priorité, le délai et le taux d’erreur des paquets.

Deux flux QoS différents peuvent donc avoir le même 5QI. Inversement, un QFI n’est pas une mesure de priorité : le QFI 1 n’est pas intrinsèquement prioritaire sur le QFI 2.

Un flux QoS peut être non-GBR, sans débit garanti, ou GBR, avec des paramètres de débit garanti et maximal. Le profil QoS transmis au réseau d’accès contient le 5QI et l’ARP, ainsi que les paramètres de débit requis pour les flux GBR.

4.3. Le rôle des règles QoS dans le terminal

Une règle QoS permet au terminal de décider à quel flux QoS associer un paquet montant. Elle comporte un ensemble de filtres de paquets, une précédence et le QFI du flux correspondant.

La règle QoS par défaut permet de traiter le trafic qui ne correspond à aucune règle plus spécifique.

Dans notre exemple de télémédecine, le terminal pourrait ainsi disposer d’une règle spécifique pour le trafic audio et utiliser la règle par défaut pour les documents. Les filtres peuvent exploiter des informations telles que les adresses IP, les ports et les protocoles.

Les règles URSP et les règles QoS remplissent deux fonctions complémentaires. Les premières permettent au terminal de sélectionner une session PDU adaptée au trafic applicatif, notamment à partir du DNN et du S-NSSAI. Une fois cette session sélectionnée, les règles QoS permettent de classifier les paquets montants et de les associer aux QoS flows appropriés. Une même session PDU peut ainsi transporter plusieurs flux applicatifs bénéficiant de traitements QoS différents, sans nécessiter l’établissement d’une session distincte pour chacun d’eux

5. Réutiliser une session PDU : où se situe le gain de signalisation ?

C’est une évolution architecturale du modèle 5G : Imaginons qu’un utilisateur dispose déjà d’une session PDU pour accéder à Internet. Il ouvre ensuite une application de visioconférence. Trois situations sont possibles.

Situation A : Le trafic utilise un flux QoS existant

L’application utilise la session PDU déjà établie. Les paquets correspondent à une règle QoS existante, éventuellement la règle par défaut. Aucune nouvelle signalisation de session ou de QoS nécessaire

Situation B : Une nouvelle règle est nécessaire, sans nouveau flux QoS 

Le réseau souhaite classifier plus précisément le trafic, mais le traitement QoS requis est compatible avec un flux déjà établi. Le SMF peut mettre à jour les règles de classification au niveau du terminal et de l’UPF, tout en conservant le même QFI. Cette classification peut être l’adresse IP du serveur. Il peut y avoir un échange de Signalisation, sans nouvelle session ni nouveau QoS flow

Situation C : Un nouveau flux QoS est nécessaire

Le service nécessite un traitement QoS distinct. Le SMF peut ajouter un flux QoS à la session existante, configurer les règles correspondantes et, lorsque nécessaire, transmettre son profil QoS au gNB.

* Selon les règles déjà présentes, une mise à jour du terminal peut être nécessaire.
** Dans le scénario considéré, sans ajout d’un chemin de transport particulier.
L’ajout d’un flux QoS à une session PDU existante peut nécessiter une procédure de modification comprenant de la signalisation NAS (N1), NGAP (N2) et PFCP (N4). Il n’impose cependant ni l’établissement d’une nouvelle session PDU, ni la création systématique d’un nouveau DRB ou d’un nouveau tunnel N3.

La procédure de modification d’une session PDU est définie dans la TS 23.502, section 4.3.3. Le contrôle des QoS flows et les possibilités de préconfiguration sont décrits dans la TS 23.501, section 5.7.

 

5.1. Pourquoi un nouveau QoS flow ne nécessite-t-il pas forcément un nouveau DRB ?

Dans le réseau d’accès 5G, la couche SDAP assure l’association des flux QoS aux Data Radio Bearers (DRB). Le gNB peut transporter plusieurs flux QoS sur un même DRB si leurs exigences le permettent.

Ainsi, l’ajout d’un nouveau flux QoS ne signifie pas nécessairement la création d’un nouveau bearer radio. Il peut néanmoins nécessiter une mise à jour des informations QoS et de la configuration radio.

Il faut également distinguer le tunnel N3 de la session et les différents QoS flows qu’il transporte. Plusieurs QFI peuvent être multiplexés dans le tunnel N3 d’une même session, sans création d’un tunnel par QFI. Des architectures comportant plusieurs chemins ou tunnels constituent des cas particuliers.

Une modification QoS peut toujours nécessiter plusieurs échanges entre le SMF, l’UPF, le gNB et le terminal

5.2. La Reflective QoS : apprendre à partir du trafic descendant

5.2. La Reflective QoS : déduire les règles montantes du trafic descendant

La Reflective QoS permet au terminal de déduire certaines règles de classification du trafic montant à partir des paquets reçus en liaison descendante. Elle peut ainsi limiter la nécessité de transmettre explicitement de nouvelles règles QoS au terminal.

Prenons l’exemple de notre application de visioconférence. Le réseau a établi un flux QoS particulier pour le trafic vidéo. Lorsque le mécanisme de Reflective QoS est activé, le réseau peut indiquer au terminal, au moyen du Reflective QoS Indicator (RQI), qu’il doit appliquer ce mécanisme aux paquets descendants concernés.

À la réception de ces paquets, le terminal peut créer une règle QoS dérivée, en utilisant notamment les informations d’en-tête des paquets et leur QFI. Les paquets montants correspondant à cette règle sont alors associés au même QFI.

Contrairement à une règle QoS explicitement signalée au terminal, cette règle est déduite du trafic descendant et possède une durée de validité contrôlée par un temporisateur.

Ce mécanisme évite, dans certaines situations, de signaler explicitement chaque nouvelle règle de classification montante. Il ne dispense toutefois pas le réseau de configurer les flux QoS et les ressources nécessaires à leur traitement.

Cette approche peut éviter de signaler explicitement au terminal chaque nouvelle règle montante.

6. Pourquoi la 5G se distingue-t-elle de la connexion PDN en 4G ?

En 4G, une connexion PDN fournit au terminal une connectivité vers un réseau identifié par un APN. Elle est associée à un default EPS bearer et peut comporter plusieurs dedicated EPS bearers.

Lorsqu’un service nécessite un traitement QoS distinct, le réseau peut établir un dedicated bearer. Dans l’architecture EPC classique, cela implique une procédure de contrôle traversant le P-GW, le S-GW, le MME et le réseau d’accès, avec une configuration correspondante du terminal.

En 5G, le QoS flow devient l’unité de différenciation QoS. Il n’est plus nécessaire d’établir un bearer de bout en bout distinct pour chaque traitement QoS.

Aspect 4G EPC 5G Core
Connectivité Connexion PDN Session PDU
Réseau de données APN DNN
Différenciation QoS EPS bearer QoS flow
Identification QoS EBI et QCI QFI et 5QI
Traitement par défaut Default EPS bearer QoS flow associé à la règle par défaut
Traitement supplémentaire Dedicated bearer si nécessaire QoS flow supplémentaire si nécessaire
Ressources radio E-RAB associé au bearer Mapping QoS flows vers DRB par le gNB
Contrôle de session MME, S-GW, P-GW SMF, avec AMF pour le relais et l’accès

La 5G dissocie également l’enregistrement du terminal et l’établissement des sessions PDU. À la différence de l’attachement EPS classique, la procédure de Registration 5G n’impose pas l’établissement d’une session PDU.

Cette distinction doit néanmoins être nuancée : des optimisations CIoT ont également introduit en 4G la possibilité de s’attacher sans connexion PDN.

6.1. Comparaison sur un scénario identique

Prenons une application qui commence à transmettre un flux vidéo nécessitant un traitement QoS distinct, alors que le terminal possède déjà une connectivité Internet.

4G Connexion PDN existante

Nouveau dedicated bearer
Signalisation EPC, NAS et radio
Ressources du bearer

5G Session PDU existante

Nouveau QoS flow si nécessaire
Modification des règles et profils nécessaires
Réutilisation possible du DRB et du tunnel N3

Le gain potentiel réside dans une plus grande indépendance entre les règles de classification, les QoS flows et les ressources de transport. Il ne faut pas en déduire qu’une modification QoS en 5G est systématiquement dépourvue de messages NAS, N2 ou N4.

7. Conclusion

Le passage de la connexion PDN 4G à la session PDU 5G ne constitue pas un simple changement de terminologie. Il introduit une organisation plus souple de la connectivité et de la qualité de service.

Les règles URSP permettent d’orienter le trafic applicatif vers une session appropriée. Les règles PCC et QoS déterminent ensuite le traitement des différents flux. Enfin, la séparation entre QoS flows, tunnels du cœur de réseau et ressources radio permet de faire évoluer le traitement des applications sans reconstruire systématiquement l’ensemble de leur connectivité.

La distinction essentielle est donc la suivante : une nouvelle application ne signifie pas une nouvelle session PDU, et un nouveau besoin QoS ne signifie pas nécessairement un nouveau QoS flow ou un nouveau DRB.

C’est cette indépendance entre connectivité, classification du trafic et ressources de transport qui permet à la 5G de répondre à des besoins applicatifs variés.

Références normatives

Les principales spécifications à citer dans l’article sont :

  • 3GPP TS 23.501 : architecture du 5GS, modèle QoS (§5.7), sélection des fonctions et modes SSC.
  • 3GPP TS 23.502, §4.3.2.2.1 : procédure d’établissement d’une session PDU demandée par le terminal.
  • 3GPP TS 23.503 : politiques PCC et règles URSP.
  • 3GPP TS 23.401 : connexion PDN et EPS bearers en 4G.

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

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.

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

  1. 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.
  2. Service Provisioning : L’ECS fournit les informations relatives aux environnements Edge et aux EES appropriés.
  3. EEC Registration : L’EEC s’enregistre auprès de l’EES sélectionné si cet enregistrement est requis.
  4. EAS Discovery : L’EEC interroge l’EES afin de découvrir un serveur applicatif correspondant aux besoins de l’AC.
  5. 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é.

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

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

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

  1. É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 ?

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.

  1. 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.
  2. 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)

Evolution de la pile protocole radio 6G : quelques propositions

L’accès radio 5G à la 6G : quelles évolutions pour la pile protocolaire ?

La 5G NR a fait évoluer l’interface radio par rapport au LTE : introduction de la couche SDAP, évolution des fonctions PDCP et RLC, nouvelle gestion de la QoS, évolution des mécanismes de retransmission, etc.

Dans un précédent article consacré à l‘évolution de la pile protocolaire du LTE vers NR, nous avions présenté les principales transformations apportées aux différentes couches radio.

A de jour, la pile protocolaire de la 6G n’est pas encore définitivement spécifiée. Les mécanismes présentés dans cet article doivent donc être considérés comme des pistes de conception actuellement étudiées dans le cadre des travaux préparatoires à la standardisation 6G.

Une tendance se dessine néanmoins : améliorer les performances de la future interface radio ne consistera pas uniquement à augmenter le débit de la couche physique. Une partie des gains pourrait provenir d’une évolution du fonctionnement même du plan utilisateur.

Plusieurs objectifs apparaissent :

  • réduire la latence ;
  • limiter la signalisation et certains traitements protocolaires ;
  • améliorer l’efficacité énergétique ;
  • adapter plus rapidement le fonctionnement du RAN aux besoins des applications ;
  • permettre l’utilisation de mécanismes prédictifs, notamment fondés sur l’IA.

Non seulement la 6G poursuit la recherche d’optimisation pour transmettre les données (6G Lean) mais la 6G pourrait également chercher à optimiser le moment où elles sont transmises et les traitements nécessaires avant et après leur transmission.

1. Pourquoi faire évoluer une pile protocolaire 5G qui fonctionne déjà ?

Dans la 5G NR, le plan utilisateur de la pile radio repose sur plusieurs sous-couches :

SDAP → PDCP → RLC → MAC → PHY

Chacune assure des fonctions bien identifiées (liste non exhaustive).

La couche PDCP prend en charge la numérotation des PDU, leur remise en ordre, la protection des données ou encore la détection des duplications.

La couche RLC assure la segmentation et le réassemblage des données et, en mode AM (Acknowledged Mode), les retransmissions ARQ.

La couche MAC réalise le multiplexage des canaux logiques, la gestion des retransmissions HARQ, l’accès aux ressources radio et propose des algorithmes de séquencement entre utilisateurs.

Cette architecture en couches présente un avantage majeur : elle sépare les différentes fonctions et offre une souplesse d’utilisation. Mais cette modularité implique également des états protocolaires, des en-têtes, des traitements successifs et des échanges de signalisation.

Or, les futurs services 6G pourront présenter des contraintes particulièrement fortes : communications immersives, applications d’IA distribuée, communications extrêmement fiables et à faible latence, réseaux non terrestres NTN, etc regroupées sur le service HRLLC.

Pour ces applications, une partie de la latence et de la consommation énergétique peut provenir non plus de la transmission radio elle-même, mais du fonctionnement de la pile protocolaire.

Une piste pour la 6G consiste donc à rendre le plan utilisateur plus simple, plus réactif et, lorsque cela est possible, plus prédictif en optimisant des procédures.

2. Simplifier les couches PDCP et RLC

Une première piste concerne la numérotation des données.

Dans NR, les couches PDCP et RLC disposent chacune de leur propre espace de numérotation fondé sur un Sequence Number (SN).

Au niveau RLC, ce numéro permet notamment d’identifier les PDU, de détecter les données manquantes et, en mode AM, de gérer les mécanismes de retransmission.

PDCP possède de son côté son propre espace de numérotation (SN – Sequence Number), utilisé notamment pour la remise en ordre, la détection des duplications et la continuité des données lors de certaines procédures de mobilité (handover).

Cette séparation offre de la souplesse, mais implique également le maintien de deux espaces de numérotation et des états protocolaires associés.

La 6G pourrait étudier un espace de numérotation SN commun pour la sous-couche PDCP et RLC

L’objectif n’est pas simplement d’économiser quelques bits dans l’en-tête RLC. L’intérêt potentiel réside surtout dans la simplification des états protocolaires, des fenêtres de réception et des mécanismes nécessaires pour assurer la correspondance entre les données PDCP et RLC et également d’apporter de l’IA prédictif. Une telle simplification pourrait réduire les traitements et, indirectement, la consommation énergétique.

Il s’agit néanmoins d’un compromis : les espaces de numérotation SN distincts de la 5G apportent également de la flexibilité. Une éventuelle unification devra donc préserver les propriétés nécessaires aux différents modes de fonctionnement du protocole.

3. Réduire la latence d’accès UL : préconfigurer ou accélérer le scheduling ?

Lorsqu’un paquet arrive dans le buffer d’un UE, celui-ci ne dispose pas nécessairement immédiatement d’une ressource physique PUSCH permettant de le transmettre.

Dans un scheduling UL dynamique, le réseau doit d’abord être informé du besoin de transmission, puis attribuer les ressources correspondantes.

Données UE → SR vers noeud radio  → 1er UL Grant (NB -> UE) → BSR (UE -> NB) → 2e UL Grant (NB -> UE) → transmission (UE -> NB)

La Scheduling Request (SR) informe le réseau que l’UE souhaite transmettre. Un premier grant permet ensuite à l’UE de fournir notamment son Buffer Status Report (BSR). À partir de cette information, le scheduler peut dimensionner plus précisément les ressources nécessaires à la transmission.

Plusieurs échanges peuvent donc intervenir avant même que les données utiles commencent réellement à être transmises.

Pour un transfert volumineux, ces échanges représentent une faible part du temps total de communication. Pour un petit paquet soumis à une contrainte de latence forte, en revanche, le temps consacré à obtenir une ressource peut devenir comparable au temps nécessaire à transmettre les données elles-mêmes.

Deux stratégies utilisées en 4G et en 5G permettent alors de réduire cette latence : préconfigurer les ressources ou accélérer la procédure de scheduling dynamique (se référer aux articles SDT).

3.1 PUR : préconfigurer une ressource UL

Le Preconfigured Uplink Resource (PUR) repose sur une idée simple : certaines ressources UL sont configurées à l’avance afin que l’UE puisse transmettre sans exécuter à chaque fois une procédure complète de demande de ressources.

Lorsque les caractéristiques du trafic sont relativement prévisibles, cette approche permet de supprimer une partie de la signalisation précédant la transmission.

La contrepartie est un manque de souplesse. La ressource est associée à des occasions de transmission prédéfinies. Si les données arrivent juste après une de ces occasions, l’UE doit attendre la suivante. Inversement, une ressource configurée peut rester inutilisée si aucune donnée n’est disponible, ce qui signifie un gaspillage de la ressource radio montante.

Le PUR échange donc une partie de la flexibilité du scheduling dynamique contre une réduction de la signalisation et du délai d’accès.

3.2 Configured Grant : disposer à l’avance d’une ressource PUSCH

Le principe du Configured Grant (CG) permet également à l’UE de disposer de ressources PUSCH configurées à l’avance.

L’UE peut alors transmettre sur une ressource déjà configurée, ce qui permet de court-circuiter une partie de la procédure classique SR → UL Grant → BSR → UL Grant

Ainsi :

Données UE → ressource PUSCH déjà configurée → transmission UE-> NB

Cette approche est particulièrement intéressante pour les trafics périodiques ou sensibles à la latence.

Il faut toutefois distinguer les différents modes de Configured Grant. Dans le Type 2, les paramètres de la ressource sont configurés par RRC, mais son activation ou sa désactivation dépend d’une signalisation de contrôle DCI.

Il s’agit donc toujours d’un accès coordonné par le réseau, même si la procédure est plus légère qu’un scheduling dynamique paquet par paquet.

L’amélioration recherchée n’est pas de supprimer le contrôle du réseau, mais de déplacer une partie de la décision de scheduling en amont.

3.3 Fast UL Scheduling : accélérer le scheduling dynamique

Une autre approche consiste à conserver un fonctionnement dynamique tout en réduisant le nombre d’échanges nécessaires.

Samsung Research [1] part du constat que, dans l’accès UL dynamique 5G, la première réponse accordée après la Scheduling Request sert essentiellement à permettre à l’UE d’envoyer son BSR. Ce n’est qu’après réception de ce BSR que le réseau connaît précisément la quantité de données disponible et peut attribuer un grant adapté.

Le Fast UL Scheduling étudié pour la 6G cherche notamment à supprimer ce premier aller-retour.

L’idée consiste à permettre à l’UE d’envoyer directement le BSR sur une ressource contention-based, sans attendre qu’une allocation de ressource individuelle lui soit préalablement attribuée (UL Grant).

Deux pistes sont notamment envisagées :

  • définir un mécanisme contention-based PUSCH ;
  • réutiliser le principe du 2-step RACH, qui comporte déjà une transmission PUSCH contention-based.

Data arrival → Contention-based PUSCH + BSR → UL Grant → Data

L’aNB dispose ainsi plus rapidement de l’état du buffer et peut calculer le grant réellement nécessaire.

Cette approche ne signifie donc pas que l’UE transmet toutes ses données sans autorisation du réseau. Elle cherche plutôt à permettre à l’UE de transmettre plus rapidement l’information nécessaire au scheduler pour prendre sa décision.

La contrepartie est inhérente à l’accès par contention : plusieurs UE peuvent sélectionner simultanément la même ressource. La gestion des collisions lorsque la charge augmente constitue donc un point important à étudier.

4. Ne plus attendre les données : les annoncer avant leur arrivée

Le Fast UL Scheduling réduit le délai après l’arrivée des données.

Mais peut-on aller plus loin et agir avant leur arrivée ?

Certaines applications produisent un trafic relativement prévisible. Une application immersive ou un traitement d’IA peut par exemple générer des bursts de données à des instants connus ou partiellement prévisibles.

Le terminal pourrait alors indiquer à la station de base :

  • quand les prochaines données devraient arriver ;
  • quelle quantité de données est attendue.

Le scheduler de l’aNB (noeud radio 6G) pourrait ainsi préparer les ressources radio avant même que les données ne soient présentes dans le buffer L2.

Prediction → Resource preparation → Data arrival → Transmission

Cette approche, désignée Early Reporting dans l’étude Samsung, introduit cependant une nouvelle contrainte : la qualité de la prédiction.

Une mauvaise estimation de l’instant d’arrivée ou du volume du prochain burst peut conduire le réseau à réserver inutilement des ressources.

Le problème du scheduler évolue donc : il ne s’agit plus uniquement de décider rapidement quelles ressources attribuer, mais également d’évaluer la fiabilité de l’information prédictive fournie par le terminal.

5. Accélérer les retransmissions : rapprocher HARQ et ARQ

La fiabilité de la liaison radio repose sur plusieurs mécanismes de retransmission.

Au niveau MAC/PHY, HARQ assure des retransmissions rapides.

Au niveau RLC, le mode AM utilise ARQ pour récupérer les données qui n’ont finalement pas pu être correctement transmises.

Dans la pile classique, ces mécanismes appartiennent à des niveaux différents.

Lorsqu’une transmission échoue définitivement au niveau HARQ, RLC peut devoir attendre son propre mécanisme de détection ou un rapport d’état avant de déclencher la retransmission ARQ.

Une piste consiste à renforcer les interactions inter-couches.

L’information issue du mécanisme HARQ pourrait être exploitée afin d’accélérer le déclenchement de la retransmission correspondante au niveau RLC.

L’objectif n’est donc pas nécessairement de fusionner HARQ et ARQ, mais de réduire le délai existant entre les deux mécanismes. Par contre, il est nécessaire de positionner cette solution parmi les architectures O-RAN.

Pour certaines applications 6G, recevoir un paquet avec une très grande fiabilité après son échéance peut n’avoir aucun intérêt.

La question n’est alors plus seulement : Le paquet finira-t-il par arriver ?

mais plutôt : Le paquet arrivera-t-il avant son échéance ?

6. Une QoS capable de s’adapter pendant la communication

La 5G introduit le concept de QoS Flow.

Les paquets sont associés à des caractéristiques définissant notamment leur priorité, leur budget de délai ou leurs contraintes de fiabilité.

Ce modèle fonctionne particulièrement bien lorsque les caractéristiques du trafic restent relativement stables.

Certains services 6G pourraient toutefois produire des flux beaucoup plus variables.

Prenons une application XR. Elle peut générer successivement :

petit paquet critique → burst vidéo → données moins prioritaires → nouveau paquet critique

Appliquer exactement le même traitement à tous ces paquets peut devenir inefficace.

Une piste consiste donc à rendre la gestion de la QoS plus dynamique et davantage consciente des caractéristiques du service.

Le réseau pourrait notamment prendre en compte :

  • le volume du prochain burst ;
  • son instant d’arrivée ;
  • le délai restant avant son échéance ;
  • l’importance d’un paquet ou d’un ensemble de PDU ;
  • les relations temporelles entre plusieurs flux.

Les paramètres L2 pourraient alors être adaptés dynamiquement.

Par exemple, retransmettre un paquet dont le délai maximal est déjà dépassé consomme des ressources radio sans nécessairement améliorer la qualité perçue par l’application. Il pourrait être préférable de l’abandonner afin d’utiliser ces ressources pour un paquet encore utile.

Le RAN devient ainsi progressivement davantage service-aware.

7. Vers une gestion énergétique coordonnée entre l’UE et le réseau

La réduction de la consommation énergétique n’est pas une problématique nouvelle. La 5G NR dispose déjà de mécanismes permettant de limiter les périodes d’activité du terminal, notamment le C-DRX et des mécanismes de Wake-Up Signal (WUS).

Le principe du WUS est d’éviter qu’un UE doive activer inutilement l’ensemble de sa chaîne de réception pour surveiller le canal de contrôle. Un signal de réveil plus simple peut lui indiquer s’il doit sortir de son état de faible consommation.

L’enjeu pour la 6G n’est donc pas d’introduire le principe du WUS, mais d’aller plus loin dans la gestion coordonnée des périodes d’activité et de sommeil du terminal et du réseau.

Le réseau pourrait lui-même désactiver temporairement certaines ressources : porteuses, chaînes d’antennes, couches MIMO, cellules de capacité ou certains signaux de référence.

Une coordination plus fine devient alors nécessaire : il serait contre-productif qu’un UE se réveille précisément au moment où les ressources réseau dont il a besoin ont été placées en sommeil.

La problématique énergétique devient ainsi plus globale : il ne s’agit plus seulement de réduire la consommation du terminal, mais d’optimiser conjointement les périodes d’activité de l’UE et du réseau.

8. L’IA dans la pile protocolaire : prédire plutôt que réagir

Plusieurs des mécanismes précédents ont un point commun : ils nécessitent d’anticiper.

Il peut être utile de prévoir :

  • l’arrivée du prochain paquet ;
  • le volume du prochain burst ;
  • la durée probable d’une période d’inactivité ;
  • l’évolution des contraintes de QoS.

L’intelligence artificielle peut donc devenir un outil intéressant pour optimiser le fonctionnement de la couche 2.

Un modèle local au terminal pourrait par exemple estimer le Time To Next Packet, c’est-à-dire le temps restant avant l’arrivée probable des prochaines données.

Le terminal pourrait rester plus longtemps en sommeil lorsque le prochain paquet est prévu loin dans le temps, puis se réveiller à l’approche de son arrivée.

De la même manière, une estimation du trafic futur peut permettre au scheduler de préparer les ressources nécessaires avant l’arrivée effective des données.

Il faut cependant distinguer :

  • utiliser l’IA dans un équipement
  • standardiser un algorithme d’IA.

Il n’est pas nécessaire que le 3GPP impose le modèle utilisé par chaque terminal ou équipement réseau.

Le standard peut plutôt définir les informations échangées, leur signification, leur validité et la manière dont elles peuvent être exploitées, tout en laissant aux constructeurs le choix de leurs algorithmes de prédiction.

L’un des enjeux de la future standardisation pourrait donc être de permettre l’exploitation de la prédiction sans figer les algorithmes qui la réalisent.

9. Quelles métriques cherche-t-on réellement à améliorer ?

Les différentes évolutions présentées précédemment ne cherchent pas toutes à améliorer les mêmes performances. Certaines agissent principalement sur la latence, d’autres sur la consommation énergétique, l’utilisation des ressources radio ou encore la fiabilité dans un délai imposé.

Il est donc intéressant de relier chaque évolution aux métriques qu’elle cherche principalement à améliorer.

Piste étudiée Mécanisme Métriques principalement visées
Simplification PDCP/RLC Réduction des états et mécanismes protocolaires redondants complexité ↓ ; traitements ↓ ; overhead protocolaire ↓
PUR / Configured Grant Ressources UL préconfigurées latence d’accès UL ↓ ; signalisation ↓
Fast UL Scheduling Réduction des échanges précédant l’allocation UL latence d’accès UL ↓ ; temps avant transmission ↓
Early Reporting Anticipation de l’arrivée et du volume des données latence ↓ ; utilisation des ressources ↑
Interaction HARQ–ARQ Transmission plus rapide de l’information d’échec entre couches temps de récupération ↓ ; latence de retransmission ↓ ; fiabilité dans un délai imposé ↑
QoS dynamique / service-aware Adaptation du traitement aux caractéristiques des données respect du délai ↑ ; ressources utiles ↑ ; QoS applicative ↑
Coordination énergétique UE–aNB Coordination des périodes d’activité et de sommeil consommation UE ↓ ; consommation RAN ↓ ; efficacité énergétique ↑
Prédiction / IA Anticipation du trafic et des besoins latence ↓ ; consommation ↓ ; utilisation des ressources ↑

Ces métriques ne sont évidemment pas indépendantes. Une même évolution peut améliorer une métrique tout en introduisant un compromis sur une autre.

Le Fast UL Scheduling en fournit un bon exemple : l’utilisation d’une ressource contention-based peut réduire la latence lorsque la charge est faible, mais elle introduit également un risque de collision lorsque plusieurs UE tentent d’accéder simultanément à la même ressource. De même, l’Early Reporting peut permettre de préparer les ressources avant l’arrivée des données, mais une mauvaise prédiction peut conduire à réserver inutilement des ressources.

L’objectif de la future pile protocolaire n’est donc pas de maximiser indépendamment chacune de ces métriques, mais de rechercher un compromis dynamique entre latence, fiabilité, efficacité spectrale, consommation énergétique et complexité protocolaire, en fonction du service transporté.

10. De la 5G réactive à une 6G plus prédictive

Les différentes pistes étudiées semblent finalement suivre une logique commune.

Fonction 5G NR Piste 6G
Numérotation L2 SN PDCP + SN RLC SN potentiellement unifié
Accès UL SR → Grant → BSR → Grant Fast UL Scheduling
Allocation UL après arrivée des données Early Reporting
Retransmission HARQ puis ARQ interaction HARQ–ARQ
QoS paramètres relativement stables QoS plus dynamique / service-aware
Énergie mécanismes principalement côté UE coordination UE–aNB
Décision principalement réactive prédiction / IA

Ces évolutions ne conduisent donc pas nécessairement à l’apparition d’une nouvelle couche protocolaire.

Elles suggèrent plutôt un changement de philosophie.

Observation → prédiction → anticipation → allocation/configuration → événement

La réduction de la latence ne provient alors plus uniquement d’une transmission physique plus rapide.

Elle peut également résulter de la suppression d’attentes, de signalisation et de traitements devenus inutiles.

Conclusion

Les premières réflexions autour du plan utilisateur 6G montrent que l’évolution de la future interface radio ne devrait pas se limiter à de nouvelles bandes de fréquences, de nouveaux schémas de transmission ou à une augmentation du débit.

Une partie importante des gains pourrait provenir d’une simplification et d’une adaptation de la pile protocolaire elle-même.

Trois tendances principales se dégagent :

  • Simplifier, en supprimant certains états, traitements ou informations redondants.
  • Accélérer, en renforçant les interactions entre les couches et en réduisant les échanges nécessaires avant une transmission.
  • Anticiper, grâce à une meilleure connaissance des caractéristiques du service et, éventuellement, à des mécanismes prédictifs reposant sur l’IA.

Ces évolutions cherchent conjointement à réduire la latence, les traitements protocolaires et la consommation énergétique, tout en améliorant l’utilisation des ressources et la capacité à respecter les contraintes temporelles des applications.

Ces mécanismes restent néanmoins des pistes de conception et de standardisation. Les choix définitifs dépendront des travaux du 3GPP et des compromis entre performances, complexité, consommation énergétique, robustesse et interopérabilité.

La 6G pourrait ainsi ne pas seulement être une interface radio plus rapide que la 5G.

Elle pourrait surtout devenir une interface moins dépendante de mécanismes purement réactifs, davantage consciente des caractéristiques du service transporté et capable d’anticiper une partie des besoins de transmission.

Références

  1. Samsung Research, Streamlined, Efficient and Intelligent User Plane Design for 6G, 2026.
  2. 3GPP TR 38.914, Study on 6G Scenarios and Requirements.
  3. F. Launay, Évolution de la pile protocolaire LTE vers NR (3/5).
  4. 3GPP TS 38.322, NR; Radio Link Control (RLC) protocol specification.

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

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 :

  1. Complexité accrue d’implémentation
  2. Problèmes de synchronisation et de décodage de canal plus complexes
  3. OFDM avec CP reste plus robuste et pratique pour les déploiements
  4. É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)

 

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

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

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

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

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

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

sans intervention humaine

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

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

1. Pourquoi automatiser le réseau 5G ?

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

L’enjeu est triple :

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

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

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

2.1 Principe général

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

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

2.2 Fonctionnement : collecte, traitement, analytiques

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

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

Les analytiques produites peuvent être de deux natures :

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

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

Release 15 (2019) — La fondation

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

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

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

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

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

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

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

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

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

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

b) Nouvelles fonctions d’infrastructure d’automatisation :

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

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

Figure 2 : Architecture NAE

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

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

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

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

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

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

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

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

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

4. Cas d’usage illustratifs

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

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

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

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

5. Points clés à retenir

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

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

 

Références normatives

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

Source principale :

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

 

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

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

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

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

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

Les six scénarios d’usage IMT-2030

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

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

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

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

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

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

Performances du scénario IC (Immersive Communication)

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

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

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

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

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

Performances des scénarios HRLLC et MC

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

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

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

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

Les six nouvelles exigences spécifiques à IMT-2030

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

Exigence composite (scénario IC)

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

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

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

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

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

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

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

Précision de positionnement (scénario ISAC)

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

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

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

Exigence IA (scénario AIAC)

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

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

L’exigence UC couvre deux dimensions complémentaires :

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

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

Distance de liaison (Link Distance)

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

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

La séquence normative est maintenant bien établie :

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

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

Conclusion : ce que ces exigences signifient pour la recherche

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

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

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

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

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

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

Références

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

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

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

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

La vision de la 6G par SK Telecom

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

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

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

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

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

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

1. Quatre ruptures attendues à l’horizon 2030

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

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

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

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

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

2. Les objectifs qui guident cette évolution

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

3. Les briques technologiques structurantes de la 6G

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

10. Conclusion

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


Glossaire des principaux sigles

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

Pour aller plus loin

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

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

 

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

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

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

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

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

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

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

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

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

 

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

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

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

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

 

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

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

 

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

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

2.2 Le DNN — Data Network Name

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

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

Le DNN remplit trois fonctions complémentaires :

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

 

DNN et architecture hybride PNI-NPN

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

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

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

2.3 Le SSC Mode — Session and Service Continuity

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

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

 

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

 

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

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

3.1 Les types de NSSAI

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

 

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

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

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

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

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

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

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

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

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

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

Rôle exact de l’AMF et du NSSF

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

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

 

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

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

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

 

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

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

4.1 Déclenchement

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

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

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

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

 

4.3 Création du contexte SMF

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

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

 

5. URSP — UE Route Selection Policy

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

5.1 Architecture des acteurs

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

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

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

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

 

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

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

 

5.3 Exemples de règles URSP hospitalières

Règle 1 —trafic IoT médical critique

Traffic Descriptor : IPv4 dest = 10.100.0.0/16

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

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

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

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

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

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

 

Règle 3 — communications MCX

Traffic Descriptor : App Descriptor = com.hospital.mcx

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

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

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

Traffic Descriptor : Match-all

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

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

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

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

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

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

Le provisionnement réseau

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

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

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

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

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

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

Pourquoi le MDM est indispensable :

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

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

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

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

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

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

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

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

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

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

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

Référence : TS 23.502 §4.3.2.

6.1 Séquence

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

7.1 Pourquoi MPLS L3 VPN ?

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

 

7.2 Architecture MPLS L3 VPN (RFC 4364)

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

7.3 Mécanisme de forwarding

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

7.4 Interfaces 5GC et backbone MPLS

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

 

Interface N4 et disponibilité

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

 

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

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

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

 

9. Références normatives

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