Le cœur 5G n’est plus conçu uniquement pour les communications entre personnes. Les véhicules connectés, usines intelligentes, campus intelligents, services de télémédecine, drones et de nombreuses autres applications verticales ont de plus en plus besoin d’influencer dynamiquement les ressources réseau selon les conditions de service ou d’obtenir auprès de l’opérateur des informations autorisées sur l’état du réseau. Si chaque nouvelle exigence imposait à l’opérateur de modifier manuellement les configurations de l’AMF, du SMF, du PCF, de l’UDM et d’autres fonctions réseau, le déploiement massif de la 5G dans les secteurs verticaux serait extrêmement difficile.

C’est précisément le rôle du NEF, ou Network Exposure Function. Il se place entre le 5GC et les fonctions applicatives, ou AF, et transforme les capacités internes du cœur en interfaces normalisées utilisables par des applications externes. Il assure en parallèle le contrôle de sécurité, la traduction des informations et la transmission de paramètres. Pour les applications tierces, le NEF constitue une passerelle contrôlée vers le cadre de capacités du cœur 5G de l’opérateur, et non une simple passerelle API.

Pourquoi le 5GC a besoin du NEF

Le modèle économique de la 4G était largement orienté B2C : le réseau fournissait la connectivité et les abonnés utilisaient l’Internet mobile pour accéder à différentes applications. Avec la 5G, le modèle s’étend vers le B2B2X. Le réseau doit désormais prendre en charge non seulement les utilisateurs individuels, mais aussi des interactions plus profondes et automatisées avec des plateformes de fabrication, de transport, de campus, de santé et d’autres secteurs verticaux.

Cela pose une question essentielle : comment les applications industrielles peuvent-elles utiliser les capacités réseau de l’opérateur de manière à la fois sécurisée et normalisée ?

Prenons l’exemple d’une entreprise industrielle qui souhaite offrir une QoS plus prévisible aux terminaux de production d’une zone précise ou orienter le trafic applicatif vers un réseau de données local plus proche de l’usine. Sans mécanisme unifié d’exposition des capacités, la plateforme applicative pourrait devoir se connecter directement à plusieurs fonctions du cœur et mettre en œuvre des configurations différentes selon les fournisseurs. Cela augmenterait la complexité d’intégration et exposerait davantage d’interfaces internes du cœur.

Le NEF crée une frontière commune entre les applications industrielles et le 5GC. Un AF externe n’a pas besoin de connaître chaque détail interne de l’AMF, du SMF, du PCF, de l’UDM ou de l’UPF. Il lui suffit de soumettre une demande de service conforme aux normes via le NEF. Celui-ci interagit ensuite avec les fonctions réseau 5GC appropriées et renvoie le résultat à l’application.

Cette approche transforme certaines exigences qui dépendraient autrement d’une coordination manuelle et de configurations statiques en appels de service normalisés, ce qui permet aux opérateurs d’exposer plus automatiquement leurs capacités réseau à leurs partenaires.

Où se situe le NEF dans le 5GC

Le NEF est déployé entre les fonctions réseau du 5GC et les AF. Un AF est une entité fonctionnelle de la couche applicative chargée de la logique métier. Il peut s’agir d’une application de confiance détenue ou gérée par l’opérateur, ou d’une plateforme applicative tierce située hors du domaine de confiance de l’opérateur. Une application tierce ne peut pas bénéficier d’un accès illimité aux fonctions internes du cœur ; les interactions contrôlées passent donc par le NEF.

Du point de vue des interfaces, le NEF relie en pratique deux environnements différents. Vers le nord, il dessert des AF tels que des plateformes vidéo, des plateformes de véhicules connectés et des systèmes de contrôle industriel. Vers le sud, il se connecte aux fonctions internes du 5GC et communique avec des entités comme le SMF, le PCF et l’UDM selon le service demandé.

Le NEF est issu du SCEF utilisé en 4G, mais son périmètre est nettement plus large. Le SCEF était principalement lié à certains cas d’usage IoT, tandis que le NEF du 5GC prend en charge un éventail beaucoup plus étendu d’applications centrées sur l’humain et sur les machines et constitue désormais un élément important du cadre d’exposition de capacités fondé sur les services.

Par conception, le NEF fait bien plus que transférer des messages. Ses principales responsabilités comprennent l’exposition des capacités et événements réseau, le provisionnement sécurisé dans le réseau 3GPP d’informations fournies par des applications externes, la traduction entre formats externes et internes, ainsi que la réception de données provenant d’autres fonctions réseau pour stockage ou réexposition ultérieure si nécessaire.

Certaines informations reçues par le NEF peuvent être stockées dans l’UDR, ce qui évite qu’elles restent liées à une seule instance de NEF. Le NEF peut également prendre en charge les fonctions PFD et fournir ainsi la base d’une détection applicative et d’un traitement des politiques plus précis.

Comment cinq capacités clés sont exposées

La valeur du NEF réside finalement dans les services qu’il peut exposer. Dans les déploiements 5GC concrets, ses principales capacités peuvent être regroupées en cinq domaines : exposition de la QoS, abonnements aux événements réseau, orientation du trafic, provisionnement de paramètres et gestion PFD. Ces fonctions correspondent à certains des besoins d’interaction les plus fréquents entre les applications industrielles et les réseaux des opérateurs.

Exposition des capacités QoS

L’exposition des capacités QoS permet à une application partenaire de demander une qualité de service spécifique pour un flux donné. Par exemple, une application vidéo peut déjà fonctionner sur une session PDU existante. Si l’utilisateur choisit un service vidéo de meilleure qualité, l’AF peut utiliser le NEF pour demander une QoS renforcée pour ce flux de trafic.

Après réception de la demande, le NEF se coordonne avec des fonctions du cœur telles que le PCF. Celui-ci applique ensuite la logique de politique et travaille avec le SMF et d’autres ressources réseau afin d’établir le traitement QoS approprié pour le flux de service.

L’objectif n’est pas simplement d’allouer davantage de bande passante au terminal. Il s’agit de permettre à une application d’exprimer ses exigences de service via une interface normalisée, tout en maintenant les décisions de politique et l’application des ressources réseau sous le contrôle du 5GC.

Mobilité et abonnements aux événements réseau

Un AF tiers peut également utiliser le NEF pour s’abonner à des événements réseau liés au UE, par exemple la perte de connectivité, le retour à l’état joignable, la position actuelle ou la dernière position connue, l’état d’itinérance, les causes d’échec de communication et l’état de livraison des données descendantes.

Ces événements sont détectés par différentes fonctions du cœur. L’AMF peut détecter la joignabilité du UE, la perte de connectivité et certains échecs de communication. L’UDM peut fournir des informations telles que l’état d’itinérance ou certains changements d’association d’identité, tandis que le SMF peut signaler des conditions liées à la livraison de données descendantes.

L’AF n’a pas besoin de se connecter directement à chaque fonction réseau. Il crée plutôt un abonnement aux événements via le NEF. Le NEF établit ensuite l’abonnement interne nécessaire auprès de la fonction concernée. Lorsque l’événement ciblé survient, le cœur informe le NEF, qui transmet la notification à l’AF externe conformément à l’abonnement.

Ce mécanisme est particulièrement utile pour les applications industrielles qui doivent déclencher une logique métier automatisée selon l’état des terminaux. Au lieu d’interroger continuellement le réseau sur l’état du UE, la plateforme externe peut recevoir une notification au moment où l’événement pertinent se produit réellement.

Orientation du trafic

Le NEF peut également recevoir des demandes Traffic Influence provenant d’un AF et orienter le trafic d’un UE ou d’un service donné vers un Local DN, ou Local Data Network. Un Local DN est identifié par un DNAI et est généralement associé à l’edge computing ou à des services déployés régionalement.

Dans une usine automatisée, par exemple, un serveur de contrôle industriel peut être déployé sur un réseau local proche du site de production. La plateforme applicative peut demander via le NEF que le 5GC adapte le chemin du plan utilisateur afin que le trafic des terminaux concernés soit routé vers le Local DN approprié.

Le NEF ne contrôle pas directement l’UPF. Il transmet l’exigence au processus de contrôle des politiques. Le PCF et le SMF prennent ensuite en charge la politique et la configuration du plan utilisateur. Selon la situation, le SMF peut resélectionner l’UPF ou ajouter, remplacer ou retirer des UPF du chemin existant afin de réaliser l’orientation du trafic.

Provisionnement sécurisé de paramètres

Un AF externe peut également utiliser le NEF pour fournir au 5GC certains paramètres liés à l’utilisateur. Cela ne signifie pas que l’application est autorisée à modifier librement les paramètres du cœur. La plage d’informations pouvant être provisionnée est strictement contrôlée.

Parmi les exemples courants figurent Expected UE Behaviour et certains Network Configuration Parameters. Expected UE Behaviour peut décrire les caractéristiques de mobilité attendues d’un terminal, tandis que les paramètres de configuration réseau peuvent contenir le temps de réponse maximal, le délai de transmission descendante acceptable ou le nombre recommandé de paquets descendants à mettre en mémoire tampon lorsque le UE n’est pas joignable.

Le NEF transmet les demandes de paramètres autorisées à l’UDM, qui travaille avec l’UDR pour lire et mettre à jour les données correspondantes. L’AMF ou d’autres fonctions réseau abonnées à ces changements peuvent ensuite recevoir les paramètres mis à jour pour les traitements réseau ultérieurs.

Gestion PFD

PFD, ou Packet Flow Description, peut être compris comme un ensemble de règles utilisées pour la détection d’applications. Un AF tiers peut créer des informations d’identification d’application via le NEF. Les règles obtenues peuvent être stockées dans l’UDR, récupérées par le SMF via le NEF puis transmises à l’UPF pour la détection applicative.

Par rapport à une identification du trafic uniquement à partir de ports ou d’adresses de base, les PFD peuvent décrire des caractéristiques applicatives plus précises. Un service vidéo peut par exemple être identifié par un motif d’URL particulier ou d’autres caractéristiques du trafic, ce qui permet au réseau d’associer plus précisément le trafic aux règles de traitement de politique appropriées.

La véritable valeur technique du NEF

D’un point de vue architectural, le rôle le plus important du NEF n’est pas d’ajouter un nœud de transfert supplémentaire. Son objectif réel est de créer une couche d’exposition des capacités qui soit administrable. Les AF externes voient des interfaces orientées services, tandis que le travail réel à l’intérieur du 5GC reste assuré par des fonctions telles que le contrôle de politique du PCF, la gestion de session du SMF, la gestion des données de l’UDM et le traitement du plan utilisateur par l’UPF.

C’est pourquoi le NEF ne doit pas être considéré comme une passerelle API classique. Il doit comprendre la relation entre les demandes métier externes et les capacités du cœur 3GPP, tout en assurant le contrôle de sécurité, la traduction des informations et la coordination des processus entre les deux côtés.

Le NEF ne remplace pas non plus les autres fonctions réseau. L’application de la QoS dépend toujours du contrôle de politique et de la configuration des ressources de session. Les événements réseau restent détectés par la NF concernée. Les chemins du plan utilisateur sont toujours ajustés par des fonctions telles que le SMF, et les données liées aux utilisateurs continuent d’être gérées par l’UDM et l’UDR. Le rôle du NEF est d’exposer ces capacités internes de manière contrôlée et normalisée.

Cette capacité est particulièrement importante pour les services 5G B2B2X. Les applications industrielles n’ont pas besoin de comprendre toute la topologie interne du 5GC ni de créer des interfaces propriétaires vers chaque fonction réseau. Elles peuvent transmettre leurs besoins réseau via des mécanismes d’exposition normalisés. Parallèlement, l’opérateur conserve la maîtrise de la frontière du cœur tout en transformant certaines capacités réseau en services utilisables par des partenaires de confiance.

En pratique, le NEF aide le cœur 5G à évoluer d’un réseau principalement dédié à la connectivité vers une plateforme capable d’exposer directement des capacités réseau aux applications industrielles.

Questions fréquentes

Tous les AF doivent-ils être déployés hors du réseau de l’opérateur ?

Non. Un AF peut être une application de confiance détenue ou gérée par l’opérateur, ou une application tierce située hors de son domaine de confiance. Les méthodes d’accès et les mécanismes de sécurité peuvent différer selon le type d’AF.

Les données métier sont-elles toujours stockées localement dans le NEF ?

Non. Certaines informations reçues par le NEF peuvent être stockées dans l’UDR puis utilisées par d’autres fonctions réseau ou lors de procédures ultérieures. Le stockage des données ne doit donc pas nécessairement rester lié à une seule instance de NEF.

Un Local DN est-il identique à un UPF ?

Non. Un Local DN est un réseau de données local qui héberge des applications ou services de données spécifiques, tandis que l’UPF est une fonction réseau du plan utilisateur du 5GC. Le trafic peut être acheminé via un chemin UPF approprié vers un Local DN donné, mais les deux remplissent des rôles différents.

L’UPF crée-t-il lui-même les règles PFD ?

Non. Les règles PFD peuvent être fournies par un AF et gérées via le NEF. Le SMF récupère les règles concernées et les transmet à l’UPF afin d’assurer une détection d’application plus précise dans le plan utilisateur.