Procédure de désenregistrement initiée par le réseau dans le cœur 5GC

Un UE 5G peut fonctionner normalement, avec une couverture radio intacte et même une PDU Session active, lorsque l’AMF lui envoie soudainement une Deregistration Request initiée par le réseau. L’UE ne s’est pas éteint et n’a pas envoyé lui-même de Deregistration Request.

Ce comportement n’a rien de contradictoire. Une relation d’enregistrement 5GC ne doit pas nécessairement être terminée par l’UE. Des actions d’exploitation et de maintenance, une indisponibilité prolongée de l’UE, un traitement d’état interne à l’AMF ou le retrait de l’abonnement 5G de l’abonné dans l’UDM peuvent tous conduire le réseau à mettre fin à un enregistrement existant. Lors de l’analyse des traces, les questions les plus importantes ne sont pas simplement de savoir si les ressources UPF ont finalement été supprimées, mais qui a pris en premier la décision de désenregistrer, si l’UE peut encore recevoir la notification, si le réseau exige un nouvel enregistrement et quels messages de signalisation peuvent légitimement ne jamais apparaître.

Qui peut décider qu’un UE enregistré doit quitter le 5GS ?

Le désenregistrement initié par le réseau nécessite d’abord de distinguer « initier » et « déclencher ». La procédure est finalement initiée et exécutée par l’AMF, mais la raison qui la provoque ne provient pas toujours de l’AMF lui-même.

Une première catégorie commence au niveau de l’AMF. Un opérateur peut désenregistrer explicitement un utilisateur pour des opérations de maintenance, une migration d’utilisateur ou un autre objectif de gestion du réseau, forçant un UE actuellement dans l’état RM-REGISTERED à quitter son enregistrement existant. Une autre catégorie est le désenregistrement implicite. Si le réseau ne peut plus confirmer que l’UE est joignable et que les conditions de temporisation correspondantes sont remplies, l’AMF peut commencer à nettoyer le contexte sans attendre que l’UE n’initie quoi que ce soit.

Une troisième voie commence dans l’UDM. Par exemple, si l’opérateur retire l’abonnement au service 5G de l’abonné, l’UDM sait que l’état de l’abonnement a changé. L’UDM n’envoie pas directement de signalisation NAS à l’UE. Il notifie plutôt l’AMF qui dessert actuellement cet UE, puis l’AMF transforme cette décision du cœur de réseau en procédure de désenregistrement initiée par le réseau.

Du point de vue des relations entre fonctions réseau, les principales sources peuvent donc être résumées comme suit :

• initiation explicite par l’AMF : actions d’exploitation et de maintenance, migration d’utilisateur ou autres objectifs de gestion du réseau ;

• désenregistrement implicite de l’AMF : les conditions du temporisateur de désenregistrement ou de joignabilité sont remplies et l’UE ne peut plus être considéré comme normalement enregistré ;

• désenregistrement déclenché par l’UDM : par exemple, l’abonnement de l’utilisateur est retiré et l’UDM demande à l’AMF de désenregistrer l’UE.

Quelle que soit la cause initiale, l’objectif final est le même : l’ancien enregistrement 5GS n’est plus valide et l’UE passe de RM-REGISTERED à RM-DEREGISTERED.

Pourquoi les désenregistrements explicite et implicite semblent-ils si différents dans une trace ?

Les deux procédures retirent finalement l’UE de l’état enregistré, mais leur signalisation peut sembler très différente.

Lors d’un désenregistrement explicite, le réseau peut généralement encore communiquer avec l’UE. L’AMF peut envoyer une Deregistration Request NAS indiquant à l’UE que son enregistrement actuel est en cours de terminaison. Si l’UE reste joignable, il peut renvoyer une Deregistration Accept, après quoi le réseau poursuit la libération du contexte restant et de la connexion de signalisation côté accès.

Le désenregistrement implicite part d’une condition différente. Il survient généralement après que l’UE n’est pas réapparu ou n’a pas répondu pendant suffisamment longtemps pour que le réseau ne puisse plus confirmer sa joignabilité. À ce stade, envoyer une nouvelle Deregistration Request peut être inutile, car l’UE peut déjà être éteint, hors couverture ou autrement déconnecté.

Par conséquent, le désenregistrement implicite peut apparaître simplement comme un nettoyage de contexte côté réseau sans échange complet Deregistration Request → Deregistration Accept.

Il en découle une règle utile pour l’analyse des traces : l’absence d’une Deregistration Request du réseau vers l’UE ne prouve pas qu’aucun désenregistrement initié par le réseau n’a eu lieu. Dans un scénario implicite, le réseau peut justement nettoyer le contexte parce que l’UE n’est plus disponible pour la signalisation.

Comment l’UDM transmet-il à l’AMF une décision de retrait d’abonnement ?

Un changement des droits de service de l’abonné est l’un des exemples les plus clairs de désenregistrement initié par le réseau. Supposons qu’un UE soit déjà enregistré sur un réseau visité et ait établi un service, mais que le réseau d’origine retire ensuite l’abonnement 5G de l’utilisateur. L’UDM constate en premier ce changement d’abonnement, et non le gNB ou l’UE.

L’UDM peut envoyer une Deregistration Notification à l’AMF de service via l’URI de rappel précédemment enregistrée par cet AMF. Dans un cas typique, la notification peut indiquer un motif tel que SUBSCRIPTION_WITHDRAWN et identifier l’Access Type concerné, par exemple 3GPP_ACCESS.

Ce n’est qu’après réception de cette notification que l’AMF entre dans la procédure de désenregistrement réseau orientée vers l’UE. L’AMF peut alors envoyer une Deregistration Request NAS à l’UE via le gNB. Outre l’identité de l’UE et l’Access Type, un champ particulièrement important est re-registration required (nouvel enregistrement requis).

Ce champ indique si le réseau attend de l’UE qu’il exécute un nouveau Registration après le désenregistrement. Il ne faut pas l’interpréter comme signifiant que tout désenregistrement initié par le réseau impose toujours un nouvel enregistrement réussi. Dans certains scénarios, le réseau peut seulement vouloir que l’UE quitte l’AMF actuel ou reconstruise son contexte d’enregistrement. Si l’abonné a réellement perdu son droit au service 5G, la réussite d’un Registration ultérieur constitue une décision distincte.

Après traitement de la notification UDM-vers-AMF, l’AMF renvoie l’accusé correspondant à l’UDM. À ce stade, la chaîne de contrôle est passée de « l’état de l’abonnement a changé » à « l’AMF de service exécute maintenant le désenregistrement ».

Comment les ressources internes sont-elles nettoyées après que le réseau décide de désenregistrer l’UE ?

À partir de ce point, certaines étapes de libération des ressources recoupent celles du désenregistrement initié par l’UE. Il est peu utile de répéter à nouveau chaque message N4, PCF et UDM. Le point le plus important est de comprendre pourquoi ces actions de nettoyage restent nécessaires dans une procédure initiée par le réseau.

L’UE peut déjà disposer d’une ou plusieurs PDU Sessions actives. Dès que l’AMF décide de terminer l’enregistrement, il doit demander aux SMF concernés de libérer ces sessions. Le SMF gère ensuite les ressources du plan utilisateur et les chemins N3 côté UPF et met fin aux relations SM Policy qui ne disposent plus d’un contexte de service valide. Les abonnements ou enregistrements dans l’UDM peuvent également être supprimés selon l’état des sessions restantes.

L’AMF peut lui aussi devoir libérer des relations de politique d’accès et de mobilité, notamment une AM Policy Association et toute UE Policy Association applicable. Sinon, le réseau pourrait se retrouver dans un état incohérent où l’UE n’est plus enregistré mais où le PCF, le SMF ou l’UDM conserve encore des relations suggérant qu’un service actif continue.

La difficulté n’est pas de « supprimer autant que possible ». Le réseau doit comprendre l’Access Type actuel et tout état de service encore valide. Si l’UE reste enregistré via un autre accès ou si un contexte est encore utilisé par une autre session, supprimer tout l’état de l’UE serait incorrect.

Par conséquent, après avoir observé une Deregistration Request initiée par le réseau, le dépannage ne doit pas se concentrer sur la présence d’une séquence identique de 14 messages. Il faut plutôt vérifier si les PDU Sessions qui devaient être libérées l’ont effectivement été, si les relations de politique obsolètes ont été terminées et si le contexte qui doit rester valide a été préservé.

Quelle est la différence entre un désenregistrement explicite par l’AMF et un retrait d’abonnement par l’UDM ?

Les étapes ultérieures de ces deux procédures peuvent sembler très similaires, car elles reposent toutes deux finalement sur l’AMF pour désenregistrer l’UE et peuvent entrer dans la même logique de nettoyage des PDU Sessions et des politiques. Leurs points de départ sont toutefois différents.

Si un opérateur retire explicitement l’UE de l’AMF, la première action importante vient directement de l’AMF. Il n’y a pas de Deregistration Notification préalable de l’UDM. L’AMF connaît déjà la raison opérationnelle du désenregistrement et peut envoyer directement la Deregistration Request à l’UE.

Si le service 5G de l’abonné a été retiré, le point de départ est l’UDM. Avant que l’AMF n’agisse, il reçoit normalement une notification de désenregistrement de l’UDM. Dans des captures multi-NF, cette différence est extrêmement utile, car elle montre qui a décidé en premier que l’enregistrement existant devait être terminé, au lieu de traiter toute la signalisation de nettoyage ultérieure comme un même scénario.

Lors d’une migration AMF ou d’une redistribution des utilisateurs au sein d’un pool d’AMF, l’exigence re-registration dans la Deregistration Request doit également être examinée avec le fait que l’UE entre ou non ensuite dans une nouvelle procédure Registration. Dans ce cas, le désenregistrement peut être une étape du déplacement de l’UE vers un autre AMF de service plutôt qu’une terminaison permanente du service 5G de l’abonné.

Le retrait d’abonnement est différent par nature, car il reflète une modification des droits de l’abonné. Même si la procédure NAS autorise l’UE à tenter de nouveau un Registration, le cœur de réseau évaluera toujours cette tentative en fonction de l’état d’abonnement mis à jour.

Dans une trace, commencez par identifier qui a envoyé le premier message

Le désenregistrement initié par le réseau est plus facile à analyser lorsqu’il est divisé en quatre étapes : origine → notification → nettoyage des ressources → réponse de l’UE.

• Premièrement, identifiez l’origine. Si le premier message pertinent est une Deregistration Notification de l’UDM vers l’AMF, la procédure a été déclenchée par un événement côté UDM. Si l’AMF envoie directement la Deregistration Request à l’UE, il s’agit plus probablement d’un cas explicite initié par l’AMF. Si aucun des deux n’apparaît mais que le réseau commence à supprimer le contexte UE, envisagez un désenregistrement implicite.

• Deuxièmement, vérifiez le sens NAS. Dans un désenregistrement initié par le réseau, la Deregistration Request circule AMF → UE. C’est le sens inverse d’un désenregistrement initié par l’UE. Le nom du message peut être identique, le sens est donc important.

• Troisièmement, vérifiez si l’UE renvoie Deregistration Accept. Lors d’un désenregistrement explicite, si l’UE reste joignable, une réponse est normalement visible. Lors d’un désenregistrement implicite, l’UE peut déjà être injoignable, cette étape peut donc être absente.

• Quatrièmement, vérifiez les ressources internes. Si l’UE avait auparavant des PDU Sessions, vérifiez si les ressources correspondantes du SMF et de l’UPF ont été libérées. Si la procédure provient de l’UDM ou implique un état de politique, vérifiez également les relations UDM et PCF.

Une séquence pratique d’analyse est la suivante :

1. Identifier quelle NF a initié ou déclenché la procédure ;

2. Confirmer le sens de la Deregistration Request et l’Access Type ;

3. Vérifier si re-registration required correspond au scénario ;

4. Déterminer si l’UE renvoie Deregistration Accept ;

5. Vérifier la libération des PDU Sessions existantes et des ressources du plan utilisateur ;

6. Enfin, confirmer que l’état d’enregistrement de l’UE a quitté RM-REGISTERED.

Cette approche est plus proche du dépannage réel que de comparer mécaniquement si un message HTTP/2 manque dans un flux de référence numéroté. Le désenregistrement initié par le réseau peut avoir plusieurs causes, de sorte que différents scénarios peuvent différer dès le premier message.

FAQ

Le désenregistrement initié par le réseau envoie-t-il toujours une Deregistration Request à l’UE ?

Non. Lors d’un désenregistrement explicite, si l’UE est joignable, l’AMF envoie normalement une Deregistration Request. Le désenregistrement implicite se produit souvent après que l’UE est resté injoignable pendant une période prolongée, de sorte que le réseau peut nettoyer directement le contexte d’enregistrement sans qu’une Deregistration Request NAS apparaisse dans la trace.

L’UDM peut-il désenregistrer directement l’UE ?

L’UDM est principalement responsable des données d’abonné et d’abonnement. Des événements tels que le retrait d’abonnement peuvent déclencher un désenregistrement, mais l’AMF de service reste la fonction réseau qui exécute la Deregistration Request initiée par le réseau vers l’UE. L’analyse des traces doit distinguer entre déclenché par l’UDM et initié par l’AMF pour le désenregistrement.

Si re-registration required est défini sur 1, cela signifie-t-il que l’UE réussira nécessairement à s’enregistrer de nouveau ?

Non. Ce champ indique que le réseau exige de l’UE qu’il exécute de nouveau Registration, mais l’acceptation du nouvel enregistrement dépend des droits de l’abonné, des restrictions d’accès, de la politique réseau et de la raison du désenregistrement initial. Si l’abonnement a été retiré, une nouvelle tentative de Registration ne garantit pas que le 5GC acceptera l’UE.

Les étapes de libération des ressources sont-elles complètement différentes de celles du désenregistrement initié par l’UE ?

Non. Le sens de déclenchement est différent, mais une fois que le réseau décide de terminer l’enregistrement, le nettoyage des PDU Sessions existantes, des ressources UPF et des relations de politique peut largement recouper celui du désenregistrement initié par l’UE. Les différences les plus utiles sont de savoir qui a lancé la procédure, le sens du message NAS, si une confirmation UE est attendue et si un nouvel enregistrement est requis.