Du MMTEL AS au NG-RTC : comment l’IMS réinvente les communications téléphoniques

Posté le by - 63 vues
Répondre

VoLTE, VoNR, IMS Data Channels, WebRTC… Derrière ces technologies se dessine une évolution majeure : la transformation de l’appel téléphonique en une expérience multimédia interactive. Comment l’architecture IMS accompagne-t-elle cette évolution et quel rôle conserve le MMTEL AS ?

1. Le MMTEL AS : au cœur de la téléphonie IMS

Avec le déploiement de la VoLTE (Voice over LTE), puis de la VoNR (Voice over New Radio), les opérateurs mobiles ont progressivement fait évoluer leurs services téléphoniques vers une architecture entièrement IP.

Cette évolution repose sur le réseau IMS (IP Multimedia Subsystem), une architecture normalisée par le 3GPP permettant de fournir des services de communication multimédia sur différents réseaux d’accès.

Pour enrichir les services voix, le MMTEL AS (Multimedia Telephony Application Server), souvent désigné sous le terme TAS (Telephony Application Server) apporte des fonctionnalités supplémentaires.

le rôle du MMTEL AS ?

Le MMTEL AS assure la logique applicative des services téléphoniques IMS comme :

  • Des renvois et transferts d’appels.
  • De la mise en attente et du double appel.
  • Des conférences téléphoniques.
  • De la présentation ou de la restriction de l’identité de l’appelant.
  • Des services supplémentaires associés aux communications multimédias.

Le MMTEL AS intervient principalement dans le plan de contrôle des services. Il s’appuie sur le protocole SIP (Session Initiation Protocol) pour participer à l’établissement, à la modification et à la terminaison des sessions IMS. Lors de l’établissement de la communication, les messages SIP transportent des descriptions SDP permettant aux extrémités de négocier les caractéristiques des médias, notamment les codecs et les paramètres de transport. Une fois la session établie, les flux vocaux sont transportés en RTP, éventuellement à travers des fonctions média intermédiaires. Le MMTEL AS peut intervenir dans la logique de service sans nécessairement traiter ces flux. Le MMTEL AS apporte des fonctions supplémentaires comme un renvoi d’appel, une pré-image qui sera affichée sur le poste de l’appelé, une sonnerie personnalisée…

le MMTEL AS contrôle la logique du service téléphonique, mais n’est pas un équipement de transport de la voix. Le transport de la voix est ensuite assuré par le protocole RTP (Real-time Transport Protocol) entre l’appelant et l’appelé.

2. L’architecture IMS : comment fonctionne le cœur des services VoLTE et VoNR ?

Pour comprendre le rôle du MMTEL AS et les évolutions apportées par NG-RTC, il est utile de revenir sur l’architecture IMS (IP Multimedia Subsystem) et de la comprendre.

L’IMS repose sur plusieurs fonctions spécialisées qui assurent l’enregistrement des utilisateurs, la signalisation des appels, l’exécution des services téléphoniques et, lorsque cela est nécessaire, le traitement des médias.

Son principe fondamental est de séparer le contrôle de la communication du transport de la voix.

Les CSCF : les fonctions de contrôle des sessions SIP

L’architecture IMS comprend trois fonctions principales de contrôle des sessions, appelées CSCF (Call Session Control Function).

Le P-CSCF (Proxy-CSCF)

Il constitue le premier point de contact du terminal avec l’IMS. Il reçoit les messages SIP du smartphone et les transmet aux autres fonctions du réseau. Il participe également à la sécurisation de la signalisation et aux mécanismes de contrôle de la qualité de service.

L’I-CSCF (Interrogating-CSCF)

Il intervient lors de l’enregistrement IMS et de l’établissement des communications. Il permet d’identifier le S-CSCF chargé de prendre en charge l’abonné, en s’appuyant sur les informations du réseau de rattachement.

Le S-CSCF (Serving-CSCF)

Il constitue la fonction centrale de contrôle des sessions SIP de l’abonné. Il assure :

  • La gestion de l’enregistrement IMS.
  • Le traitement et le routage des messages SIP.
  • L’application des règles de déclenchement des services.
  • L’interaction avec les serveurs d’applications IMS.

Dans cette architecture, c’est la fonction S-CSCF qui fait intervenir le MMTEL AS lorsqu’un service téléphonique doit être exécuté.

Le HSS : les informations d’abonnement

Le HSS (Home Subscriber Server) conserve les données nécessaires au fonctionnement des services IMS. Il contient les identités IMS, les informations d’authentification, les profils de service et les informations nécessaires à l’affectation du S-CSCF.

Dans les architectures IMS classiques, le S-CSCF et l’I-CSCF communiquent avec le HSS à travers les interfaces Cx fondées sur Diameter.

Dans les architectures plus récentes, les données d’abonnement peuvent également être accessibles au moyen de fonctions adaptées à l’environnement 5G.

Les Application Servers : la logique des services

Les serveurs d’applications, ou IMS AS (IMS Application Servers), exécutent les services associés aux communications.

Le MMTEL AS en est un exemple majeur.

Lorsqu’un abonné dispose d’un service de renvoi d’appel, le S-CSCF peut déclencher le MMTEL AS afin que celui-ci applique la logique correspondante.

L’interface entre le S-CSCF et l’IMS AS est appelée ISC (IMS Service Control). Elle repose sur SIP.

L’IMS peut également intégrer d’autres serveurs d’applications, selon les services proposés par l’opérateur.

La MRF : le traitement des médias

La MRF (Media Resource Function) fournit des ressources de traitement média lorsque les services en ont besoin.

Elle peut intervenir pour :

  • Diffuser des annonces vocales.
  • Générer certaines tonalités.
  • Mixer plusieurs flux audio lors de conférences.

L’architecture MRF distingue traditionnellement une fonction de contrôle, le MRFC, et une fonction de traitement média, le MRFP.

Il ne faut pas confondre cette MRF avec la MF (Media Function) introduite dans l’architecture IMS Data Channel, dont nous détaillerons le rôle plus loin.

Les fonctions d’interconnexion

L’IMS peut également comporter des fonctions permettant de communiquer avec d’autres réseaux.

Par exemple, le BGCF (Breakout Gateway Control Function) participe à la sélection du réseau de sortie vers les réseaux téléphoniques à commutation de circuits.

Le MGCF (Media Gateway Control Function) assure des fonctions de contrôle de l’interfonctionnement avec ces réseaux, en association avec une passerelle média.

Ces fonctions sont particulièrement utiles lorsqu’un appel IMS doit joindre un correspondant situé sur un réseau téléphonique traditionnel.

Exemple : établissement d’un appel VoLTE ou VoNR

Prenons le cas d’un utilisateur qui appelle un correspondant depuis son smartphone.

  1. Enregistrement IMS : le terminal s’enregistre auprès de l’IMS via le P-CSCF. Le S-CSCF prend en charge l’enregistrement de l’abonné.
  2. Initiation de l’appel : le terminal envoie un message SIP INVITE contenant une description SDP des médias proposés, comme les codecs audio et les paramètres de transport.
  3. Contrôle de la session : les fonctions CSCF acheminent la signalisation SIP. Le S-CSCF peut faire intervenir le MMTEL AS selon les services de l’abonné.
  4. Négociation des médias : les échanges SIP/SDP permettent aux extrémités de convenir des caractéristiques de la communication, du codec et des adresses IP et ports utilisés pour les flux média.
  5. Transport de la voix : une fois la communication établie, les paquets vocaux sont transportés en RTP, éventuellement à travers des équipements intermédiaires.

Le MMTEL AS peut donc intervenir dans le contrôle de l’appel sans transporter lui-même les paquets de voix.

Pourquoi cette architecture est-elle importante pour NG-RTC ?

Cette organisation permet à l’IMS d’évoluer sans remettre en cause ses fonctions fondamentales.

Avec NG-RTC, les fonctions CSCF continuent de gérer la signalisation des sessions IMS, tandis que les serveurs d’applications conservent leur rôle dans l’exécution des services.

De nouveaux composants nommés DCSF, DCAR, DC Application Server et la MF, viennent compléter cette architecture pour prendre en charge les canaux de transport de service nommés IMS Data Channels.

L’IMS Application Server

L’IMS AS conserve un rôle central dans la coordination des services et des ressources associées à la session IMS. L’IMS AS interagit avec le DCSF et la MF pour assurer la cohérence entre le contrôle de la communication et les ressources Data Channel.

Le DCSF : Data Channel Signalling Function

Le DCSF assure les fonctions de contrôle spécifiques aux IMS Data Channels. Il intervient dans les procédures de négociation, d’établissement et de gestion des canaux de données.

Le DCSF ne pilote pas directement la MF.

La chaîne de contrôle passe par l’IMS AS :

  1. Le DCSF détermine les opérations nécessaires à la gestion du Data Channel.
  2. L’IMS AS reçoit les instructions du DCSF.
  3. L’IMS AS interagit avec la MF pour gérer les ressources média correspondantes.

Cette organisation maintient l’IMS AS au centre de la coordination des services.

Le DCAR : Data Channel Application Repository

Le DCAR constitue un référentiel de ressources applicatives Data Channel. Il intervient dans la découverte et la mise à disposition des applications utilisables dans l’environnement IMS Data Channel.

Il ne doit pas être confondu avec le serveur qui assure la logique métier d’une application.

Le DC AS : Data Channel Application Server

Le DC AS est le serveur applicatif associé à un fournisseur de service. Le 3GPP définit son intégration dans l’architecture IMS Data Channel, mais ne spécifie pas ses fonctionnalités applicatives internes.

Cette souplesse permet d’envisager différents types de services.

La MF : Media Function

La Media Function assure les fonctions média nécessaires aux IMS Data Channels.

Les principales interfaces de l’architecture

Interface Fonctions reliées
DC1 IMS AS ↔ DCSF
DC2 IMS AS ↔ MF
DC3 DCSF ↔ NEF
DC4 DCSF ↔ DC AS
DC5 DCSF ↔ DCAR
MDC1 MF ↔ DCSF, trafic Bootstrap
MDC2 MF ↔ DC AS, trafic applicatif A2P/P2A

Les interfaces de contrôle reposent sur une approche service-based, avec les services Nimsas, Ndcsf et Nmf, décrits dans les spécifications 3GPP de la famille TS 29.175.

Cette organisation distingue clairement le contrôle des services, la gestion des ressources média et la logique applicative.

la MRF

Les premières évolutions de l’architecture IMS Data Channel ont également envisagé l’utilisation d’une MRF (Media Resource Function).

Cette possibilité pouvait présenter un intérêt pour les opérateurs disposant déjà d’infrastructures MRF.

Toutefois, l’architecture a évolué au fil des versions de la Release 18, avec la suppression de cette variante dans les versions ultérieures de l’annexe AC de TS 23.228.

Il convient donc de ne pas présenter aujourd’hui MF et MRF comme deux solutions systématiquement équivalentes dans l’architecture normalisée.

NG-RTC ne remplace donc pas le cœur IMS : il étend ses capacités en ajoutant de nouvelles fonctions de contrôle, de transport et d’exécution applicative.

3. Call Composer : enrichir l’appel avant même de décrocher

L’enrichissement des communications IMS n’a pas commencé avec NG-RTC. La spécification GSMA RCC.20 (Enriched Calling) définit le Call Composer, qui permet d’associer des informations contextuelles à un appel.

L’appelant peut, par exemple, transmettre le sujet de son appel, son importance ou une image associée.

Deux variantes techniques doivent être distinguées.

Le MMTEL-based Call Composer

Dans cette première variante, les informations sont intégrées directement à la signalisation SIP de l’appel MMTEL.

L’INVITE SIP peut contenir :

  • Subject : sujet de l’appel.
  • Priority : niveau de priorité.
  • Call-Info : lien vers une image associée.

Les informations sont ainsi transmises dans le cadre de l’établissement de l’appel.

Cette variante n’utilise pas le protocole MSRP.

Le Session-based Call Composer

La seconde variante repose sur une session Enriched Calling dédiée.

Elle utilise :

  • SIP/SDP pour établir et négocier la session.
  • MSRP (Message Session Relay Protocol) pour transporter les messages.
  • CPIM/XML pour encapsuler et structurer les informations applicatives.

Ces deux variantes répondent au même objectif fonctionnel, mais utilisent des mécanismes techniques différents.

Le Call Composer constitue ainsi une étape vers les appels enrichis. Il reste toutefois distinct des IMS Data Channels, dont l’ambition est de permettre des interactions applicatives plus étendues pendant une communication.

4. NG-RTC : vers des communications interactives de nouvelle génération

Le NG-RTC (Next Generation Real-Time Communication) désigne les évolutions des communications temps réel IMS, autour des services multimédias enrichis.

L’un des mécanismes majeurs de cette évolution est l’IMS Data Channel, qui permet d’associer des échanges de données applicatives à une communication IMS.

L’objectif n’est plus seulement de transmettre de la voix ou de la vidéo, mais également de permettre aux utilisateurs d’interagir avec des services numériques pendant leur communication.

Quelques exemples d’utilisation

Dans le secteur bancaire, un conseiller pourrait proposer à son client une simulation interactive d’un prêt pendant un appel.

Dans l’assurance, un assuré pourrait compléter un formulaire ou transmettre des informations concernant un sinistre sans quitter l’environnement de communication.

Dans l’assistance technique, un utilisateur pourrait accéder à une interface de diagnostic ou partager des informations avec un service d’assistance.

Ces scénarios nécessitent des fonctions applicatives qui dépassent les services téléphoniques traditionnels du MMTEL AS.

C’est pourquoi l’architecture IMS évolue avec de nouveaux composants spécialisés, tout en conservant ses mécanismes fondamentaux de signalisation et de contrôle.

Le DCAR : Data Channel Application Repository

Dans la section II, ous avons présenté le rôle du DCAR en expliquant qu’il intervient dans la découverte et la mise à disposition des applications utilisables dans l’environnement IMS Data Channel.

Prenons l’exemple d’un appel à une compagnie d’assurance. Pendant la conversation, le conseiller propose au client de remplir un formulaire de déclaration de sinistre directement sur son smartphone.

Le DCAR peut fournir les ressources nécessaires au chargement de cette application, notamment ses fichiers HTML, JavaScript et CSS. Ces ressources sont récupérées à travers le Bootstrap Data Channel, avec l’intervention de la MF et du DCSF.

Une fois le formulaire affiché, les interactions avec le système d’information de l’assureur peuvent être assurées par un Application Data Channel connecté au DC Application Server (DC AS).

Le DCAR fournit donc les ressources de l’application, tandis que le DC AS assure sa logique métier et le traitement des données échangées.

5. IMS Data Channel : un nouveau média dans la session IMS

Dans une communication IMS classique, les principaux médias sont l’audio et éventuellement la vidéo. Avec les IMS Data Channels, un nouveau type de média peut être associé à la session.

Type de média Fonction
Audio Communication vocale
Vidéo Communication visuelle
Data Channel Échanges de données et interactions applicatives

Les Data Channels utilisent les mécanismes de transport des WebRTC Data Channels. Il ne faut cependant pas en déduire que l’ensemble de la communication IMS devient une communication WebRTC classique.

SIP et SDP restent utilisés pour la signalisation et la négociation de la session IMS. Les mécanismes WebRTC Data Channel interviennent au niveau du transport des données applicatives.

Bootstrap Data Channel et Application Data Channel

L’architecture distingue deux types de canaux.

Le Bootstrap Data Channel permet d’initialiser l’environnement applicatif et de récupérer les ressources nécessaires à l’utilisation des applications Data Channel.

Reprenons l’architecture du réseau IMS avec les fonctions NG-RTC.

Dans l’architecture utilisant une Media Function (MF), le Bootstrap Data Channel est terminé par la fonction MF. Celle-ci agit comme un proxy HTTP et relaie les requêtes du terminal vers le DCSF via l’interface MDC1.

L’Application Data Channel est ensuite utilisée pour les échanges de données nécessaires au fonctionnement de l’application.

Les mécanismes de multiplexage SCTP distinguent les canaux à l’aide de plages de stream IDs :

Type de canal Plage de stream IDs SCTP
Bootstrap Data Channel 0 à 999
Application Data Channel 1000 et au-delà

Cette distinction permet de séparer les échanges nécessaires à l’initialisation des services des données échangées par les applications.

Trois modèles de communication

Les IMS Data Channels prennent en charge trois grands modèles :

P2P (Person-to-Person) : échange de données applicatives entre deux utilisateurs.

A2P (Application-to-Person) : communication applicative depuis un service vers un utilisateur.

P2A (Person-to-Application) : interaction d’un utilisateur avec une application serveur.

Ces modèles permettent de couvrir des scénarios de communication entre particuliers, mais également des services professionnels ou des interactions entre une entreprise et ses clients.

Ainsi, la fonction MF assure :

Pour le Bootstrap Data Channel :

  • La MF termine le canal établi avec le terminal.
  • Elle relaie les échanges HTTP vers le DCSF via MDC1.

Pour les Application Data Channels A2P/P2A :

  • La MF relaie le trafic entre le terminal et le DC AS.
  • Elle utilise l’interface MDC2 du côté du serveur applicatif.

La MF intervient donc dans le plan média, tandis que les décisions de contrôle des ressources passent par l’IMS AS.

6. La pile protocolaire SCTP et DTLS ?

Les IMS Data Channels s’appuient sur des mécanismes issus de WebRTC pour le transport des données applicatives.

La pile protocolaire typique est la suivante :

Données applicatives → SCTP → DTLS → UDP → IP

Chaque protocole joue un rôle particulier.

SCTP : multiplexage et fiabilité configurable

SCTP (Stream Control Transmission Protocol) permet :

  • De transporter plusieurs flux logiques indépendants au sein d’une même association.
  • D’utiliser une livraison fiable ou partiellement fiable.
  • De configurer l’ordonnancement des messages.

Cette souplesse est particulièrement intéressante pour les applications interactives.

Par exemple, la transmission d’un document exige généralement une livraison fiable, tandis que certaines mises à jour d’interface peuvent perdre leur intérêt si elles arrivent trop tard.

SCTP n’est donc pas intrinsèquement plus rapide que TCP. Son avantage réside dans le multiplexage et la flexibilité des mécanismes de livraison.

DTLS : la sécurité des échanges

DTLS (Datagram Transport Layer Security) assure la protection cryptographique des échanges, leur confidentialité et leur intégrité, ainsi que l’authentification des extrémités de la connexion sécurisée.

UDP : le transport sous-jacent

UDP transporte les datagrammes sans garantir lui-même leur livraison ni leur ordonnancement.

Les mécanismes nécessaires à la fiabilité sont assurés par SCTP lorsque l’application en a besoin.

Cette combinaison permet de prendre en charge des échanges applicatifs interactifs tout en conservant les mécanismes de sécurité nécessaires.

7. NG-RTC est-il réservé à la VoNR ?

NG-RTC est une évolution des services IMS et non une fonctionnalité exclusivement liée à la 5G NR. La VoLTE et la VoNR utilisent toutes deux l’architecture IMS.

La différence réside principalement dans le réseau d’accès et le cœur de réseau :

  • VoLTE : LTE, EPC et IMS.
  • VoNR : 5G NR, 5GC et IMS.

Les IMS Data Channels peuvent être utilisés sur différents accès compatibles, sous réserve de la prise en charge des fonctionnalités par les terminaux et les infrastructures.

La 5G SA peut offrir un environnement favorable à certains services enrichis grâce à ses mécanismes de qualité de service et aux capacités du réseau.

Il serait toutefois incorrect d’affirmer que la VoNR constitue un prérequis obligatoire à NG-RTC.

8. L’évolution des IMS Data Channels dans les Releases 3GPP

L’architecture IMS Data Channel s’est progressivement structurée dans les spécifications 3GPP.

Release Principales évolutions
Release 18 Introduction de l’architecture IMS Data Channel dans l’annexe AC de TS 23.228 : DCSF, DCAR, MF, DC AS et procédures de gestion des canaux.
Release 19 Améliorations architecturales et procédurales, concernant l’interfonctionnement, les sessions Data Channel autonomes et le multiplexage applicatif SCTP.
Release 20 — travaux en cours Étude SA4 TR 26.814 sur les améliorations des IMS Data Channels et la clarification de certaines ambiguïtés d’interopérabilité.

La Release 18 constitue une étape structurante dans la normalisation de l’architecture.

La Release 19 apporte des améliorations destinées à enrichir les possibilités d’utilisation et à faciliter l’interfonctionnement.

Les travaux ultérieurs portent sur la clarification des comportements protocolaires et l’interopérabilité entre implémentations.

Cette progression illustre une distinction essentielle : une fonction peut être normalisée sans être immédiatement disponible ou interopérable dans les réseaux commerciaux.

9. Quels enjeux pour les opérateurs télécoms ?

Les IMS Data Channels ouvrent des perspectives intéressantes, mais leur déploiement ne dépend pas uniquement de leur faisabilité technique.

Valoriser les services de communication

Les opérateurs peuvent envisager des services enrichis, pour les relations entre entreprises et clients.

L’appel téléphonique devient potentiellement un environnement d’interaction intégrant voix, vidéo et données applicatives.

Assurer l’interopérabilité

Les services doivent fonctionner entre différents terminaux, infrastructures IMS et fournisseurs d’équipements.

Les travaux de clarification des spécifications sont donc particulièrement importants pour les déploiements multi-constructeurs.

Garantir la sécurité

Les IMS Data Channels introduisent de nouveaux échanges applicatifs et de nouvelles interfaces.

La protection des données, l’authentification, la sécurité des applications et la maîtrise des interactions avec les serveurs tiers constituent des exigences essentielles.

Prendre en compte l’interception légale

L’interception légale (Lawful Interception) représente un enjeu réglementaire majeur.

Les Data Channels peuvent transporter des contenus applicatifs protégés par DTLS, avec différents modèles de terminaison de la sécurité.

Ces mécanismes soulèvent des questions sur les capacités d’interception et la fourniture des informations légalement requises.

La spécification 3GPP TS 33.328 traite de la sécurité du plan média IMS, mais ne définit pas elle-même l’architecture d’interception légale.

Des propositions discutées dans les groupes de normalisation soulignent la nécessité de clarifier et de compléter les mécanismes applicables aux IMS Data Channels.

Ces positions doivent être distinguées des exigences définitivement adoptées : elles reflètent des travaux de normalisation en cours.

Pour les opérateurs soumis à des obligations d’interception légale, cette question peut constituer un frein important au déploiement commercial tant que les mécanismes de conformité ne sont pas suffisamment définis et implémentés.

Construire un modèle économique viable

Enfin, l’intérêt technologique ne garantit pas l’adoption commerciale.

Les opérateurs doivent également évaluer les investissements nécessaires, les capacités des terminaux, les besoins réels des utilisateurs et les modèles de partenariat avec les fournisseurs d’applications.

Le déploiement de NG-RTC dépend donc autant de la maturité de l’écosystème que des possibilités offertes par les spécifications.

Conclusion : du service téléphonique à la plateforme de communication interactive

Le MMTEL AS a joué un rôle essentiel dans la modernisation de la téléphonie mobile en permettant de fournir des services téléphoniques avancés sur une architecture IMS entièrement IP.

Avec NG-RTC et les IMS Data Channels, cette architecture franchit une nouvelle étape.

L’appel téléphonique peut désormais devenir un environnement de communication intégrant des interactions applicatives, des échanges de données et de nouveaux services multimédias.

Cette évolution ne remet pas en cause les principes fondamentaux de l’IMS.

Au contraire, l’IMS Application Server conserve un rôle central dans la coordination des services, tandis que de nouvelles fonctions spécialisées prennent en charge le contrôle des Data Channels, les ressources média et les applications.

Pour les opérateurs, l’enjeu est désormais de transformer ces possibilités techniques en services interopérables, sécurisés, conformes aux exigences réglementaires et économiquement viables.

NG-RTC ne remplace pas la téléphonie IMS : il en élargit les possibilités.

Références techniques

  • 3GPP TS 23.228 — IP Multimedia Subsystem (IMS), annexe AC relative aux IMS Data Channels.
  • 3GPP TS 24.186 — IMS Data Channel, procédures et protocoles.
  • 3GPP TS 29.175 — Interfaces de services pour les fonctions IMS Data Channel.
  • 3GPP TS 33.328 — Sécurité du plan média IMS.
  • 3GPP TR 26.814 — Étude des améliorations IMS Data Channel.
  • GSMA RCC.20 — Enriched Calling.
  • GSMA NG.134 — IMS Data Channel.
  • RFC 4975 — Message Session Relay Protocol.
  • RFC 8831 — WebRTC Data Channels.

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

Posté le by - 70 vues
Répondre

Introduction

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

En NTN : quand c’est la cellule qui bouge

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

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

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

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

En résumé

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

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

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

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

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

Posté le by - 184 vues
Répondre

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 ?

Posté le by - 104 vues
Répondre

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

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

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

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

Il faut pouvoir déterminer :

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

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

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

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

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

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

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

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

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

Deux problématiques complémentaires apparaissent alors :

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

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

2. Architecture générale EDGEAPP

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

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

Le terminal utilisateur (UE) héberge :

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

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

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

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

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

  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 ?

Posté le by - 141 vues
Répondre

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

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

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

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

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

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

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

Le 3GPP définit notamment :

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

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

De manière très simplifiée :

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

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

2. Pourquoi AEAD pour la 6G ?

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

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

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

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

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

Et les « Associated Data » ?

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

Prenons un exemple volontairement simplifié :

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

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

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

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

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

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

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

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

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

Le principe général est le suivant :

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

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

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

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

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

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

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

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

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

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

Rocca-S

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

SNOW-Axn

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Et avec les réseaux NTN ?

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

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

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

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

6. Pourquoi des clés de 256 bits ?

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

Il faut cependant distinguer deux problématiques.

  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

Posté le by - 138 vues
Répondre

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

Posté le by - 111 vues
Répondre

1. L’amplification de puissance au niveau du smartphone

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

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

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

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

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

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

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

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

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

L’étalement DFT-s-OFDM

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

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

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

3 – Frequency-Domain Spectral Shaping (FDSS)

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

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

  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

Posté le by - 218 vues
Répondre

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

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

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

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

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

sans intervention humaine

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

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

1. Pourquoi automatiser le réseau 5G ?

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

L’enjeu est triple :

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

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

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

2.1 Principe général

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

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

2.2 Fonctionnement : collecte, traitement, analytiques

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

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

Les analytiques produites peuvent être de deux natures :

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

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

Release 15 (2019) — La fondation

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

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

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

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

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

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

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

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

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

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

b) Nouvelles fonctions d’infrastructure d’automatisation :

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

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

Figure 2 : Architecture NAE

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

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

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

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

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

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

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

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

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

4. Cas d’usage illustratifs

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

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

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

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

5. Points clés à retenir

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

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

 

Références normatives

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

Source principale :

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

 

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

Posté le by - 494 vues
Répondre

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

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

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

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

Les six scénarios d’usage IMT-2030

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

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

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

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

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

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

Performances du scénario IC (Immersive Communication)

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

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

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

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

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

Performances des scénarios HRLLC et MC

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

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

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

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

Les six nouvelles exigences spécifiques à IMT-2030

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

Exigence composite (scénario IC)

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

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

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

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

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

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

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

Précision de positionnement (scénario ISAC)

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

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

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

Exigence IA (scénario AIAC)

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

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

L’exigence UC couvre deux dimensions complémentaires :

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

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

Distance de liaison (Link Distance)

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

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

La séquence normative est maintenant bien établie :

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

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

Conclusion : ce que ces exigences signifient pour la recherche

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

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

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

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

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

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

Références

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

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

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

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