Un UE peut rester absent du réseau suffisamment longtemps pour que les conditions du temporisateur de désenregistrement implicite de l’AMF soient remplies. À ce stade, il ne s’agit plus de savoir comment l’UE termine son enregistrement, et il peut même être impossible de lui transmettre un message NAS de désenregistrement. Le réseau doit plutôt décider du traitement des données d’abonnement, du contexte de gestion de mobilité et des états d’abonnement et d’enregistrement dans l’UDM que l’AMF conserve encore pour cet UE.
Cette phase de nettoyage est assurée par la purge de l’AMF (AMF Purge). La norme 3GPP définit cette procédure sous le nom de Purge of Subscriber Data in AMF (purge des données d’abonné dans l’AMF). Après le désenregistrement implicite ou explicite de l’UE, l’AMF peut supprimer les Subscriber Data et le MM Context enregistrés localement et mettre fin aux relations correspondantes entretenues avec l’UDM.
L’analyse d’une purge ne doit donc pas recommencer à Registration Request, Authentication ou Registration Accept. Il faut examiner comment les états d’enregistrement devenus obsolètes sont nettoyés entre l’AMF et l’UDM une fois que la relation d’enregistrement a déjà pris fin.
Différence entre purge, enregistrement et désenregistrement déclenché par le réseau
La purge est parfois confondue avec le désenregistrement, car elle peut suivre une condition de désenregistrement implicite. Ce sont pourtant deux procédures distinctes.
| Procédure | Objectif principal | Signalisation typique à vérifier |
|---|---|---|
| Enregistrement initial | Établir la relation d’enregistrement entre l’UE et le 5GS | Registration Request / Accept |
| Désenregistrement déclenché par le réseau | Mettre fin à une relation d’enregistrement 5GS existante | Deregistration Request et signalisation de nettoyage associée |
| Purge de l’AMF | Supprimer de l’AMF les données d’abonné obsolètes et le MM Context, puis nettoyer l’état correspondant dans l’UDM | SDM Unsubscribe et UECM Deregistration |
Lors d’un désenregistrement implicite, l’UE peut être injoignable depuis longtemps. La procédure de purge elle-même ne nécessite donc pas sa participation. L’absence de messages NAS d’enregistrement ou de désenregistrement côté UE dans une trace ne signifie pas qu’aucune purge n’a eu lieu.
Plus précisément, le désenregistrement établit que l’UE ne maintient plus sa relation d’enregistrement 5GS actuelle, tandis que la purge supprime les états résiduels de l’AMF et de l’UDM liés à cette relation.
Pour comprendre pourquoi le réseau met fin à l’enregistrement d’un UE, consultez la procédure de désenregistrement déclenché par le réseau dans le cœur 5GC. La purge poursuit ensuite le nettoyage effectué côté AMF.
Déclencheurs et périmètre du nettoyage lors d’une purge de l’AMF
Un déclencheur courant apparaît lorsque les conditions des temporisateurs de l’AMF utilisés pour le désenregistrement implicite sont réunies. Le réseau ne peut plus considérer l’UE comme normalement enregistré et procède au nettoyage du contexte restant.
L’AMF doit principalement traiter deux catégories d’état.
La première concerne les Subscriber Data (données d’abonné). Lors de l’enregistrement de l’UE, l’AMF peut récupérer auprès de l’UDM des données d’abonnement relatives à l’accès et à la gestion de mobilité, puis les stocker localement. Il peut également créer une SDM Subscription afin que l’UDM lui signale toute modification pertinente de ces données.
La seconde est le MM Context (contexte de gestion de mobilité). Celui-ci contient les informations utilisées par l’AMF pour gérer l’enregistrement et la mobilité de l’UE. Dès lors que l’UE n’entretient plus la relation d’enregistrement actuelle, ce contexte local ne doit pas rester alloué indéfiniment.
La purge supprime donc un ancien état au lieu d’en créer un nouveau. Le nettoyage comprend généralement les opérations suivantes :
Annuler auprès de l’UDM l’abonnement de l’AMF aux données d’abonné ;
Désenregistrer dans l’UDM l’enregistrement UECM de l’AMF ;
Supprimer les données d’abonné de l’UE et le MM Context stockés localement dans l’AMF ;
Mettre en cohérence l’état d’enregistrement de l’UE stocké dans l’AMF avec son état réel de désenregistrement.
Signalisation SDM Unsubscribe et UECM Deregistration
Dans les traces SBI, la séquence principale de signalisation de la purge de l’AMF est relativement courte et se concentre sur les échanges entre l’AMF et l’UDM.
Annulation de l’abonnement SDM
L’AMF doit d’abord supprimer l’abonnement aux données d’abonné créé précédemment. Dans une trace HTTP/2, une opération semblable à la suivante peut être observée :
DELETE /nudm-sdm/v2/{SUPI}/sdm-subscriptions/{subscriptionId}
L’UDM utilise le Subscription ID pour identifier et supprimer la relation d’abonnement correspondante. Après cette suppression, les modifications ultérieures des données de l’UE ne sont plus notifiées à cet AMF au moyen de l’abonnement supprimé.
En fonctionnement normal, l’UDM peut renvoyer 204 No Content pour indiquer que l’abonnement a bien été supprimé.
Désenregistrement de l’AMF dans UECM
L’AMF doit ensuite mettre à jour son état d’enregistrement dans l’UECM de l’UDM. Dans une trace réseau réelle, cela peut apparaître comme une mise à jour de la ressource AMF 3GPP Access Registration, la requête transportant le GUAMI ainsi que PurgeFlag=true.
L’UDM vérifie l’enregistrement AMF concerné à partir des informations reçues. Si le GUAMI correspond aux données enregistrées pour l’AMF de service, l’état de purge est reflété dans les informations d’enregistrement, ce qui indique que cet AMF a effectué le désenregistrement et le nettoyage nécessaires pour l’UE.
Après traitement réussi, l’UDM peut à nouveau renvoyer 204 No Content. À ce stade, les deux relations principales entre l’AMF et l’UDM ont été nettoyées :
La SDM Subscription a été supprimée ;
le traitement de désenregistrement/purge de l’AMF Registration dans UECM est terminé.
Enfin, l’AMF supprime le contexte UE stocké localement et fait passer l’état de gestion de l’enregistrement correspondant à RM-DEREGISTERED.
Points à contrôler dans une trace de purge de l’AMF
Le dépannage d’une purge de l’AMF ne doit pas débuter par Registration Request ; il n’est généralement pas nécessaire non plus de commencer par le gNB ou l’UPF. La question centrale est la cohérence des états entre l’AMF et l’UDM.
Les points de vérification utiles sont les suivants :
SDM Subscription : vérifier que l’AMF envoie Unsubscribe avec le bon SUPI et le bon Subscription ID ;
UDM Response : confirmer que la suppression SDM aboutit et que l’UDM retire la relation d’abonnement initiale ;
UECM Registration : vérifier que l’AMF effectue Deregistration pour le bon Access Type et l’enregistrement UE correspondant ;
GUAMI : confirmer que le GUAMI transporté dans la requête correspond aux informations de l’AMF de service conservées dans l’UDM ;
PurgeFlag : confirmer que la requête identifie correctement l’opération comme une purge ;
AMF Local Context : après les opérations côté UDM, vérifier que l’AMF supprime effectivement les Subscriber Data et le MM Context concernés.
Si la SDM Subscription a déjà été supprimée alors que l’AMF conserve l’ancien MM Context, le problème se situe probablement dans le nettoyage local de l’AMF. Si SDM Unsubscribe échoue lui-même, il faut ensuite vérifier le Subscription ID, le SUPI et la relation d’abonnement correspondante stockée dans l’UDM.
Il ne faut donc pas déterminer l’achèvement de la purge à partir de la seule présence d’un message NAS particulier. Un critère plus fiable consiste à vérifier que le contexte local de l’AMF, l’abonnement aux données dans l’UDM et l’état d’enregistrement UECM sont tous cohérents avec le fait que l’UE n’est plus enregistré.
Foire aux questions
La purge de l’AMF est-elle identique au désenregistrement implicite ?
Pas exactement. Un désenregistrement implicite peut être suivi d’une purge, mais cette dernière désigne plus précisément le nettoyage des Subscriber Data et du MM Context par l’AMF après le désenregistrement, ainsi que la suppression de l’abonnement SDM et de l’enregistrement UECM correspondants dans l’UDM.
La purge de l’AMF exige-t-elle l’envoi d’un message NAS par l’UE ?
Pas nécessairement. Lors d’un désenregistrement implicite, l’UE peut déjà être injoignable. La signalisation essentielle de la purge s’effectue entre l’AMF et l’UDM ; une trace peut donc ne contenir aucun Registration Request ou Deregistration Request côté UE.
À quoi sert Nudm_SDM_Unsubscribe ?
Cette opération supprime l’abonnement aux données d’abonné que l’AMF avait précédemment créé pour cet UE. Une fois l’abonnement annulé, l’UDM ne transmet plus à cet AMF de notifications de modification des données d’abonné par l’intermédiaire de l’abonnement supprimé.
Quel est le rôle de PurgeFlag ?
Pendant la purge, UECM Deregistration peut comporter une indication associée à cette opération pour informer l’UDM que l’AMF nettoie la relation d’enregistrement correspondante. Dans l’analyse des traces, PurgeFlag doit être interprété conjointement avec le GUAMI et l’UECM Registration concernée.
Pourquoi ne réalise-t-on pas un nouvel enregistrement pendant la purge ?
La purge nettoie une ancienne relation d’enregistrement déjà terminée ; elle n’en établit pas de nouvelle. Si l’UE accède ultérieurement de nouveau au 5GS, il suit la procédure Registration appropriée à l’état courant de l’UE et du réseau. Il s’agit d’une séquence de signalisation distincte.
