Lors d’un dépannage sur site, une erreur fréquente consiste à voir un RRC Release et à considérer que le désenregistrement de l’UE est déjà terminé. La connexion radio peut effectivement avoir disparu et l’UE peut avoir cessé d’envoyer des données, mais le contexte d’enregistrement dans l’AMF, la session PDU dans le SMF, la session N4 dans l’UPF, les associations de politique dans le PCF et les enregistrements dans l’UDM ne disparaissent pas tous au même instant simplement parce que « le signal a disparu ». Dans une trace de signalisation, ce qui compte est la chaîne de nettoyage inter-NF qui suit le Deregistration Request : comment l’AMF détermine la portée du désenregistrement, comment le SMF demande à l’UPF de supprimer les ressources du plan utilisateur et jusqu’où les associations PCF et UDM doivent être libérées.
Le désenregistrement initié par l’UE est la procédure contrôlée qui retire du 5GS un UE déjà enregistré. Elle commence par un NAS Deregistration Request et peut impliquer la libération de sessions PDU, la suppression des sessions N4 et des tunnels de plan utilisateur dans l’UPF, la terminaison des associations SM Policy et AM Policy, la suppression de l’état d’enregistrement correspondant dans l’UDM, puis la libération de la connexion de signalisation entre l’UE et le réseau d’accès. Le désenregistrement normal et la mise hors tension peuvent se ressembler au début de la procédure, mais leur fin est différente : l’un attend un Deregistration Accept, tandis que l’autre ne reste pas connecté uniquement pour recevoir une confirmation. Cette différence est facile à manquer dans l’analyse des traces.
Pourquoi le désenregistrement ne se résume-t-il pas à marquer l’UE hors ligne ?
Après qu’un UE a terminé l’Initial Registration et établi une session PDU, le 5GC ne conserve pas un simple indicateur « en ligne ». L’AMF maintient le contexte d’enregistrement et de mobilité, le SMF gère le contexte de session PDU, l’UPF conserve la session N4 avec des ressources de transfert du plan utilisateur telles que FAR, QER et URR, l’UDM stocke les relations d’enregistrement AMF et SMF, et le PCF peut maintenir des associations de politique AM, UE ou SM.
Si l’UE disparaît simplement du réseau, ces ressources ne sont pas automatiquement supprimées exactement au même moment. Cela est particulièrement important lorsqu’une ou plusieurs sessions PDU existent encore. Le réseau doit savoir quelles sessions doivent être libérées, quelles règles du plan utilisateur doivent être supprimées et quels abonnements ou associations de politique n’ont plus de raison d’être conservés.
Le désenregistrement initié par l’UE effectue donc un démantèlement ordonné de l’état d’enregistrement et de ses ressources associées:
L’UE indique que l’enregistrement 5GS actuel doit prendre fin
→ L’AMF détermine la portée du désenregistrement
→ Les sessions PDU associées sont libérées
→ Le SMF demande à l’UPF de supprimer les ressources du plan utilisateur
→ Les associations de session et de politique sont supprimées
→ L’état d’enregistrement est supprimé
→ La connexion de signalisation côté accès est libérée
C’est pourquoi le désenregistrement ne doit pas être confondu avec RRC Release ni avec une libération ordinaire de connexion N2. Une libération de connexion RAN signifie seulement que la connexion de signalisation d’accès actuelle est terminée. Le désenregistrement agit à un niveau supérieur et supprime la relation d’enregistrement 5GS ainsi que les états de session et de politique associés. Si une trace ne montre qu’un RRC Release, conclure que l’UE est déjà désenregistré peut facilement confondre « libération de la connexion d’accès » et « suppression de l’enregistrement ».
Comment le Deregistration Request définit-il la manière et l’accès par lesquels l’UE quitte le réseau ?
Lorsque l’UE quitte activement le 5GS, il envoie à l’AMF un NAS Deregistration Request. Pour l’analyse de la signalisation, les premiers éléments à vérifier ne sont pas la présence ultérieure de messages PFCP, mais le Deregistration type et l’Access Type transportés dans la requête.
Le Deregistration type indique d’abord au réseau si la procédure correspond à un cas de mise hors tension. En termes d’ingénierie, le désenregistrement initié par l’UE apparaît généralement dans deux situations : le désenregistrement normal, dans lequel l’UE quitte le réseau de manière ordonnée, et la mise hors tension, dans laquelle l’UE indique qu’il va s’éteindre ou entrer dans un état équivalent d’arrêt.
Access Type répond à une autre question : quel accès est réellement désenregistré. L’UE peut se désenregistrer uniquement de l’accès 3GPP, uniquement de l’accès non-3GPP ou, lorsque les deux types d’accès du même PLMN sont desservis par le même AMF, la procédure peut couvrir les deux selon le cas. Ainsi, « désenregistrement de l’UE » ne signifie pas toujours que tous les états d’accès associés à cet UE sont supprimés en une seule fois.
Le Deregistration Request transporte également des informations d’identité de l’UE. Lorsqu’un 5G-GUTI valide est disponible, l’UE peut l’utiliser pour aider l’AMF à associer le message NAS au contexte UE existant. Si aucun 5G-GUTI valide n’est disponible, le traitement de l’identité dépend de l’identité 5GS actuellement disponible pour l’UE. Du point de vue de l’AMF, l’association correcte de ce message NAS au contexte UE existant est une condition préalable à la libération des bonnes sessions PDU et des bonnes associations de politique.
Dans un désenregistrement normal, l’UE envoie la requête et attend que le réseau confirme l’achèvement. Avec la mise hors tension, l’objectif est de transmettre l’indication « je quitte le réseau » aussi rapidement que possible, puis de poursuivre l’arrêt ; le traitement est donc différent. Le désenregistrement normal peut utiliser T3521 pour surveiller la période pendant laquelle l’UE attend Deregistration Accept, tandis qu’une procédure de mise hors tension n’attend pas la confirmation réseau de la même manière.
Pourquoi l’AMF vérifie-t-il d’abord si l’UE possède encore une session PDU ?
Après réception du Deregistration Request, l’une des décisions clés de l’AMF consiste à déterminer si des sessions PDU établies existent encore sur l’accès cible.
Si l’UE ne possède aucune session PDU pertinente, il n’existe pas de session de plan utilisateur à démonter individuellement et la procédure peut être nettement plus courte. En revanche, si une ou plusieurs sessions PDU sont encore actives, l’AMF ne peut pas simplement supprimer son propre contexte d’enregistrement, car le SMF et l’UPF considéreraient toujours ces sessions comme existantes.
Pour chaque session PDU qui doit être libérée, l’AMF peut invoquer Nsmf_PDUSession_ReleaseSMContext vers le SMF correspondant. Cela peut être compris comme une instruction explicite de l’AMF à la couche de gestion de session : l’UE quitte l’accès cible, le SM Context associé ne doit donc plus être maintenu. Ce n’est qu’après réception de cette instruction que le SMF peut poursuivre la suppression de la session N4, terminer les associations de politique et nettoyer l’état d’enregistrement concerné dans l’UDM.
Cela met également en évidence la différence entre le désenregistrement et une libération indépendante de session PDU. Libérer une session PDU ne signifie pas que l’UE quitte le 5GS ; l’UE peut rester 5GS Registered. À l’inverse, lorsque l’UE initie son désenregistrement, les sessions PDU associées à l’accès cible doivent normalement être nettoyées dans le cadre de la procédure de désenregistrement globale.
Par conséquent, si une trace montre un Deregistration Request sans Nsmf_PDUSession_ReleaseSMContext par la suite, il ne faut pas conclure immédiatement à une signalisation manquante. Il faut d’abord confirmer qu’une session PDU était effectivement établie sur l’Access Type concerné. Si aucune session PDU n’existait, l’absence d’une procédure de libération N4 peut correspondre exactement au comportement attendu.
Comment le SMF et l’UPF démontent-ils réellement le plan utilisateur ?
Une fois que l’AMF envoie au SMF la demande de libération de session PDU, le SMF devient responsable de la suppression des ressources de plan utilisateur associées. Lorsqu’une session UPF existe, le SMF la libère via l’interface N4.
Dans un cas typique, le SMF envoie un PFCP Session Deletion Request. L’UPF utilise le F-SEID correspondant ou le contexte de session N4 pour supprimer l’état de transfert de l’utilisateur et renvoie un PFCP Session Deletion Response. Les tunnels de plan utilisateur, les règles de transfert et le contexte associé à la session PDU sont alors supprimés. Le nettoyage ne se limite pas à un tunnel unique ; il supprime également l’état des règles associé à cette session N4, notamment les FAR, QER, URR et les autres règles applicables.
La relation de contrôle peut être résumée ainsi :
UE → AMF : je veux me désenregistrer
→ AMF → SMF : libérer le contexte de session PDU de cet UE
→ SMF → UPF : supprimer la session N4 et les ressources du plan utilisateur
→ UPF → SMF : confirmer la suppression
→ SMF → AMF : libération du SM Context terminée
Si la session utilise un PCC dynamique, le SMF peut également devoir terminer l’association SM Policy correspondante, par exemple via Npcf_SMPolicyControl_Delete. Lorsque la session libérée est la dernière session PDU gérée par ce SMF pour le DNN et le S-NSSAI concernés, le SMF peut aussi se désabonner des modifications de Session Management Subscription Data dans l’UDM et utiliser Nudm_UECM_Deregistration pour supprimer de l’UDM l’association entre le SMF et le DNN/la session PDU correspondants.
Du point de vue d’une trace UPF, le moment où le désenregistrement atteint réellement le plan utilisateur n’est pas le NAS Deregistration Request lui-même, mais la libération ultérieure de la session N4. Ce n’est qu’une fois cette étape terminée que les ressources de transfert appartenant à la session PDU d’origine sont réellement supprimées du plan utilisateur.
Pourquoi l’UDM et le PCF doivent-ils encore nettoyer du contexte supplémentaire ?
Une fois la libération de session PDU terminée, le plan utilisateur peut déjà avoir disparu, mais des associations de plan de contrôle peuvent encore subsister dans le 5GC. Pour que le désenregistrement soit pleinement terminé, le réseau doit déterminer quels abonnements, enregistrements et relations de politique restent valides et lesquels doivent être supprimés.
Du côté de la gestion de session, si le SMF ne dessert plus la dernière session PDU de l’utilisateur pour le DNN et le S-NSSAI concernés, il peut annuler son abonnement aux mises à jour SM Data dans l’UDM et supprimer le SMF Registration associé. Cela évite que l’UDM continue à envoyer des mises à jour de Session Management à un SMF qui ne dessert plus cette session.
Du côté des politiques d’accès et de mobilité, si l’UE n’est plus enregistré via aucun Access Type pertinent et qu’une AM Policy Association existe entre l’AMF et le PCF, l’AMF doit terminer cette association. Lorsqu’une UE Policy Association existe, elle doit également être libérée lorsque les conditions applicables sont remplies. Si l’AMF ne maintient plus aucun enregistrement valide pour cet UE, la relation d’enregistrement AMF dans l’UDM peut également devoir être supprimée via Nudm_UECM_Deregistration.
Il existe ici une limite importante : il ne faut pas supposer que tout le contexte PCF et UDM doit disparaître simplement parce qu’une procédure de désenregistrement a lieu. Si l’UE reste enregistré via un autre Access Type, ou si le même SMF gère encore d’autres sessions PDU pertinentes pour cet UE, certaines associations peuvent encore être nécessaires.
Le nettoyage du désenregistrement n’est donc pas une simple séquence fixe de requêtes DELETE. Il suit un principe : ne supprimer que l’état qui a perdu sa signification opérationnelle du fait de ce désenregistrement, tout en conservant le contexte encore utilisé par un autre accès ou une autre session. C’est l’un des points les plus faciles à mal interpréter dans les déploiements multi-accès et multi-session PDU.
Pourquoi le désenregistrement normal et la mise hors tension se terminent-ils différemment ?
Le désenregistrement normal et la mise hors tension peuvent tous deux déclencher la libération de sessions PDU et de ressources du cœur de réseau au début de la procédure, mais ils diffèrent dans la façon dont le côté UE arrive à son terme.
Dans une procédure de désenregistrement normal, après avoir envoyé le Deregistration Request, l’UE attend la confirmation du réseau. Une fois le traitement applicable terminé par l’AMF, celui-ci renvoie un Deregistration Accept, indiquant explicitement à l’UE que le réseau a accepté le désenregistrement. Des mécanismes NAS tels que T3521 peuvent surveiller cette période d’attente. Si T3521 expire, l’UE suit les mécanismes de retransmission ou de traitement d’exception définis par le protocole au lieu de supposer simplement que le désenregistrement est terminé.
Si le désenregistrement s’applique à l’accès 3GPP et qu’une connexion de signalisation N2 existe encore entre l’AMF et le NG-RAN, l’AMF peut ensuite poursuivre avec N2 UE Context Release afin de terminer la connexion de signalisation correspondante côté accès.
La mise hors tension est différente. L’UE est sur le point de s’éteindre ; il est donc peu utile de le maintenir connecté uniquement pour attendre un message de confirmation. Lorsque le Deregistration type indique mise hors tension, l’AMF ne traite pas le côté UE comme dans un désenregistrement normal en exigeant un Deregistration Accept avant que l’UE ne quitte le réseau. Une fois que l’UE a fait son meilleur effort pour transmettre le Deregistration Request, il peut poursuivre le processus d’arrêt.
Cette différence est particulièrement importante dans les traces de paquets :
Désenregistrement normal
Deregistration Request
→ Le cœur de réseau libère les ressources associées
→ Deregistration Accept
→ Libération de la signalisation / AN
mise hors tension
Deregistration Request
→ Le cœur de réseau libère les ressources associées
→ L’UE n’attend pas Deregistration Accept avant de terminer son arrêt
Ainsi, l’absence de Deregistration Accept dans une trace d’extinction ne signifie pas automatiquement que la procédure a échoué. La première étape consiste à vérifier si le Deregistration type correspond à un désenregistrement normal ou à la mise hors tension. Si l’UE s’est déjà éteint, a perdu la liaison radio ou n’a pas eu assez de temps pour recevoir une réponse, le réseau peut ensuite s’appuyer sur des mécanismes tels que Mobile Reachable Timer et Implicit Deregistration pour traiter la disparition anormale de l’UE.
Questions fréquentes
L’UE est-il assuré de transmettre Deregistration Request à l’AMF lorsqu’il s’éteint ?
Non. La procédure de mise hors tension est conçue pour que l’UE fasse son meilleur effort pour envoyer la demande de désenregistrement avant de s’éteindre, mais le réseau peut ne jamais la recevoir si l’UE a déjà perdu la couverture, si la liaison radio est tombée ou si l’alimentation disparaît soudainement. C’est pourquoi le 5GC a toujours besoin de mécanismes côté réseau tels que Mobile Reachable Timer et Implicit Deregistration pour traiter les UE qui disparaissent de façon inattendue.
Le désenregistrement de l’UE déclenche-t-il toujours PFCP Session Deletion ?
Non. S’il n’existe aucune session PDU établie sur l’Access Type cible, il n’y a pas de session N4 de plan utilisateur correspondante à libérer ; les étapes SMF et UPF associées au nettoyage de la session PDU peuvent donc être absentes. PFCP Session Deletion n’est requis que lorsqu’une session PDU pertinente et ses ressources de plan utilisateur existent réellement.
Le désenregistrement et la libération de session PDU sont-ils la même procédure ?
Non. La libération de session PDU supprime une session de données précise tandis que l’UE peut rester dans l’état 5GS Registered. Le désenregistrement supprime la relation d’enregistrement de l’UE avec le 5GS. Lorsque l’UE se désenregistre, les sessions PDU existantes doivent normalement être libérées comme ressources associées, mais les deux procédures agissent à des niveaux différents et ont des objectifs différents.
Pourquoi une partie du contexte UDM ou PCF peut-elle subsister après le désenregistrement de l’UE ?
Il faut d’abord vérifier à quel Access Type s’applique le désenregistrement et si l’UE reste enregistré via un autre accès. Si l’UE conserve un autre accès valide, d’autres sessions PDU ou des relations de politique encore utilisées, il peut être nécessaire de conserver une partie du contexte. Le désenregistrement ne doit pas être interprété comme une suppression inconditionnelle de chaque élément d’état UE dans l’ensemble du 5GC.
