Archives du mot-clef 5G Core

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 - 75 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

 

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

Posté le by - 110 vues
Répondre

Nous allons voir dans cet article la fonction SCP Service Communication Proxy proposée dans la Rel-16 pour apporter une souplesse dans le déploiement du 5GC et dans la communication entre les fonctions NF.

Dans le cœur de réseau 5G (5GC), tout est service. Une fonction réseau (NF) n’appelle plus forcément une autre NF via une interface point à point figée comme en EPC (S1, S5, S11…) : elle consomme un service exposé en HTTP/2, décrit en JSON, au sein d’une architecture orientée services — la SBA, Service-Based Architecture (3GPP TS 23.501 §7).

Mais « orienté services » ne dit pas comment la requête voyage concrètement entre le consommateur (NFc) et le producteur (NFp). Sur ce point, la 3GPP définit quatre modèles de communication, désignés modèles A, B, C et D (TS 23.501 §7.1.1). Ils se distinguent par une question simple : qui découvre le producteur, qui le sélectionne, et qui route effectivement la requête ?

Le socle commun : le NRF

Avant de comparer les modèles, un mot sur la fonction qui rend tout ça possible : le NRF (Network Repository Function). Chaque instance de NF s’y enregistre avec un profil (NFProfile, TS 29.510 §6.1.6.2) décrivant son type, son statut, les slices qu’elle sert (sNssais), sa charge courante (load), sa capacité configurée (capacity), sa localisation, et bien d’autres attributs. C’est sur cette base que repose toute logique de discovery (trouver les candidats) et de sélection (choisir le bon candidat parmi eux).

Ce qui change d’un modèle à l’autre, c’est seulement la répartition de ces deux tâches — discovery et sélection — entre le consommateur et un composant que l’on n’a pas encore présenté : le SCP.

Modèles A et B : la communication directe

Dans les modèles A et B, le NFc parle directement au NFp, sans intermédiaire de routage.

Modèle A — sans discovery. Le consommateur connaît déjà l’adresse du producteur, configurée statiquement. Aucune interrogation du NRF n’a lieu au moment de l’appel. C’est simple, mais rigide : ça ne tient pas la route dès que les instances NF sont déployées, retirées ou redimensionnées dynamiquement — exactement le genre de souplesse qu’on recherche en environnement cloud-native.

Modèle B — avec discovery, sans SCP. Le consommateur interroge le NRF (Nnrf_NFDiscovery_Request), reçoit une liste de candidats (SearchResult, TS 29.510 §6.2.3), applique lui-même sa logique de sélection (charge, localisation, slice…), puis contacte directement l’instance choisie. La découverte est dynamique, mais chaque NFc doit implémenter sa propre logique de discovery et de sélection — du code répété dans chaque type de NF.

Le SCP : un proxy de service, pas un simple routeur

Les modèles C et D introduisent le SCP (Service Communication Proxy), une fonction réseau à part entière dont le rôle est de gérer l’échange de signalisation entre NFs. Deux déploiements sont possibles : colocalisé avec chaque NF (modèle sidecar, comme dans un service mesh applicatif), ou centralisé comme une entité à part.

Le SCP agit comme un routeur de service et, selon le modèle, comme un agent de sélection : il peut interroger lui-même le NRF pour obtenir les paramètres de sélection (charge, capacité, localisation) d’un ensemble d’instances, et choisir la plus appropriée au moment du routage — une décision mécaniquement plus fraîche que celle prise par un NFc qui aurait mis en cache un résultat de discovery plus ancien (borné par le validityPeriod de la réponse NRF et le heartBeatTimer de chaque instance enregistrée).

Modèle C : le NF consommateur garde la main sur la découverte

Dans le modèle C, le NFc continue d’interroger le NRF et d’appliquer sa propre logique de sélection — exactement comme en modèle B. La différence se situe après : au lieu de contacter directement le producteur, le NFc envoie sa requête au SCP, en indiquant l’adresse cible.

Deux cas se présentent. Si cette adresse pointe vers une instance unique, le SCP se contente de router — un simple relais. Si elle pointe vers un NF Set (un ensemble d’instances interchangeables), le SCP doit lui-même sélectionner une instance dans ce set, en interrogeant si besoin le NRF pour affiner son choix.

Le NFc fait donc toujours le gros du travail de discovery et de sélection, mais délègue le routage réseau au SCP — un point de contrôle centralisé qui apporte de la résilience et de l’observabilité, sans simplifier la logique côté consommateur.

Modèle D : la découverte déléguée

Le modèle D va plus loin : le NFc ne fait ni discovery ni sélection. Il construit sa requête avec uniquement les critères nécessaires — type de NF cible, S-NSSAI, DNN, zone géographique — typiquement transmis via les en-têtes 3gpp-Sbi-Discovery-* en HTTP/2 (TS 29.500), et envoie le tout au SCP.

C’est le SCP qui interroge le NRF, obtient les candidats correspondants, effectue la sélection finale, puis route la requête. Le NFc n’a plus besoin de connaître le NRF ni d’implémenter quoi que ce soit en matière de sélection : toute cette intelligence est centralisée dans le SCP — au prix d’un SCP qui doit être nettement plus robuste et complet.

Quel modèle pour quel déploiement ?

Il n’y a pas de modèle « supérieur » dans l’absolu — seulement des compromis différents.

Le modèle A reste pertinent pour des relations NF figées à petite échelle, là où la complexité d’un NRF ne se justifie pas. Le modèle B convient à des déploiements dynamiques mais de taille modeste, où dupliquer la logique de sélection dans chaque NF reste acceptable. Le modèle C apporte de la résilience et de l’observabilité centralisée sans renoncer à la maîtrise de la sélection côté consommateur — un bon compromis pour des architectures en transition. Le modèle D, enfin, est celui qui s’aligne le mieux avec une approche service mesh à grande échelle : il simplifie radicalement chaque NF, au prix de concentrer une responsabilité critique — et donc une exigence de robustesse accrue — sur le SCP.

En pratique, un même cœur de réseau 5G n’est pas obligé de choisir un seul modèle pour toutes ses interactions : certains flux peuvent rester en communication directe (B) tandis que d’autres transitent par un SCP en mode délégué (D), selon la criticité, la fréquence d’appel, ou la maturité de l’infrastructure de routage déployée par l’opérateur.

Références : 3GPP TS 23.501 §6.3 et §7.1.1 (NF Service Framework) ; TS 29.500 (en-têtes de découverte HTTP/2) ; TS 29.510 (Nnrf_NFDiscovery, schémas NFProfile et SearchResult).