Encyclopédie
2026-07-23 18:10:42
Comment la mobilité inactif passant du 4G au 5G déclenche une mise à jour de l'enregistrement de mobilité ?
Cet article explique comment la mobilité inactif passant du 4G au 5G déclenche une mise à jour de l‘enregistrement de mobilité, pourquoi l‘interface N26 est importante, comment le contexte de l‘UE passe de l‘MME à l‘AMF, et comment le 5GC finalise l‘enregistrement, la gestion des abonnements, le contrôle des politiques et la préparation du contexte de session sans transition en état de connexion.

Becke Telcom

Comment la mobilité inactif passant du 4G au 5G déclenche une mise à jour de l'enregistrement de mobilité ?

Lorsqu’un terminal mobile passe d’une couverture 4G à une couverture 5G, le réseau ne traite pas toujours cet événement comme un enregistrement 5G entièrement nouveau. Le comportement réel dépend de l’état du terminal, de l’architecture d’interfonctionnement et de la prise en charge ou non de l’interface N26 entre l’EPC et le 5GC. Dans un scénario typique, l’équipement utilisateur (UE) est déjà attaché à la 4G, a établi un support par défaut, est passé à l’état de veille, puis s’est déplacé dans une zone de couverture 5G. À ce moment, le terminal lance une procédure d’enregistrement 5G, mais le type d’enregistrement n’est pas un enregistrement initial. Il s’agit d’une mise à jour de l’enregistrement de mobilité (Mobility Registration Update).

Cette différence est importante. L’enregistrement initial signifie généralement que l’UE repart de zéro en 5G. La mise à jour de l’enregistrement de mobilité signifie que le réseau dispose déjà d’un contexte utile côté 4G et que le cœur 5G doit reprendre les informations de mobilité et de session de l’utilisateur de la manière la plus fluide possible. Dans un déploiement basé sur N26, l’AMF peut demander le contexte de l’UE auprès du MME, réutiliser ou transformer les informations essentielles et poursuivre le processus d’enregistrement côté 5G.

La façon la plus simple de comprendre la procédure est d’imaginer un utilisateur qui se trouvait à l’extérieur d’un stade sous couverture 4G, déjà attaché au LTE/EPC avec un support par défaut établi, puis qui a cessé toute activité de données et est passé à l’état de veille. Lorsque l’utilisateur entre dans le stade, la zone intérieure est couverte par la 5G. L’UE découvre la cellule 5G, lance l’enregistrement via le gNodeB et le réseau entame la procédure de mobilité en mode veille de la 4G vers la 5G.

Pourquoi ce scénario existe

L’interfonctionnement 4G-5G n’est pas seulement un problème d’accès radio, c’est aussi un problème de continuité du cœur de réseau. Côté radio, le point d’accès passe de l’eNodeB au gNodeB. Côté cœur, l’ancrage de mobilité passe du MME à l’AMF. Parallèlement, certaines fonctions peuvent rester logiquement continues parce qu’elles sont déployées de manière combinée. Par exemple, le HSS et l’UDM peuvent être colocalisés, le PGW-C et le SMF peuvent être combinés, et le PGW-U et l’UPF peuvent être combinés. Cela permet au réseau de réutiliser une partie du contexte de service 4G existant tout en transférant l’UE vers le système 5G.

La procédure décrite ici suppose un mode d’enregistrement unique avec l’interface N26. N26 permet à l’AMF et au MME d’échanger le contexte de l’UE. C’est la raison principale pour laquelle le côté 5G n’a pas besoin de tout reconstruire à partir de zéro. Sans cet échange de contexte, l’enregistrement 5G reposerait sur une approche d’interfonctionnement différente, et la continuité de session serait gérée autrement.

La partie « veille » du scénario est tout aussi importante que la partie « 4G vers 5G ». L’UE n’est pas en cours de transfert actif à l’état connecté. Il est déjà passé en mode ECM-IDLE côté LTE/EPC. Par conséquent, la tâche principale n’est pas de basculer un tunnel de plan utilisateur en temps réel, mais de migrer et d’interpréter le contexte de l’UE afin que le 5GC puisse continuer à gérer l’abonné après l’enregistrement de l’UE en couverture 5G.

Mobilité en mode veille de la 4G vers la 5G montrant l'UE passant de la couverture LTE eNodeB à la couverture 5G gNodeB avec l'interface MME AMF N26 et la mise à jour de l'enregistrement de mobilité
En mobilité en mode veille, l’UE passe d’une couverture 4G à une couverture 5G et lance une mise à jour de l’enregistrement de mobilité au lieu d’un enregistrement initial normal.

Ce qui change dans le réseau

Le changement le plus visible se situe du côté du réseau d’accès radio (RAN). L’UE était initialement desservi par un eNodeB LTE, puis se connecte via un gNodeB 5G. Le gNodeB reçoit la signalisation liée à l’enregistrement de l’UE et la transmet à l’AMF sélectionné. C’est la première étape du transfert de l’UE de l’environnement d’accès LTE/EPC vers l’environnement d’accès 5GS.

Le changement côté cœur est plus complexe. En 4G, le MME détient les informations de gestion de la mobilité et possède le contexte MM et SM de l’UE après l’attachement et l’établissement du support par défaut. En 5G, c’est l’AMF qui devient responsable de la gestion de l’accès et de la mobilité. Au cours de cette procédure, l’AMF doit obtenir le contexte de l’UE auprès du MME afin de pouvoir construire le contexte de mobilité correct côté 5G.

Les ancrages de plan utilisateur et de contrôle de session peuvent ne pas changer physiquement si le PGW-C est combiné avec le SMF et le PGW-U avec l’UPF. Ce déploiement combiné rend la transition plus facile à comprendre : l’UE change de domaine de contrôle d’accès et de mobilité, tandis que l’ancrage de service peut rester logiquement continu. La mise à jour de l’enregistrement aide le cœur 5G à prendre connaissance de ce qui existait déjà du côté 4G.

En pratique, le réseau ne se contente pas de « connecter l’utilisateur à la 5G ». Il transpose un état de mobilité et de support 4G dans un cadre de gestion de la mobilité et de session 5G. C’est pourquoi la procédure comprend le mappage du GUTI, la demande de contexte, la réponse de contexte, l’enregistrement auprès de l’UDM, la récupération de politique, la création de contexte SM et l’acceptation finale de l’enregistrement.

Comment l’enregistrement commence réellement

Avant que l’UE puisse s’enregistrer via l’accès 5G, il a besoin d’une identité que le réseau 5G peut comprendre. Dans ce scénario, l’UE mappe le 4G-GUTI existant en un 5G-GUTI conformément aux règles d’interfonctionnement. Cette identité mappée n’est pas identique à un 5G-GUTI natif attribué lors d’un enregistrement 5G antérieur, mais elle donne au réseau suffisamment d’informations pour localiser le contexte associé côté 4G.

L’UE envoie ensuite une demande d’enregistrement NAS (Registration Request). Le type d’enregistrement est une mise à jour de l’enregistrement de mobilité. La demande peut inclure le 5G-GUTI mappé, des informations d’état de l’UE et un conteneur de message EPS NAS contenant une demande TAU (Tracking Area Update). L’état de l’UE est significatif car le terminal n’est pas enregistré en mode N1 mais reste enregistré en mode S1, ce qui indique au réseau qu’il ne s’agit pas d’un démarrage 5G autonome propre, mais d’un cas d’interfonctionnement depuis le côté EPS.

Le gNodeB transmet ensuite la demande d’enregistrement à un AMF. Le choix de l’AMF dépend des informations d’identité disponibles dans la signalisation RRC. Si l’UE possède un 5G-GUTI natif, le gNodeB peut acheminer la demande vers l’AMF correspondant sur la base du GUAMI. Si l’UE ne fournit qu’une identité mappée depuis l’EPS, le gNodeB peut sélectionner un nouvel AMF en fonction des informations du GUAMI mappé.

Cette première partie de la procédure fixe la direction de tout ce qui suit. L’AMF doit maintenant comprendre d’où vient l’UE, quel MME est susceptible de détenir le contexte 4G, et comment demander ce contexte sur la bonne interface.

Comment le contexte transite par N26

Après avoir reçu la demande d’enregistrement, l’AMF extrait les informations du 5G-GUTI mappé. Il peut convertir les informations liées au GUAMI en une forme permettant d’identifier le MME correspondant. L’AMF construit alors le FQDN du nœud MME et utilise le DNS pour obtenir l’adresse de l’interface S10 du MME. Cette étape est nécessaire car l’AMF a besoin d’un chemin de transport pour demander le contexte de l’UE auprès du MME.

L’AMF envoie une demande de contexte GTPv2 (Context Request) au MME. La demande peut inclure le type RAT réglé sur NR, le 4G-GUTI mappé, le message complet de demande TAU copié depuis la demande d’enregistrement, ainsi que les informations d’adressage S10 telles que l’adresse IP et le TEID. C’est ici que N26 devient visible dans la procédure. L’AMF ne devine pas l’état de l’UE, il demande au MME le contexte qui existait déjà dans l’EPC.

Le MME utilise le contexte de sécurité 4G pour vérifier la demande TAU, puis recherche le contexte de l’UE sur la base de l’identité de l’UE. Si le contexte est trouvé et accepté, le MME renvoie une réponse de contexte GTPv2 (Context Response). Cette réponse peut inclure l’IMSI, le contexte MM, des informations relatives à la sécurité, l’UE-AMBR, les algorithmes de chiffrement et de protection d’intégrité NAS sélectionnés, des informations de restriction d’accès et des informations de connexion PDN.

Les informations de connexion PDN sont particulièrement utiles car elles relient le monde des supports 4G aux étapes ultérieures de gestion de session 5G. Elles peuvent inclure l’APN, l’EBI, l’APN-AMBR, les informations S5-C côté PGW, le contexte de support, la QoS du support et les informations S5-U côté PGW. L’AMF peut alors transformer le contexte EPS MM reçu en un contexte 5G MM.

Un transfert de contexte depuis un ancien AMF peut également avoir lieu dans certains cas. Si l’UE s’était précédemment trouvé en 5G, était passé en 4G, puis est revenu en 5G, la demande d’enregistrement peut contenir un GUTI supplémentaire (Additional GUTI). Dans cette situation, l’AMF peut contacter l’ancien AMF pour obtenir le contexte de l’UE. Mais cela est facultatif et n’apparaît pas dans tous les scénarios de mobilité en mode veille de la 4G vers la 5G.

Transfert de contexte N26 entre le MME et l'AMF montrant le 5G-GUTI mappé, la recherche DNS, la demande de contexte GTPv2, la réponse de contexte et la conversion du contexte EPS MM en contexte 5G MM
N26 permet à l’AMF de récupérer le contexte de l’UE auprès du MME et de convertir les informations de mobilité EPS en contexte de mobilité 5G.

Comment le 5GC finalise la mise à jour

Une fois que l’AMF dispose du contexte nécessaire, la procédure commence à ressembler davantage à un processus normal d’enregistrement de mobilité 5G. L’AMF interagit avec l’UDM/HSS pour terminer l’enregistrement d’accès 3GPP, obtenir les données d’abonnement d’accès et de mobilité, récupérer les données d’abonnement de sélection du SMF et s’abonner aux futurs changements de données d’abonnement. Ces étapes garantissent que l’AMF dispose des informations d’abonné correctes pour la gestion de l’accès 5G.

L’AMF peut également interagir avec la NRF pour découvrir les fonctions réseau appropriées. Par exemple, lorsque l’AMF a besoin de services UDM, il peut découvrir un UDM prenant en charge le service requis comme le SDM ou l’UECM. Lorsqu’il doit travailler avec le SMF, il peut utiliser les informations liées au FQDN du PGW-C/SMF et découvrir l’adresse de l’interface N11 du SMF par le biais de procédures liées à la NRF.

Le contrôle de politique apparaît également dans la procédure. Si l’AMF a déjà reçu des informations PCF utilisables de l’ancien AMF, il peut continuer à utiliser ce PCF. Sinon, il peut sélectionner un PCF et obtenir des informations de contrôle de politique d’accès et de mobilité. La réponse de politique peut inclure des restrictions d’accès telles que des zones ou des zones de suivi où l’accès n’est pas autorisé.

La partie relative au SMF convertit le côté session du contexte EPS hérité dans le cadre de services 5G. L’AMF demande au PGW-C/SMF de créer un contexte SM en utilisant les informations de connexion PDN EPS reçues du MME. La demande peut contenir le contexte EPS, la liste des sessions PDU à activer si elle est présente, et l’état du contexte de support EPS rapporté par l’UE. Une réponse avec un état d’activation indique que les ressources de plan utilisateur, comme le tunnel N3, sont en cours de préparation.

Enfin, l’ancien enregistrement EPC est nettoyé. Le HSS/UDM peut déclencher une annulation de localisation (Cancel Location) vers le MME, et le MME peut notifier au SGW de libérer les ressources associées. Ensuite, l’AMF envoie une acceptation d’enregistrement (Registration Accept) à l’UE. Ce message peut inclure le nouveau 5G-GUTI, le NSSAI autorisé, le temporisateur T3512, la liste de zones de suivi (TA list) et l’état du support EPS (EPS Bearer Status). L’UE vérifie l’état du support EPS reçu et supprime les règles de flux QoS ou les paramètres QoS locaux qui ne sont pas associés à l’état de support EPS indiqué. L’UE envoie ensuite un message d’enregistrement terminé (Registration Complete).

Pourquoi la mobilité en mode veille est différente

Le point clé de cette procédure est que l’UE était en mode veille lorsqu’il est entré dans la couverture 5G. Comme il n’y a pas de transfert actif de plan utilisateur en état connecté, le réseau n’a pas besoin d’effectuer une commutation de tunnel en temps réel pour une session de données en cours, comme il le ferait lors d’une mobilité en état connecté. L’accent est plutôt mis sur la migration du contexte et la mise à jour de l’enregistrement.

Cela explique pourquoi la procédure consacre autant d’efforts au mappage d’identité, à la découverte DNS, à la demande de contexte, à la conversion du contexte MM, à l’enregistrement UDM, à la récupération de politique et à la création de contexte SM. Le réseau reconstruit l’état du plan de contrôle côté 5G de l’UE à partir de l’état côté 4G. Il ne se contente pas de transférer une connexion radio active de l’eNodeB au gNodeB.

Pour les ingénieurs qui étudient la signalisation, cette distinction permet d’éviter une confusion fréquente. Voir une mobilité 4G vers 5G ne signifie pas automatiquement un transfert (handover). Si l’UE est en veille, la procédure s’apparente davantage à un ré-enregistrement contrôlé avec héritage de contexte. Si l’UE est connecté et se déplace activement, le réseau doit envisager le transfert radio et la continuité du plan utilisateur en temps réel d’une manière différente.

C’est aussi pourquoi une explication basée sur un scénario est souvent plus facile à comprendre qu’un grand diagramme de norme unique. Un diagramme de norme peut inclure de nombreuses étapes optionnelles et des scénarios combinés. Une explication pratique peut restreindre la vue : un UE attaché en 4G, passé à l’état de veille, entré dans une couverture 5G et utilisé N26 pour transférer le contexte du MME à l’AMF.

Notes finales

La procédure de mobilité en mode veille de la 4G vers la 5G n’est pas un simple changement de couverture. Il s’agit d’un processus d’interfonctionnement structuré qui permet à un UE précédemment attaché en LTE/EPC de s’enregistrer dans le 5GS par une mise à jour de l’enregistrement de mobilité. La procédure dépend fortement de N26 lorsque le réseau souhaite transférer le contexte de l’UE entre le MME et l’AMF.

La logique la plus importante est la continuité du contexte. L’UE mappe le 4G-GUTI en 5G-GUTI, le gNodeB transmet la demande d’enregistrement, l’AMF découvre le MME, le MME renvoie les contextes EPS MM et SM, et l’AMF convertit et poursuit l’enregistrement côté 5G. Les interactions avec l’UDM, la NRF, le PCF et le SMF achèvent ensuite la préparation de l’abonnement, de la découverte, de la politique et du contexte de session.

Pour l’apprentissage des réseaux, la leçon pratique est claire : la mobilité en mode veille de la 4G vers la 5G effectue principalement une migration du contexte de l’UE de l’EPC vers le 5GC. Il ne faut pas la confondre avec le transfert en état connecté, où le chemin du plan utilisateur en temps réel doit être commuté pendant que l’UE reste actif.

FAQ

Quel est le type d’enregistrement dans ce scénario ?

Le type d’enregistrement est une mise à jour de l’enregistrement de mobilité (Mobility Registration Update). Il diffère de l’enregistrement initial car l’UE possède déjà un contexte côté 4G provenant de l’attachement LTE/EPC précédent.

Pourquoi l’interface N26 est-elle importante ?

N26 permet à l’AMF et au MME d’échanger le contexte de l’UE, ce qui permet au cœur 5G d’obtenir les informations de mobilité et de session précédemment détenues dans l’EPC.

Qu’est-ce qui change lorsque l’UE passe de la 4G à la 5G ?

Le côté accès passe de l’eNodeB au gNodeB, et la fonction de gestion de la mobilité passe du MME à l’AMF. Certaines fonctions de cœur combinées, comme HSS/UDM ou PGW-C/SMF, peuvent rester logiquement continues.

La mobilité en mode veille nécessite-t-elle un transfert en temps réel du plan utilisateur ?

Non. Dans ce scénario, l’UE est en veille, la tâche principale est donc la migration du contexte et la mise à jour de l’enregistrement, plutôt qu’une commutation de tunnel en temps réel du plan utilisateur.

Que reçoit l’UE à la fin ?

L’UE reçoit une acceptation d’enregistrement (Registration Accept), qui peut inclure un nouveau 5G-GUTI, le NSSAI autorisé, un temporisateur d’enregistrement, une liste de zones de suivi et l’état du support EPS. L’UE termine ensuite la procédure par un message d’enregistrement terminé (Registration Complete).

Produits recommandés
catalogue
Service à la clientèle Téléphone
We use cookie to improve your online experience. By continuing to browse this website, you agree to our use of cookie.

Cookies

This Cookie Policy explains how we use cookies and similar technologies when you access or use our website and related services. Please read this Policy together with our Terms and Conditions and Privacy Policy so that you understand how we collect, use, and protect information.

By continuing to access or use our Services, you acknowledge that cookies and similar technologies may be used as described in this Policy, subject to applicable law and your available choices.

Updates to This Cookie Policy

We may revise this Cookie Policy from time to time to reflect changes in legal requirements, technology, or our business practices. When we make updates, the revised version will be posted on this page and will become effective from the date of publication unless otherwise required by law.

Where required, we will provide additional notice or request your consent before applying material changes that affect your rights or choices.

What Are Cookies?

Cookies are small text files placed on your device when you visit a website or interact with certain online content. They help websites recognize your browser or device, remember your preferences, support essential functionality, and improve the overall user experience.

In this Cookie Policy, the term “cookies” also includes similar technologies such as pixels, tags, web beacons, and other tracking tools that perform comparable functions.

Why We Use Cookies

We use cookies to help our website function properly, remember user preferences, enhance website performance, understand how visitors interact with our pages, and support security, analytics, and marketing activities where permitted by law.

We use cookies to keep our website functional, secure, efficient, and more relevant to your browsing experience.

Categories of Cookies We Use

Strictly Necessary Cookies

These cookies are essential for the operation of the website and cannot be disabled in our systems where they are required to provide the service you request. They are typically set in response to actions such as setting privacy preferences, signing in, or submitting forms.

Without these cookies, certain parts of the website may not function correctly.

Functional Cookies

Functional cookies enable enhanced features and personalization, such as remembering your preferences, language settings, or previously selected options. These cookies may be set by us or by third-party providers whose services are integrated into our website.

If you disable these cookies, some services or features may not work as intended.

Performance and Analytics Cookies

These cookies help us understand how visitors use our website by collecting information such as traffic sources, page visits, navigation behavior, and general interaction patterns. In many cases, this information is aggregated and does not directly identify individual users.

We use this information to improve website performance, usability, and content relevance.

Targeting and Advertising Cookies

These cookies may be placed by our advertising or marketing partners to help deliver more relevant ads and measure the effectiveness of campaigns. They may use information about your browsing activity across different websites and services to build a profile of your interests.

These cookies generally do not store directly identifying personal information, but they may identify your browser or device.

First-Party and Third-Party Cookies

Some cookies are set directly by our website and are referred to as first-party cookies. Other cookies are set by third-party services, such as analytics providers, embedded content providers, or advertising partners, and are referred to as third-party cookies.

Third-party providers may use their own cookies in accordance with their own privacy and cookie policies.

Information Collected Through Cookies

Depending on the type of cookie used, the information collected may include browser type, device type, IP address, referring website, pages viewed, time spent on pages, clickstream behavior, and general usage patterns.

This information helps us maintain the website, improve performance, enhance security, and provide a better user experience.

Your Cookie Choices

You can control or disable cookies through your browser settings and, where available, through our cookie consent or preference management tools. Depending on your location, you may also have the right to accept or reject certain categories of cookies, especially those used for analytics, personalization, or advertising purposes.

Please note that blocking or deleting certain cookies may affect the availability, functionality, or performance of some parts of the website.

Restricting cookies may limit certain features and reduce the quality of your experience on the website.

Cookies in Mobile Applications

Where our mobile applications use cookie-like technologies, they are generally limited to those required for core functionality, security, and service delivery. Disabling these essential technologies may affect the normal operation of the application.

We do not use essential mobile application cookies to store unnecessary personal information.

How to Manage Cookies

Most web browsers allow you to manage cookies through browser settings. You can usually choose to block, delete, or receive alerts before cookies are stored. Because browser controls vary, please refer to your browser provider’s support documentation for details on how to manage cookie settings.

Contact Us

If you have any questions about this Cookie Policy or our use of cookies and similar technologies, please contact us at support@becke.cc .