Dans le cœur 5G, l’AMF détient des informations de mobilité de première main sur l’UE, notamment sa zone de suivi actuelle, son état de joignabilité, les changements d’enregistrement, l’état CM et les changements de type d’accès. Lorsque des fonctions réseau telles que le SMF, le NEF ou l’UDM ont besoin de ces informations, interroger continuellement l’AMF ne fournit qu’un instantané à un moment donné et ne permet pas de capter efficacement les changements d’état. Namf_EventExposure résout ce problème en transformant les informations de mobilité gérées par l’AMF en services d’événements auxquels d’autres fonctions réseau peuvent s’abonner afin de recevoir des notifications continues.

• Nom du service : Namf_EventExposure

  Modèle principal : Abonnement aux événements + notification des changements d’état

  Consommateurs typiques : SMF, NEF, UDM

  Contexte de version : Basé sur les définitions pertinentes de 3GPP Release 15.6

Rôle et limites du service

Namf_EventExposure est un service AMF qui expose à d’autres fonctions réseau des événements liés à la mobilité. Comme l’AMF assure la gestion de l’accès et de la mobilité, elle conserve directement des informations telles que la localisation de l’UE, son état d’enregistrement et son état de gestion de connexion. Les autres fonctions réseau n’ont pas à recréer la même logique de détermination d’état. Elles peuvent utiliser ce service pour déclarer les événements qui les intéressent, tandis que l’AMF détermine leur occurrence et envoie une notification lorsque les conditions configurées sont satisfaites.

L’abonnement à un événement est fondamentalement différent d’une requête d’état classique. Une requête répond à « Quel est l’état actuel ? », alors qu’un abonnement répond à « Quand l’état change-t-il ? ». Par exemple, le SMF n’a pas besoin d’interroger continuellement l’AMF pour savoir si un UE est joignable ; il peut simplement être averti lorsque l’UE passe de joignable à non joignable. Le NEF peut uniquement vouloir savoir si un UE entre dans une zone définie, tandis que l’UDM peut s’intéresser aux changements d’enregistrement ou de joignabilité. exposition d’événements fournit donc un échange asynchrone, piloté par des conditions, uniquement lorsque l’information est nécessaire.

L’AMF ne diffuse pas indistinctement toutes ses informations internes. Les événements sont exposés selon des relations d’abonnement établies. Le consommateur, l’UE cible, le type d’événement et l’URI de notification définissent ensemble la portée d’un abonnement. Cette approche réduit la signalisation inutile tout en permettant à chaque fonction réseau de ne s’abonner qu’aux informations de mobilité pertinentes pour sa propre logique de service.

Types d’événements et paramètres clés

L’AMF peut exposer des événements couvrant plusieurs aspects de la mobilité, de l’enregistrement, de la connectivité et de la joignabilité de l’UE. Plutôt que de mémoriser chaque événement séparément, il est plus simple de les regrouper en trois catégories : événements de localisation et de zone, événements d’enregistrement et d’état d’accès, et événements de joignabilité ou d’exception.

Événements de localisation et de zone

Le rapport de localisation de l’UE est l’un des types d’événements les plus directs. Un consommateur peut s’abonner aux changements de localisation d’un seul UE ou d’un groupe d’UE, les notifications pouvant contenir des informations telles que le TAI et l’identifiant de cellule. Le rapport AOI, ou rapport de zone d’intérêt, se concentre sur la relation entre l’UE et une zone prédéfinie, par exemple pour indiquer si l’UE est entré dans cette zone, l’a quittée ou se trouve dans un état inconnu.

Le rapport AOI est particulièrement utile lorsqu’une application n’a pas besoin de mises à jour permanentes de localisation précise et doit seulement savoir si un UE se trouve dans une zone définie. Par exemple, si l’application doit uniquement déterminer si un UE entre dans une zone composée de TA1 et TA2, il n’est pas nécessaire de produire continuellement des notifications de localisation tant que l’UE reste dans cette zone. Un rapport n’est requis que lorsque l’UE entre dans la région configurée ou en sort.

États d’enregistrement, d’accès et de connexion

Le rapport d’état d’enregistrement distingue les états REGISTERED et DEREGISTERED, tandis que le rapport de gestion de connexion indique si l’UE est en CM-IDLE ou CM-CONNECTED. Ces deux états ont des significations différentes pour les fonctions réseau qui doivent déterminer si une communication de plan utilisateur ou de signalisation peut être établie immédiatement.

L’AMF peut également exposer les changements de type de réseau d’accès de l’UE, par exemple les transitions entre accès 3GPP et non-3GPP, ainsi que les changements de fuseau horaire actuel de l’UE. Ces paramètres ne nécessitent généralement pas de sondage fréquent, mais leur modification peut affecter des décisions de politique ou le traitement d’un service. Ils sont donc bien adaptés au modèle d’abonnement aux événements.

Événements de joignabilité et d’exception

Le rapport de joignabilité indique si l’AMF considère que l’UE est joignable par le réseau. Les résultats possibles comprennent joignable, injoignable et REGULATORY-ONLY. REGULATORY-ONLY signifie que l’UE n’est joignable que pour des services prioritaires imposés par la réglementation. Il ne faut pas confondre joignabilité et état de connexion : un UE en CM-IDLE peut rester joignable, même si une procédure de recherche du terminal peut être nécessaire avant le rétablissement d’une connexion.

Les événements d’exception décrivent des échecs ou une perte de communication. Les rapports d’échec de communication peuvent inclure des valeurs de cause de libération de connexion RAN ou NAS. Un rapport de perte de communication peut être généré lorsque l’AMF détermine, par exemple après l’expiration d’un temporisateur de joignabilité mobile, que la communication avec l’UE a été perdue, ce qui permet à l’abonné de recevoir l’identifiant UE correspondant.

Outre les événements associés à un UE individuel ou à un groupe d’UE, l’AMF peut exposer des statistiques sur le nombre d’UE dans une zone donnée. Dans ce cas, le consommateur s’intéresse au nombre total d’UE présents dans la région plutôt qu’à l’état d’un abonné particulier. Cela montre qu’exposition d’événements ne se limite pas aux notifications par UE et peut également fournir des informations statistiques liées à la mobilité.

Abonnement, mise à jour et notification

Namf_EventExposure organise les changements d’état autour d’un cycle de vie complet d’abonnement. Une fonction réseau consommatrice crée d’abord un abonnement et l’AMF enregistre cette relation. Si le consommateur doit ensuite modifier les conditions de l’événement, l’abonnement peut être mis à jour. Lorsqu’il n’est plus nécessaire, il peut être supprimé. Les résultats réels de l’événement sont ensuite transmis par l’AMF à l’adresse de notification configurée.

Pour créer un abonnement, le consommateur envoie une requête POST pour un nouvel abonnement. Si la requête réussit, l’AMF renvoie les informations de l’abonnement créé ainsi qu’un identifiant pouvant être référencé lors d’opérations ultérieures. Si le consommateur doit modifier les conditions de l’événement, il peut utiliser PATCH sur l’abonnement concerné au lieu de le supprimer et de le recréer. Lorsque l’événement n’est plus nécessaire, le consommateur envoie DELETE pour supprimer la relation d’abonnement ; l’AMF cesse alors d’envoyer des notifications pour cet abonnement.

Notify est l’étape essentielle qui transmet le changement d’état réel. Lorsque la condition de l’événement souscrit est satisfaite, l’AMF envoie par POST une notification d’événement vers l’eventNotificationUri enregistré dans l’abonnement. Une fois la notification traitée par le consommateur et la réponse renvoyée, la transaction de notification est terminée. Une séquence typique peut être résumée comme suit :

1. Le consommateur identifie l’UE et l’événement qu’il souhaite surveiller ;

2. L’AMF crée et maintient le contexte d’abonnement ;

3. L’AMF continue de suivre l’état de mobilité concerné ;

4. Lorsque la condition de l’événement est remplie, l’AMF envoie une notification ;

5. Le consommateur traite l’événement et exécute la logique de service requise ;

6. L’abonnement est mis à jour ou supprimé lorsque les exigences du service évoluent.

Le reporting peut être configuré en mode ponctuel ou continu. Un rapport ponctuel convient lorsque le consommateur a seulement besoin du résultat actuel ou d’une seule occurrence d’événement. En mode continu, l’abonnement reste actif et les changements d’état ultérieurs correspondant aux conditions configurées peuvent déclencher d’autres notifications. D’un point de vue d’ingénierie, « quel événement est souscrit » et « combien de rapports sont nécessaires » doivent donc être considérés comme deux paramètres distincts.

Perspective d’ingénierie et conclusion

Du point de vue de l’architecture basée sur les services de la 5GC, Namf_EventExposure clarifie une frontière de responsabilité : quelle fonction réseau détecte un état et quelle fonction le consomme. Comme l’AMF possède déjà les informations de gestion de mobilité, il est plus efficace qu’elle les expose via un mécanisme d’événements normalisé plutôt que de laisser le SMF, le NEF ou l’UDM réinférer sans cesse le même état UE au moyen de signalisation supplémentaire.

C’est également pourquoi le modèle d’abonnement convient particulièrement à l’exposition d’événements. La localisation, l’enregistrement, l’état de connexion et la joignabilité de l’UE sont des informations orientées état. La plupart du temps, ces valeurs ne changent pas, mais lorsqu’elles évoluent, elles peuvent immédiatement influencer le comportement d’une autre fonction réseau. Un sondage continu générerait une grande quantité de signalisation pour une faible valeur opérationnelle, alors que l’abonnement et la notification permettent de transmettre l’information uniquement lorsqu’un événement réel se produit.

Lors de l’analyse pratique de la signalisation Namf_EventExposure, quatre éléments sont particulièrement importants : quelle NF a créé l’abonnement, quel événement a été demandé, quel UE ou quelle zone est surveillé et où la notification est envoyée. En suivant l’ID d’abonnement avec l’eventNotificationUri, il est généralement possible de reconstituer toute l’interaction, depuis la création et la modification de l’abonnement jusqu’au message Notify final.

La façon la plus efficace de comprendre Namf_EventExposure consiste à construire un modèle simple : l’AMF maintient l’état de mobilité, le consommateur déclare son intérêt, l’abonnement établit la relation et Notify transmet le résultat lorsque l’état change. Une fois ce modèle compris, les événements spécifiques tels que la localisation, l’AOI, l’enregistrement, l’état de connexion et la joignabilité deviennent beaucoup plus faciles à interpréter.

FAQ

Quelle est la différence fondamentale entre Namf_EventExposure et une interrogation directe de l’AMF ?

Une requête directe récupère l’état à un instant précis. exposition d’événements établit un intérêt à l’avance et permet à l’AMF de notifier le consommateur lorsque l’état concerné change. La première méthode convient aux requêtes ponctuelles, la seconde à une surveillance continue des événements.

Un même consommateur peut-il s’abonner aux événements de plusieurs UE ?

Oui. La portée cible prise en charge dépend du type d’événement. Certains événements peuvent concerner un seul UE ou un groupe d’UE, tandis que des statistiques comme le nombre d’UE dans une zone déterminée peuvent s’appliquer à un nombre quelconque d’UE.

CM-IDLE signifie-t-il que l’UE est injoignable ?

Non. L’état CM décrit l’état de gestion de connexion de l’UE, tandis que la joignabilité indique si le réseau peut atteindre l’UE. Un UE en CM-IDLE peut rester joignable, même si la communication nécessite généralement de rétablir d’abord la connexion.

Pourquoi la notification d’événement nécessite-t-elle une URI de rappel distincte ?

La création de l’abonnement et l’occurrence de l’événement ne se produisent pas nécessairement au même moment. Le consommateur fournit une URI de notification lors de la création de l’abonnement, ce qui permet à l’AMF d’envoyer ultérieurement un message Notify lorsque la condition configurée est satisfaite, sans maintenir ouverte la connexion de la requête initiale.