À quel abonné cet UE appartient-il ?

Est-il autorisé à accéder au réseau actuel ?

Existe-t-il un ancien contexte de mobilité qui puisse encore être réutilisé ?

À quelles tranches de réseau et capacités d’accès l’UE est-il abonné, et quel AMF doit le prendre en charge ?

Lorsqu’un terminal 5G s’allume, le cœur de réseau doit répondre à ces questions fondamentales avant que les services de données utilisateur puissent être établis. Elles sont traitées pendant l’enregistrement initial 5G. Du point de vue d’une trace de signalisation, la procédure va bien au-delà d’un simple « Registration Request suivi d’un enregistrement réussi ». Entre l’envoi du Registration Request par l’UE et le retour final du Registration Complete, le réseau peut traiter l’identité, récupérer le contexte d’un ancien AMF, effectuer l’authentification 5G-AKA, établir la sécurité NAS, enregistrer l’AMF auprès de l’UDM, récupérer les données d’abonnement et appliquer la politique d’accès.

Une erreur courante lors de l’étude de cette procédure consiste à vouloir mémoriser chaque message dans l’ordre. Une approche plus pratique consiste à se demander quel problème l’AMF résout à chaque étape. Le chemin complet de signalisation peut se résumer ainsi : identifier l’UE à l’origine de la demande, établir une identité de confiance, compléter le contexte d’abonné nécessaire, puis seulement finaliser l’enregistrement.

L’enregistrement initial établit le droit de l’UE à accéder au réseau

L’enregistrement dans le 5GS n’est pas une procédure unique. Selon le déclencheur, l’UE peut effectuer une Initial Registration, une Mobility Registration Update, une Periodic Registration Update ou une Emergency Registration. L’UE indique la procédure applicable dans le champ 5GS registration type du Registration Request.

L’Initial Registration se produit généralement lorsqu’un UE s’allume et rejoint le 5GS. À des fins pédagogiques, elle est souvent comparée à la procédure Attach de LTE/EPC, mais les deux ne doivent pas être considérées comme identiques. Dans l’architecture orientée services du 5G Core, la gestion de la mobilité, l’authentification, les données d’abonnement et le contrôle des politiques sont répartis entre des fonctions réseau telles que l’AMF, l’AUSF, l’UDM et le PCF. Une seule procédure d’enregistrement peut donc impliquer plusieurs interactions orientées services entre fonctions réseau.

Plus important encore, l’Initial Registration établit principalement l’état de gestion de l’accès et de la mobilité et non une session de données utilisateur. Le réseau doit identifier l’UE, établir son contexte de mobilité, déterminer la NSSAI autorisée et les restrictions de zone applicables, puis créer la relation de sécurité nécessaire à la signalisation suivante. Ce n’est qu’une fois ces conditions réunies que l’UE dispose des bases nécessaires pour demander une PDU Session.

Ainsi, recevoir un Registration Accept ne signifie pas automatiquement que l’abonné peut déjà accéder à Internet. L’enregistrement et l’établissement d’une PDU Session sont deux étapes distinctes du 5G Core.

Le Registration Request fait entrer l’UE dans la procédure du 5G Core

La procédure d’enregistrement du cœur de réseau commence par le NAS Registration Request. L’UE envoie d’abord le message NAS au gNB sur l’interface radio. Le gNB transporte ensuite la NAS-PDU vers l’AMF dans un NGAP Initial UE Message. Pour un ingénieur du cœur de réseau, ce message constitue le point d’entrée de toute la procédure d’enregistrement.

En plus de transporter le Registration Request, l’Initial UE Message fournit à l’AMF des informations de localisation d’accès telles que le NR-CGI et le TAI. Le message NAS lui-même peut contenir des paramètres comme le 5GS registration type, la 5GS mobile identity, l’UE Security Capability et la Requested NSSAI.

Ces paramètres ne constituent pas une simple liste de capacités de l’UE. L’AMF les utilise pour déterminer la suite de l’enregistrement. Le Registration Type indique si l’UE effectue une Initial Registration ou un autre type de mise à jour d’enregistrement. La mobile identity permet de déterminer si un contexte d’abonné existant peut être associé à l’UE. La Requested NSSAI indique les tranches de réseau demandées par l’UE, tandis que l’UE Security Capability fournit les éléments nécessaires au choix ultérieur des algorithmes de sécurité NAS.

Un point est facile à mal interpréter : un UE qui effectue une Initial Registration ne part pas nécessairement sans aucune information 5G antérieure. S’il conserve un 5G-GUTI précédemment attribué, il peut inclure cette identité dans un nouveau Initial Registration Request. La possibilité pour le réseau de réutiliser les informations associées à cette identité influence directement les étapes suivantes.

Le nouvel AMF résout l’identité et récupère l’ancien contexte de l’UE

Prenons un UE précédemment enregistré dans un 5GS à Guangzhou, puis éteint, déplacé à Beijing et rallumé via un gNB de Beijing. L’UE est maintenant pris en charge par un nouvel AMF, mais il peut encore conserver le 5G-GUTI attribué auparavant par l’AMF de Guangzhou.

Le GUAMI contenu dans le 5G-GUTI peut fournir des informations permettant d’identifier l’ancien AMF. Si le nouvel AMF estime que l’ancienne fonction réseau peut encore détenir un contexte UE utile, il peut demander un UE Context Transfer via la communication inter-AMF et récupérer des informations telles que le SUPI, le GPSI, le PEI ainsi que certaines parties du contexte de gestion de mobilité.

Cela illustre un point important : « Initial » décrit le type de la procédure d’enregistrement en cours. Il ne signifie pas que l’abonné entre dans un réseau 5G pour la première fois. L’UE peut encore posséder une identité 5G attribuée auparavant et le nouvel AMF peut être en mesure de réutiliser le contexte de l’ancien AMF.

Une interaction avec l’ancien AMF n’est pas nécessaire dans chaque Initial Registration. Si le nouvel AMF dispose déjà des informations d’identité requises, ou si aucun ancien contexte UE n’est disponible, le chemin de signalisation peut être différent. Si l’AMF a encore besoin du SUCI de l’UE, il peut envoyer un Identity Request, auquel l’UE répond par un Identity Response contenant l’identité demandée.

Par conséquent, l’absence d’un Identity Request ou d’un UE Context Transfer dans une trace de paquets n’indique pas à elle seule un échec d’enregistrement. La première question à se poser est de savoir quelles informations d’identité et de contexte l’AMF possède déjà.

5G-AKA transforme une identité déclarée en abonné de confiance

Savoir qui l’UE prétend être ne suffit pas pour que le réseau lui fasse confiance. La procédure passe donc à l’une de ses étapes de sécurité les plus importantes : l’authentification.

L’AMF doit identifier un AUSF capable d’authentifier l’abonné. Dans un 5G Core orienté services, cela implique généralement une découverte de fonctions réseau via le NRF. En fonction du service requis et des informations liées à l’abonné, l’AMF sélectionne une instance AUSF appropriée et lui envoie une demande d’authentification.

L’AUSF travaille ensuite avec les fonctions d’authentification associées à l’UDM du réseau d’origine. Lorsque le SUCI est utilisé, le réseau d’origine peut retrouver le SUPI correspondant et préparer les données d’authentification nécessaires à 5G-AKA. L’AMF transmet ensuite des paramètres tels que RAND et AUTN à l’UE dans un NAS Authentication Request. L’UE effectue le calcul d’authentification avec les informations d’identification stockées dans l’USIM et renvoie un Authentication Response contenant RES*.

L’authentification ne repose pas sur une seule comparaison effectuée par une unique fonction réseau. Le côté du réseau de desserte et le réseau d’origine réalisent leurs vérifications respectives. L’AMF dérive HRES* de la réponse reçue de l’UE et le compare à HXRES*. L’AUSF vérifie le RES* retourné par rapport au XRES* attendu. Ce n’est que lorsque les vérifications requises réussissent que le réseau accepte l’identité de l’abonné comme authentifiée.

Après l’authentification, le réseau établit ou met généralement à jour le NAS Security Context. À partir d’informations telles que l’UE Security Capability, l’AMF sélectionne des algorithmes appropriés de protection de l’intégrité et de chiffrement, puis utilise la procédure Security Mode afin de protéger la signalisation NAS critique qui suit.

D’un point de vue d’ingénierie, cette étape forme une frontière de sécurité claire : avant l’authentification, le réseau traite un terminal qui demande l’accès ; après l’établissement réussi de l’authentification et de la sécurité NAS, l’AMF dispose d’un contexte de plan de contrôle UE fiable et protégé.

Les données d’abonnement et de politique complètent le contexte UE

Une authentification réussie répond à la question de l’authenticité de l’identité de l’abonné, mais l’AMF doit encore savoir ce que cet abonné est réellement autorisé à faire dans le réseau. L’étape suivante transforme une identité authentifiée en un contexte exploitable d’accès et de mobilité.

L’AMF sélectionne l’UDM approprié et s’y enregistre comme l’AMF qui dessert actuellement le SUPI via l’accès 3GPP. Cet enregistrement est important, car l’UDM doit savoir quel AMF doit recevoir ultérieurement les notifications liées à la mobilité, les événements de désenregistrement ou les modifications des données d’abonnement de cet abonné.

L’AMF récupère ensuite les Access and Mobility Subscription Data. Selon le profil d’abonnement, celles-ci peuvent inclure la Subscribed NSSAI, l’UE-AMBR, les paramètres d’enregistrement périodique, les restrictions RAT et les restrictions de zone. L’authentification confirme donc que l’identité est valide, tandis que les données d’abonnement répondent à une autre question : que peut faire cet abonné valide dans le réseau actuel ?

L’AMF peut également récupérer des données d’abonnement destinées à une future sélection du SMF, notamment des informations associées au S-NSSAI, aux DNN et à un DNN par défaut. Cela prête souvent à confusion lors de la lecture des traces : si les SMF Selection Subscription Data apparaissent déjà pendant l’enregistrement, le SMF fait-il déjà partie de la procédure ?

Pas nécessairement. À ce stade, l’AMF récupère uniquement des informations susceptibles d’être nécessaires pour une future sélection du SMF. L’Initial Registration n’impose pas l’établissement simultané d’une PDU Session ; l’AMF peut donc obtenir ces données d’abonnement sans créer de SM Context ni engager une procédure active de gestion de session avec un SMF.

Pour la politique d’accès, l’AMF peut également sélectionner un PCF et établir une AM Policy Association. Les politiques renvoyées par le PCF peuvent influer, par exemple, sur les restrictions d’accès à certaines zones. À ce stade, le contexte UE détenu par l’AMF a évolué d’une simple identité vers un ensemble combinant identité, sécurité, abonnement, découpage réseau, localisation et informations de politique.

Le Registration Accept applique le résultat à l’UE et au gNB

La majeure partie des traitements précédents se déroule à l’intérieur du cœur de réseau. Le résultat final doit néanmoins être transmis au réseau d’accès et à l’UE. Une fois les conditions requises remplies, l’AMF envoie un Initial Context Setup Request au gNB, avec les informations nécessaires pour établir le contexte UE, tout en acheminant le NAS Registration Accept vers l’UE.

Un Registration Accept peut inclure un nouveau 5G-GUTI, l’Allowed NSSAI, le temporisateur d’enregistrement périodique T3512 et la liste des zones de suivi applicable. Ces paramètres déterminent comment l’UE reste enregistré dans le 5GS, quelles tranches de réseau il peut actuellement utiliser et à quel moment il devra ensuite effectuer un Periodic Registration Update.

En parallèle, le gNB établit le contexte UE correspondant au moyen de la procédure Initial Context Setup. Une fois son traitement terminé, le gNB renvoie un Initial Context Setup Response. L’UE confirme ensuite le résultat de l’enregistrement en envoyant un NAS Registration Complete à l’AMF.

Registration Accept et Registration Complete sont donc plus que de simples notifications de succès. Ils appliquent le résultat d’enregistrement produit dans le cœur de réseau à l’UE et au RAN, afin que le réseau, le gNB et le terminal atteignent un état d’enregistrement 5GS cohérent.

L’enregistrement et l’établissement d’une PDU Session suivent des chemins de signalisation distincts

Cette distinction est essentielle lors de l’analyse de la séquence complète de signalisation. Une fois la 5GS Initial Registration terminée, l’AMF sait qui est l’abonné, où se trouve l’UE, quelles zones d’accès et quelles tranches de réseau sont autorisées, et quels contextes de sécurité et de mobilité s’appliquent. Aucune de ces étapes n’établit automatiquement un chemin de données sur le plan utilisateur.

Pour accéder à Internet ou à un réseau de données d’entreprise, l’UE doit encore effectuer un PDU Session Establishment. À ce stade, le SMF prend en charge la gestion de session, sélectionne ou contrôle l’UPF et provisionne via N4 des règles du plan utilisateur telles que PDR, FAR, QER et URR. Les ressources N3 entre le gNB et l’UPF sont également préparées dans le cadre de l’établissement de la session.

En dépannage opérationnel, cette séparation crée deux catégories de panne très différentes :

Échec de l’enregistrement : se concentrer sur l’identité de l’UE, l’authentification, la sécurité NAS, les données d’abonnement UDM, la NSSAI, les restrictions de zone et le traitement des politiques par l’AMF.

Enregistrement réussi mais service de données indisponible : déplacer l’analyse vers le PDU Session Establishment, le SMF, l’UPF, la signalisation N3/N4 et l’acheminement du plan utilisateur, plutôt que de réexaminer sans cesse Registration Request et Registration Accept.

Garder cette frontière clairement en tête peut réduire considérablement le temps de dépannage du 5GC. L’indication 5G affichée sur le terminal montre seulement que l’accès radio et l’enregistrement ont atteint un certain état. L’existence d’une véritable connexion de données dépend encore des procédures de gestion de session et du plan utilisateur.

Lire la trace comme une transition d’état, pas comme une liste de messages

Les diagrammes de signalisation standard sont volontairement complets, car ils doivent couvrir différents opérateurs, scénarios d’itinérance, types d’accès et fonctions réseau optionnelles. Une trace réelle ne contient cependant pas nécessairement toutes les étapes d’une procédure de référence. Il peut ne pas y avoir d’interaction avec l’ancien AMF, un Identity Request peut être inutile, l’EIR peut ne pas être utilisé, et une procédure d’accès NR classique n’inclut pas les fonctions réseau réservées à d’autres types d’accès.

Une manière plus utile de dépanner l’Initial Registration consiste à suivre l’évolution de l’état de l’UE :

Registration Request atteint l’AMF
→ l’identité de l’UE et l’ancien contexte sont résolus
→ l’authentification et la sécurité NAS sont établies
→ les données d’abonnement sont récupérées depuis l’UDM
→ la politique d’accès applicable est obtenue auprès du PCF
→ l’AMF complète le contexte d’enregistrement
→ Registration Accept est transmis
→ l’UE renvoie Registration Complete

Si le Registration Request atteint l’AMF mais que l’authentification ne commence jamais, il faut d’abord examiner le traitement de l’identité et la sélection des fonctions réseau. Si l’authentification réussit mais que Registration Accept n’est pas renvoyé, poursuivre avec les données UDM, la NSSAI, les restrictions d’accès et le traitement des politiques. Si Registration Accept est déjà terminé et que le problème concerne uniquement les données utilisateur, l’analyse doit rapidement se déplacer vers le chemin de signalisation de la PDU Session.

Comprendre la 5G Initial Registration consiste donc moins à mémoriser des dizaines de messages qu’à suivre la manière dont le contexte UE dans l’AMF se complète progressivement : recevoir une demande d’accès, déterminer qui est l’abonné, prouver que cette identité est fiable, puis déterminer dans quelles conditions cet abonné est autorisé à rester enregistré dans le 5GS.

Questions fréquentes

Quel est le rôle de T3512 dans Registration Accept ?

T3512 contrôle le comportement de mise à jour périodique de l’enregistrement de l’UE après son enregistrement. Un UE ne reste pas enregistré indéfiniment sans interaction périodique de gestion de mobilité. Le réseau peut utiliser ce temporisateur pour définir quand l’UE doit effectuer un Periodic Registration Update.

Pourquoi l’EIR est-il absent de certaines traces d’enregistrement 5G commerciales ?

La vérification de l’identité de l’équipement est optionnelle. Le déploiement d’un EIR et les conditions déclenchant un contrôle de l’identité de l’équipement dépendent de l’architecture et des politiques opérationnelles de l’opérateur. L’absence de signalisation EIR dans une procédure d’Initial Registration par ailleurs normale ne constitue donc pas une preuve suffisante de panne.

Pourquoi N3IWF est-il normalement absent d’un enregistrement 5G NR standard ?

N3IWF est principalement utilisé pour des accès non fiables non-3GPP, par exemple certains scénarios d’accès Wi-Fi au 5G Core. Lorsque l’UE se connecte directement via un gNB sur un accès NR 3GPP standard, le NG-RAN fournit le chemin d’accès ; N3IWF ne fait donc normalement pas partie de la signalisation d’enregistrement.

Pourquoi le nombre d’opérations de découverte des fonctions réseau via le NRF peut-il varier entre les traces de différents fournisseurs ?

Les implémentations réelles du 5G Core peuvent différer en raison du cache de découverte des fonctions réseau, de la configuration statique, des modèles de déploiement SCP et du routage de services propre aux fournisseurs. Un échange complet de découverte des fonctions réseau via le NRF ne doit donc pas nécessairement apparaître avant chaque opération de service. L’analyse d’une trace doit corréler l’instance NF sélectionnée avec la demande de service suivante plutôt que de juger la procédure uniquement d’après le nombre de messages NRF.