Dans un réseau 5G, une fois l’UE enregistré, le réseau cœur doit conserver une connaissance générale de sa localisation afin de pouvoir le joindre lors d’une procédure de recherche de terminal, de l’arrivée d’un service entrant ou de données descendantes. Un UE ne reste cependant pas au même endroit. Il peut passer d’une Tracking Area à une autre, voire sortir de la zone de service de son AMF actuel. Si l’UE devait effectuer un nouvel enregistrement après chaque déplacement, la signalisation du plan de contrôle deviendrait excessive. S’il ne mettait jamais sa localisation à jour, le réseau pourrait finir par ne plus savoir où le joindre. Mobility Registration Update est conçue pour équilibrer la précision de localisation et la surcharge de signalisation.
Une question revient souvent lors de l’étude initiale de la signalisation 5GC : si l’UE est déjà enregistré, pourquoi doit-il envoyer une nouvelle Registration Request après s’être déplacé dans une autre zone ? Le passage vers un autre gNB déclenche-t-il toujours une mise à jour ? L’entrée dans une nouvelle Tracking Area implique-t-elle systématiquement un changement d’AMF ? Ces questions renvoient au même principe : l’UE reste dans l’état 5GS Registered, mais sa position actuelle peut avoir quitté la Registration Area précédemment attribuée par le réseau. Le 5GC doit donc mettre à jour la localisation de l’UE, déterminer si l’AMF de service doit rester le même et attribuer la Registration Area applicable à la prochaine phase de mobilité. Il ne s’agit pas d’un nouvel enregistrement au démarrage, et l’UE ne se réenregistre pas à chaque changement de cellule. C’est un mécanisme destiné à maintenir la continuité du contexte de mobilité 5GS de l’UE.
La sortie de la Registration Area est le principal déclencheur de la mise à jour de mobilité
L’enregistrement dans le 5GC ne se limite pas à l’Initial Registration. Le champ 5GS registration type transporté dans la Registration Request distingue des procédures telles que Initial Registration, Mobility Registration Update, Periodic Registration Update et Emergency Registration. Dans les scénarios de mobilité, l’une des confusions les plus fréquentes concerne la différence entre une Tracking Area (TA) et une Registration Area.
Une TA est l’une des zones de base utilisées par le réseau pour la gestion de localisation, tandis qu’une Registration Area est un ensemble de TA dans lequel l’AMF autorise l’UE à rester enregistré. Une Registration Area peut contenir une seule TA ou plusieurs. Supposons qu’un AMF desserve TA1, TA2, TA3 et TA4, mais n’attribue à un UE donné que TA1 et TA2 comme Registration Area actuelle en fonction de son comportement de mobilité. Lorsque cet UE passe de TA1 à TA2, il reste dans la zone enregistrée et n’a pas besoin d’effectuer une Mobility Registration Update simplement parce que la TA a changé.
La situation change lorsque l’UE poursuit son déplacement vers TA3 et que TA3 ne fait pas partie de la Registration Area actuellement mémorisée. L’UE détecte que le TAI courant se trouve hors de sa zone enregistrée, envoie une nouvelle NAS Registration Request et positionne le 5GS registration type sur mobility registration updating. Ainsi, un changement de cellule ne déclenche pas automatiquement une Mobility Registration Update, et même un changement de TA ne la déclenche pas toujours. Le cas typique est l’entrée dans une TA située hors de la Registration Area actuelle de l’UE.
C’est précisément l’objectif du concept de Registration Area. Il permet à un UE de se déplacer dans une plage définie sans interagir avec le 5GC à chaque franchissement de frontière de TA, ce qui aide à équilibrer la précision de localisation et la charge de signalisation du plan de contrôle. Le réseau peut attribuer une liste de TA plus large à un UE ayant un profil de mobilité étendu, ou réduire la Registration Area lorsqu’un suivi plus précis est souhaité. La Registration Area fait donc partie intégrante de la politique de gestion de mobilité.
Comment la Registration Request ramène-t-elle l’état de mobilité existant dans le 5GC ?
La différence la plus nette entre Mobility Registration Update et Initial Registration est que l’UE n’est pas un abonné totalement inconnu. Il a déjà terminé son enregistrement 5GS et conserve normalement des informations telles que le 5G-GUTI attribué par le réseau, sa Registration Area et le contexte NAS pertinent. La nouvelle Registration Request ne sert donc pas à établir l’identité depuis zéro. Elle indique plutôt au réseau : « Je suis le même UE que vous connaissez déjà, mais ma localisation de mobilité a changé. »
L’UE établit d’abord l’accès au plan de contrôle via le nouveau gNB. Le gNB transporte ensuite la NAS Registration Request vers l’AMF dans un NGAP Initial UE Message. En plus du NAS-PDU, l’Initial UE Message fournit des informations de localisation d’accès telles que le NR-CGI et le TAI actuels. Dans une Mobility Registration Update typique, la Registration Request peut contenir plusieurs éléments d’information importants : le 5GS registration type identifie la procédure comme mobility registration updating ; le 5G-GUTI aide le réseau à identifier l’AMF ou le GUAMI associé à l’enregistrement précédent de l’UE ; Last Visited Registered TAI fournit une référence à la localisation enregistrée précédente ; UE Security Capability décrit les algorithmes NAS pris en charge pour le chiffrement et la protection d’intégrité ; PDU Session Status reflète les sessions PDU que l’UE considère encore actives ; et Requested NSSAI peut fournir les tranches réseau demandées par l’UE le cas échéant.
Lors de l’analyse d’une trace, la première question ne devrait donc pas être de savoir si une authentification a lieu plus tard dans la procédure. Il faut d’abord vérifier si la Registration Request identifie clairement la procédure comme une Mobility Registration Update plutôt que comme une Initial Registration. Si le type d’enregistrement est mal interprété, le reste du flux de signalisation peut facilement être analysé sous un angle erroné.
Pourquoi les mises à jour avec le même AMF et les mises à jour inter-AMF suivent-elles des chemins différents ?
Quitter la Registration Area ne signifie pas nécessairement quitter la zone de service de l’AMF actuel. Cette distinction détermine directement la complexité de la suite de la procédure de signalisation et constitue l’une des premières branches à identifier lors de l’analyse d’une Mobility Registration Update.
Le Serving AMF reste le même
Supposons qu’un AMF desserve à la fois TA1 et TA2, alors que le réseau n’avait précédemment attribué que TA1 comme Registration Area de l’UE. Lorsque l’UE passe de TA1 à TA2, TA2 se trouve hors de sa Registration Area actuelle, ce qui impose une Mobility Registration Update. Toutefois, TA2 reste dans la zone de service du même AMF.
Dans ce cas, il n’y a pas de véritable migration d’Old AMF vers New AMF. L’AMF actuel possède déjà le contexte de mobilité de l’UE et doit seulement traiter la nouvelle localisation, mettre à jour la Registration Area et actualiser les informations de politique ou de contexte nécessaires. La Registration Area change, mais pas le Serving AMF.
Le Serving AMF change
La procédure devient plus complexe lorsque l’UE passe d’une TA desservie par un AMF à une TA desservie par un autre AMF. Par exemple, l’UE peut avoir terminé son enregistrement sous AMF1 et reçu un 5G-GUTI associé à AMF1. Après s’être déplacé via un nouveau gNB dans la zone de service d’AMF2, le New AMF doit savoir qui est l’UE, quel AMF le desservait auparavant et quel contexte peut être réutilisé.
Une Mobility Registration Update inter-AMF est donc plus qu’une simple mise à jour de localisation. Elle implique également le transfert du contexte de gestion de mobilité de l’UE de l’ancien AMF de service vers le nouveau.
Comment le New AMF trouve-t-il l’Old AMF et récupère-t-il le contexte UE ?
Dans un scénario de mobilité inter-AMF, le premier problème que doit résoudre le New AMF après réception de la Registration Request n’est pas de savoir si l’abonné peut établir un service de données. Il doit identifier l’AMF qui gérait précédemment l’UE. Le 5G-GUTI joue ici un rôle important. Les informations liées au GUAMI contenues dans l’identité temporaire aident le réseau à identifier l’AMF qui desservait auparavant l’UE. Le New AMF peut alors déterminer l’Old AMF et demander le UE Context existant via le service Namf_Communication.
La logique typique est simple : l’UE envoie une Mobility Registration Update à l’aide de son ancien 5G-GUTI ; le New AMF extrait du 5G-GUTI l’identité liée à l’AMF ; l’Old AMF est identifié ; le New AMF demande le UE Context ; et l’Old AMF renvoie le contexte de mobilité transférable. Ces informations peuvent aider le New AMF à récupérer des données d’identité et de mobilité telles que SUPI, GPSI, PEI et certaines parties de l’Access and Mobility Context, ce qui permet au nouveau Serving AMF de poursuivre le traitement à partir d’un état UE existant au lieu de considérer l’appareil comme totalement inconnu.
Obtenir le contexte depuis l’Old AMF ne signifie pas que toutes les procédures de sécurité suivantes peuvent toujours être ignorées. Si les informations d’identité ou le contexte de sécurité disponibles sont insuffisants, le réseau peut encore demander à nouveau le SUCI de l’UE et effectuer une vérification d’identité ou une authentification 5G-AKA selon les conditions de sécurité actuelles. L’analyse de traces doit donc éviter deux hypothèses rigides : une Mobility Registration Update n’exige pas toujours une nouvelle authentification complète, mais la présence d’un Old AMF Context disponible ne garantit pas non plus qu’aucune authentification ne se reproduira. L’apparition d’une Identity Request ou d’un 5G-AKA complet dépend du UE Context transféré, du NAS Security Context et de la politique réseau.
Comment UDM, NRF et PCF achèvent-ils la reprise par le Serving AMF ?
Récupérer le UE Context depuis l’Old AMF ne signifie pas que la relation de service a été entièrement transférée. Dans le 5GC, la localisation de l’utilisateur et l’état du service sont répartis entre plusieurs fonctions réseau. En particulier, l’UDM doit savoir quel AMF est désormais responsable de l’UE.
Le New AMF peut utiliser le NRF pour découvrir un UDM fournissant les services requis, puis enregistrer le nouveau 3GPP Access Registration dans l’UDM. Cette étape est particulièrement importante dans un scénario inter-AMF, car l’enregistrement du Serving AMF dans l’UDM doit passer de l’Old AMF au New AMF. L’UDM peut ensuite déclencher la Deregistration Notification correspondante vers l’Old AMF afin de libérer la relation de service précédente.
Le New AMF a également besoin des Access and Mobility Subscription Data actuelles, qui peuvent inclure GPSI, Subscribed NSSAI, UE-AMBR, des paramètres d’enregistrement périodique, des restrictions RAT et des restrictions d’accès par zone. Si le traitement ultérieur d’une PDU Session nécessite la sélection d’un SMF, l’AMF peut aussi récupérer les SMF Selection Subscription Data, y compris les informations DNN et Default DNN associées au S-NSSAI concerné, et s’abonner aux modifications de ces données de souscription. Le PCF complète ce processus en fournissant l’Access and Mobility Policy. Le New AMF peut sélectionner le PCF approprié et établir une AM Policy Association afin d’obtenir des informations de politique de mobilité, telles que les restrictions de zone.
Ces étapes répondent à des besoins différents. L’Old AMF Context indique au New AMF l’état antérieur de l’UE. L’UDM Registration indique au réseau cœur quel AMF dessert maintenant l’UE. Les Subscription Data indiquent au New AMF ce que l’abonné est autorisé à utiliser. La PCF Policy indique à l’AMF quelles règles de mobilité et d’accès s’appliquent actuellement. Une Mobility Registration Update ne doit donc pas être réduite à « l’AMF met à jour un TAI ». Dans un scénario inter-AMF, elle transfère également la responsabilité de gestion de mobilité d’un AMF à un autre.
Comment Registration Accept définit-il la prochaine zone de mobilité de l’UE ?
Une fois le traitement de l’identité, du contexte, des données de souscription et des politiques terminé, l’AMF doit appliquer le nouvel état d’enregistrement à la fois au gNB et à l’UE. Dans une procédure typique, l’AMF peut utiliser un NGAP Initial Context Setup Request pour établir ou mettre à jour le contexte lié à l’UE dans le gNB tout en transmettant le NAS Registration Accept à l’UE.
L’élément le plus important de Registration Accept n’est pas simplement la réussite de l’enregistrement. Le message fournit aussi des paramètres qui définissent le comportement de l’UE pendant la prochaine phase de mobilité. Un nouveau 5G-GUTI peut être attribué après un déplacement inter-AMF afin de refléter le nouveau Serving AMF. Allowed NSSAI identifie les tranches réseau actuellement autorisées pour l’UE. T3512 définit la temporisation associée à une future Periodic Registration Update. La TA List, ou Registration Area, indique à l’UE dans quelles TA il peut se déplacer tout en restant enregistré sans déclencher une nouvelle Mobility Registration Update du même type.
Après que le gNB a terminé le traitement de contexte correspondant, il renvoie un Initial Context Setup Response et l’UE envoie Registration Complete. La Mobility Registration Update en cours est alors terminée. Du point de vue des transitions d’état, le flux peut être résumé ainsi : l’UE quitte sa Registration Area existante ; la Registration Request transporte l’identité de mobilité précédente dans le 5GC ; le réseau détermine si le Serving AMF doit changer ; le UE Context est transféré depuis l’Old AMF lorsque nécessaire ; le New AMF termine l’enregistrement UDM et obtient les informations de souscription et de politique nécessaires ; Registration Accept fournit le nouveau 5G-GUTI et la Registration Area ; enfin, l’UE renvoie Registration Complete.
Le dépannage peut suivre la même chaîne d’état. Si la Registration Request atteint le New AMF mais que l’Old AMF ne peut pas être localisé, les vérifications doivent porter sur le 5G-GUTI, le GUAMI et l’adressage AMF. Si l’Old AMF Context est récupéré avec succès mais que la procédure s’arrête au niveau UDM, les vérifications suivantes doivent couvrir la découverte UDM, l’AMF Registration et la récupération des données de souscription. Si le traitement interne du réseau cœur se termine mais qu’aucun Registration Accept n’atteint l’UE, l’analyse doit se poursuivre sur les résultats de politique, les restrictions de zone, la signalisation descendante NGAP et l’établissement du contexte RAN. L’objectif de l’étude de 5GC Mobility Registration Update n’est donc pas de mémoriser des dizaines de messages HTTP/2 et NGAP, mais de comprendre comment le réseau répond à trois questions après le déplacement d’un UE enregistré : où se trouve maintenant l’UE, quel AMF doit continuer à le gérer et quelle Registration Area doit s’appliquer à sa prochaine période de mobilité ?
Questions fréquentes
L’UE effectue-t-il une Mobility Registration Update chaque fois qu’il entre dans une nouvelle Tracking Area ?
Pas nécessairement. La question essentielle est de savoir si la nouvelle TA fait toujours partie de la Registration Area actuelle de l’UE. Si l’AMF a déjà attribué TA1 et TA2 comme Registration Area de l’UE, le passage de TA1 à TA2 ne déclenchera normalement pas cette mise à jour uniquement parce que la TA a changé. L’entrée dans une TA située hors de la Registration Area constitue le déclencheur typique.
Une Mobility Registration Update change-t-elle toujours l’AMF ?
Non. L’UE peut quitter sa Registration Area actuelle alors que la nouvelle TA appartient toujours à la zone de service du même AMF. Dans ce cas, le Serving AMF reste inchangé. Le transfert de contexte d’Old AMF vers New AMF n’est nécessaire que lorsque l’UE entre dans une zone qui doit être desservie par un autre AMF.
Chaque Mobility Registration Update répète-t-elle 5G-AKA ?
Aucune règle fixe ne doit être supposée. La répétition des procédures d’identité ou de 5G-AKA dépend du UE Context disponible, du NAS Security Context et de la politique réseau. Si un contexte valide peut continuer à être utilisé, certaines procédures de sécurité peuvent ne pas devoir être répétées intégralement. Si les conditions d’identité ou de sécurité sont insuffisantes, le réseau peut effectuer à nouveau les étapes d’authentification nécessaires.
En quoi une 5GC Mobility Registration Update diffère-t-elle d’une mise à jour lorsqu’un UE passe de la 4G à la 5G ?
Les deux scénarios peuvent utiliser le type d’enregistrement Mobility Registration Update, mais la source du contexte de mobilité diffère. Une mobilité entièrement à l’intérieur du 5GS implique généralement un contexte de mobilité entre un Old AMF et un New AMF. Un scénario d’interfonctionnement en mode inactif de la 4G vers la 5G peut également impliquer le MME, N26 et la traduction entre les contextes EPS et 5GS. Lors de l’analyse d’une trace de signalisation, la première étape consiste à déterminer si l’UE se déplace au sein du 5GS ou s’il entre dans le 5GC depuis l’EPC.
