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.

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.

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).