À 3 h du matin, une passerelle industrielle 5G envoie un Registration Request à l’AMF. Son TAI n’a pas changé depuis l’enregistrement précédent, le 5G-GUTI est identique, l’AMF de service n’a pas changé et l’équipement n’a peut-être transmis aucune donnée montante depuis plusieurs heures. Du seul point de vue de la gestion de mobilité, la requête n’apporte aucune nouvelle information de localisation et pourrait ressembler à un enregistrement en double. Pourtant, le champ type d’enregistrement l’identifie clairement comme une mise à jour périodique d’enregistrement. Ce que l’AMF doit confirmer n’est pas l’endroit où l’UE s’est déplacé, mais quelque chose de plus fondamental : l’UE est-il toujours présent, doit-il toujours être considéré comme joignable par paging et son contexte d’enregistrement doit-il encore être conservé ?
Dans la gestion d’enregistrement 5GC, la mise à jour d’enregistrement de mobilité et la mise à jour périodique d’enregistrement répondent à deux problèmes différents. La première est déclenchée par la mobilité et porte sur l’actualisation de la localisation et du routage ; la seconde est déclenchée à l’expiration de T3512 et vise à confirmer périodiquement l’état d’enregistrement et la joignabilité de l’UE. Un UE qui reste longtemps en CM-IDLE peut devoir contacter le réseau à l’expiration de T3512 même s’il demeure dans la même zone d’enregistrement, reste desservi par le même AMF et n’a pas changé de position. Cette interaction permet au réseau d’actualiser sa perception de la joignabilité de l’UE et, si l’UE reste absent, de libérer à terme un contexte d’enregistrement obsolète par désenregistrement implicite. La clé pour comprendre cette procédure n’est donc pas de savoir si le Registration Request contient une nouvelle position, mais de comprendre comment T3512 est géré, comment l’UE déclenche la procédure en CM-IDLE, comment l’AMF interprète le type d’enregistrement et le contexte UE, et comment le réseau traite un UE qui ne se met pas à jour à temps.
Pourquoi une mise à jour périodique est-elle nécessaire si l’UE n’a pas bougé ?
Après l’enregistrement initial, l’UE passe à l’état 5GS Registered. Toutefois, « enregistré » ne signifie pas que l’UE maintient en permanence une connexion de signalisation NAS avec l’AMF. De nombreux smartphones, équipements IoT et terminaux à faible trafic passent en CM-IDLE lorsqu’aucune activité de données ou de signalisation n’est en cours afin de réduire la consommation de ressources radio et du cœur de réseau.
Du point de vue de l’UE, rester inactif longtemps économise des ressources. Du point de vue du 5GC, cela soulève toutefois une question importante : la dernière fois que l’AMF a su que l’UE était disponible peut remonter à plusieurs dizaines de minutes, voire plusieurs heures. Depuis, l’UE a pu être éteint, perdre la couverture ou épuiser sa batterie, ou simplement rester normalement campé sans générer de trafic.
Si le cœur de réseau conservait indéfiniment l’enregistrement de l’UE, il pourrait maintenir un contexte obsolète pour un terminal qui n’est plus joignable. À l’inverse, s’il supprimait le contexte trop rapidement, il pourrait obliger inutilement un UE toujours normalement enregistré à établir un nouvel enregistrement.
La mise à jour périodique d’enregistrement coordonne ces deux exigences. Le réseau utilise T3512 pour indiquer à l’UE combien de temps il peut rester sans autre interaction 5GMM pertinente avant de devoir lancer une mise à jour périodique d’enregistrement.
La procédure peut donc être considérée comme un point de contrôle périodique entre l’UE et le 5GC :
L’UE est déjà enregistré
→ L’UE reste en CM-IDLE pendant une période prolongée
→ T3512 continue de s’écouler
→ T3512 expire
→ L’UE rétablit la connectivité de signalisation NAS
→ L’UE lance une mise à jour périodique d’enregistrement
→ L’AMF confirme et actualise l’état d’enregistrement
Son objectif principal n’est pas de signaler un nouveau déplacement entre zones, mais d’éviter que l’UE et le réseau restent indéfiniment désynchronisés quant à la validité du contexte d’enregistrement existant.
Quand T3512 commence-t-il réellement à s’écouler ?
T3512 n’est pas simplement un temporisateur local choisi par l’UE. Sa valeur est contrôlée par le réseau, et l’AMF peut fournir à l’UE la valeur du temporisateur d’enregistrement périodique dans le message Registration Accept. Tant que l’UE ne reçoit pas une nouvelle valeur, il continue d’utiliser la configuration T3512 mémorisée.
La valeur par défaut de T3512 définie par le 3GPP est de 54 minutes, mais cela ne signifie pas que tous les UE de tous les réseaux 5G commerciaux effectuent une mise à jour toutes les 54 minutes. L’AMF peut attribuer une autre valeur selon la configuration du réseau, le comportement de l’UE, les informations d’abonnement et la politique. Si le réseau désactive T3512 ou le règle sur zéro, la mise à jour périodique correspondante n’est pas effectuée.
Dans un scénario courant d’accès 3GPP, si le réseau n’utilise pas la fonction de temporisateur d’enregistrement strictement périodique, l’UE démarre ou redémarre T3512 lorsqu’il passe de 5GMM-CONNECTED à 5GMM-IDLE. Lorsque l’UE revient à 5GMM-CONNECTED, le temporisateur s’arrête normalement. Ce point est important, car la mise à jour périodique d’enregistrement n’est pas simplement déclenchée selon une horloge absolue indépendamment de l’activité de l’UE.
Supposons qu’un UE termine son enregistrement à 09:00, libère ensuite la connexion de signalisation NAS et passe en CM-IDLE avec T3512 configuré à 54 minutes. Si aucune autre interaction ne vient arrêter, redémarrer ou modifier le temporisateur, l’UE est censé entrer dans la procédure de mise à jour périodique lorsque T3512 expire.
Les comportements prévus par des versions plus récentes de la spécification peuvent également prendre en charge un temporisateur d’enregistrement strictement périodique. Dans ce mode, T3512 peut démarrer après la réussite de l’enregistrement et ne s’arrête pas simplement parce que l’UE passe en 5GMM-CONNECTED. Si le temporisateur expire lorsque l’UE est à l’état connecté, il peut être redémarré, tandis que la mise à jour périodique elle-même reste traitée selon l’état 5GMM courant.
Ainsi, voir « T3512 = 54 minutes » dans un Registration Accept ne signifie pas automatiquement qu’un Registration Request doit apparaître exactement 54 minutes plus tard. L’analyse de traces doit aussi tenir compte du fait que l’UE ait pu passer à l’état CONNECTED pendant cet intervalle, qu’un autre enregistrement ait pu avoir lieu, que le mode strictement périodique soit activé ou non, et que le temporisateur ait pu être modifié ou désactivé.
En quoi un Registration Request périodique diffère-t-il d’un enregistrement initial ?
Lorsque T3512 expire, l’UE doit rétablir la communication du plan de contrôle avec le réseau. Une fois le chemin de signalisation NAS rétabli via le gNB, celui-ci envoie à l’AMF un NGAP Initial UE Message contenant les informations de localisation actuelles de l’UE ainsi que le NAS Registration Request.
L’élément d’information le plus important pour l’analyse de signalisation est le 5GS registration type (type d’enregistrement 5GS) du Registration Request. Dans cette procédure, il est défini sur periodic registration updating (mise à jour périodique d’enregistrement), ce qui indique explicitement à l’AMF que l’UE ne se rattache pas au 5GS pour la première fois et ne met pas à jour son enregistrement parce qu’il a quitté sa zone d’enregistrement. Il rafraîchit périodiquement un enregistrement existant.
L’UE transporte normalement aussi son 5G-GUTI existant afin que l’AMF puisse associer rapidement la demande à un contexte UE existant. Le message peut également inclure Last Visited Registered TAI, UE Security Capability et PDU Session Status afin d’aider le réseau à réconcilier les états de mobilité et de session actuellement détenus par l’UE.
Trois scénarios de Registration Request faciles à confondre peuvent donc être distingués dès le début d’une trace :
Enregistrement initial : l’UE doit établir une nouvelle relation d’enregistrement 5GS
Mise à jour d’enregistrement de mobilité : la localisation de mobilité de l’UE ou les conditions de la zone d’enregistrement ont changé
Mise à jour périodique d’enregistrement : la relation d’enregistrement existante doit être rafraîchie périodiquement
Les trois procédures utilisent un Registration Request, mais leurs déclencheurs sont fondamentalement différents. Lors de l’analyse de la signalisation d’enregistrement 5GC, le seul nom de message « Registration Request » ne permet pas d’identifier la procédure. Le premier élément à vérifier est le type d’enregistrement 5GS.
Pourquoi la mise à jour peut-elle être si courte lorsque l’AMF de service ne change pas ?
L’une des caractéristiques essentielles de la mise à jour périodique d’enregistrement n’est pas le nombre de nouveaux messages de signalisation qu’elle introduit, mais le fait qu’elle peut être bien plus courte qu’un enregistrement initial lorsque le contexte existant reste valide.
Supposons que l’UE reste dans la zone de service du même AMF, qu’aucun changement d’AMF n’ait eu lieu, que le contexte UE et le contexte de sécurité précédemment établis soient toujours utilisables et qu’aucune modification d’abonnement ou de politique ne nécessite de traitement supplémentaire. Lorsque l’AMF reçoit le Registration Request contenant le 5G-GUTI existant, il peut utiliser les informations GUAMI associées à cette identité pour déterminer que l’UE est toujours desservi localement et récupérer le contexte UE correspondant.
Dans ces conditions, de nombreuses procédures courantes d’un enregistrement initial complet ne doivent pas nécessairement être répétées.
Si l’identité et l’état de sécurité restent valides, une procédure 5G-AKA complète peut ne pas être nécessaire et l’AUSF peut donc être absent de la trace. Comme l’AMF de service n’a pas changé, il n’a pas nécessairement besoin de s’enregistrer à nouveau auprès de l’UDM ni de récupérer l’intégralité du profil d’abonnement uniquement parce qu’une mise à jour périodique a eu lieu. Si la zone d’accès et la politique n’ont pas changé, une nouvelle procédure PCF AM Policy peut également être inutile. S’il n’est pas nécessaire de sélectionner un nouvel AUSF, UDM ou PCF, les procédures de découverte NRF correspondantes peuvent elles aussi être absentes.
Un chemin de signalisation simplifié typique peut donc être le suivant :
UE
→ gNB : rétablir l’accès
→ AMF : Initial UE Message + Periodic Registration Request
→ AMF : récupérer le contexte UE existant à l’aide du 5G-GUTI
→ gNB / UE : Registration Accept
→ UE : Registration Complete lorsque nécessaire
L’expression « peut ne pas être nécessaire » est importante. Le cadre d’enregistrement 3GPP autorise le réseau à effectuer tout traitement d’identité, de sécurité, d’abonnement et de politique nécessaire au contexte courant. Une trace commerciale simplifiée ne doit donc pas être interprétée comme une séquence fixe et obligatoire pour chaque mise à jour périodique d’enregistrement.
Quels états d’enregistrement Registration Accept peut-il actualiser ?
Après avoir confirmé que l’UE peut rester enregistré, l’AMF renvoie à l’UE le résultat d’enregistrement actualisé via Registration Accept. Selon le résultat réseau, le message peut inclure des paramètres tels que Allowed NSSAI, T3512, TA List et, si nécessaire, un nouveau 5G-GUTI.
T3512 est particulièrement important lors d’une mise à jour périodique d’enregistrement. Si l’AMF fournit une nouvelle valeur, l’UE doit l’utiliser pour le cycle périodique suivant. Si aucune nouvelle valeur n’est fournie, l’UE peut continuer à utiliser la configuration mémorisée. Le réseau peut ainsi ajuster au fil du temps le comportement d’enregistrement périodique au lieu de fixer définitivement l’intervalle dans le terminal.
La TA List contenue dans Registration Accept continue de définir la zone d’enregistrement courante de l’UE. Même si la mise à jour périodique n’est pas déclenchée par la sortie de cette zone, une interaction d’enregistrement réussie permet toujours au réseau de fournir à l’UE les paramètres de gestion de mobilité les plus récents.
Si Registration Accept contient un nouveau 5G-GUTI, l’UE doit confirmer la bonne réception de l’identité temporaire au moyen de Registration Complete. Si l’AMF n’attribue pas de nouveau 5G-GUTI, l’absence de Registration Complete ne signifie pas automatiquement un échec. La trace doit être interprétée en fonction des éléments d’information contenus dans Registration Accept qui nécessitent réellement une confirmation.
C’est aussi pourquoi la mise à jour périodique d’enregistrement est plus qu’un simple mécanisme de maintien en vie. Elle reste intégrée au cadre 5GMM Registration et permet au réseau de resynchroniser les paramètres de mobilité liés à l’enregistrement plutôt que de simplement vérifier si l’UE répond encore.
Comment vérifier une mise à jour périodique d’enregistrement dans une trace de signalisation ?
Pour dépanner une mise à jour périodique d’enregistrement, l’approche la plus efficace n’est pas de commencer par rechercher la signalisation AUSF ou UDM. Il faut plutôt suivre la chaîne T3512 → état UE → Registration Request → contexte AMF → Registration Accept.
Si l’UE ne lance jamais de mise à jour périodique après l’enregistrement, vérifiez d’abord si Registration Accept contenait une valeur T3512 valide. Si T3512 est désactivé ou réglé sur zéro, aucune mise à jour périodique ne doit être attendue. Si la valeur est valide, confirmez que l’UE est effectivement passé dans l’état 5GMM-IDLE applicable et qu’aucune interaction NAS n’a pu arrêter, redémarrer ou modifier le temporisateur.
Si l’UE envoie un Registration Request mais que l’AMF le traite comme un enregistrement initial, vérifiez le type d’enregistrement 5GS et le 5G-GUTI. Si l’AMF ne peut pas associer le 5G-GUTI à un contexte UE existant, la procédure peut suivre un chemin plus complexe de récupération d’identité ou de nouvel enregistrement.
Si le Registration Request est correctement reconnu mais qu’une procédure complète d’authentification apparaît ensuite, cela ne prouve pas à lui seul qu’un problème existe. Il faut vérifier le NAS Security Context existant et déterminer si le réseau a décidé de relancer l’authentification conformément à sa politique de sécurité.
Outre T3512 côté UE, l’AMF utilise un mécanisme important de supervision de la joignabilité côté réseau : le Mobile Reachable Timer (temporisateur de joignabilité mobile). Pour un UE normalement enregistré, ce temporisateur réseau est plus long que T3512, avec une relation par défaut généralement égale à T3512 plus quatre minutes. L’AMF démarre le Mobile Reachable Timer après la libération de la connexion de signalisation NAS et l’arrête lorsque l’UE rétablit la connectivité NAS.
Les deux mécanismes fonctionnent ensemble :
T3512 côté UE : indique à l’UE quand revenir pour rafraîchir son enregistrement
Mobile Reachable Timer côté AMF : surveille si l’UE réapparaît dans le délai attendu
Si l’UE ne contacte pas le réseau pendant une période prolongée, le Mobile Reachable Timer et le mécanisme ultérieur de désenregistrement implicite permettent au cœur de réseau de gérer progressivement un UE dont la joignabilité ne peut plus être confirmée, plutôt que de conserver indéfiniment un contexte d’enregistrement obsolète.
L’objectif réel de la mise à jour périodique d’enregistrement 5GC n’est donc pas de « se réenregistrer toutes les quelques dizaines de minutes ». Elle permet à un UE resté longtemps inactif et à l’AMF de rétablir périodiquement une vision commune de l’état d’enregistrement : l’UE est toujours présent, la relation d’enregistrement existante reste valide et les paramètres de mobilité concernés peuvent continuer à être utilisés pendant la période suivante.
Questions fréquentes
T3512 est-il fixé à 54 minutes dans tous les réseaux 5G ?
Non. Cinquante-quatre minutes est la valeur par défaut définie par le 3GPP, mais l’AMF peut attribuer une autre valeur selon la configuration du réseau, le comportement de l’UE, les informations d’abonnement et la politique. L’analyse de signalisation et le dépannage doivent toujours utiliser la valeur T3512 réellement reçue par l’UE plutôt que de supposer qu’elle est toujours de 54 minutes.
Si l’UE génère du trafic normal pendant les 54 minutes, enverra-t-il tout de même une mise à jour périodique exactement à la 54e minute ?
Pas nécessairement. Avec le fonctionnement normal de T3512, le passage en 5GMM-CONNECTED influence le temporisateur périodique, qui peut redémarrer lorsque l’UE revient ensuite en IDLE. Le prochain Registration Request ne peut donc pas être prédit simplement en ajoutant 54 minutes à l’heure de fin de l’enregistrement initial. Le comportement temporel est également différent lorsqu’un temporisateur d’enregistrement strictement périodique est activé.
Chaque mise à jour périodique d’enregistrement nécessite-t-elle AUSF, UDM et PCF ?
Non. Si l’AMF de service reste inchangé, que le contexte UE et le contexte de sécurité existants sont valides et qu’aucune information d’abonnement ou de politique ne doit être rafraîchie, la procédure peut rester très courte. L’invocation d’AUSF, UDM, PCF ou NRF dépend du contexte UE et de l’implémentation réseau à ce moment-là. Ils ne doivent pas être considérés comme des participants obligatoires à chaque mise à jour périodique d’enregistrement.
La mise à jour périodique d’enregistrement s’applique-t-elle aux accès non-3GPP tels que le Wi-Fi ?
Le mécanisme de mise à jour périodique basé sur T3512 s’applique à un UE enregistré auprès du 5GS via un accès 3GPP. Pour les accès non-3GPP, le 5GS utilise d’autres mécanismes appropriés de gestion de l’enregistrement et du désenregistrement ; le comportement T3512 utilisé pour l’accès NR ne doit donc pas être appliqué directement au Wi-Fi ni à d’autres scénarios d’accès non-3GPP.
