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