Une Registration Request est déjà parvenue à un AMF ; pourquoi l’AMF qui dessert l’UE devrait-il encore changer pendant l’enregistrement ? Cela signifie-t-il que le gNB a sélectionné le mauvais AMF ? Si l’UE n’inclut pas de Requested NSSAI dans la Registration Request, à quel moment le réseau peut-il déterminer le slice réseau dont l’UE a réellement besoin ? Ces questions renvoient à une branche particulière de l’Initial Registration 5GC : la réaffectation d’AMF. Dans les échanges d’ingénierie, on parle souvent de « resélection d’AMF », alors que la procédure 3GPP la décrit plus précisément comme une réaffectation de l’AMF pendant l’enregistrement.
La différence essentielle entre la réaffectation d’AMF et un Initial Registration normal ne tient ni à une authentification supplémentaire ni à un changement d’AMF motivé par l’équilibrage de charge. L’Initial AMF obtient des informations plus complètes sur l’abonnement et les slices, constate qu’il ne peut pas desservir le S-NSSAI finalement requis par l’UE, sollicite le NSSF pour identifier un périmètre de service AMF approprié, puis transfère la procédure d’enregistrement à un Target AMF.
Pour comprendre ce flux de signalisation, il est plus utile de suivre trois décisions successives que de mémoriser l’étape précise à laquelle l’AMF change : quelles informations le gNB possède lors de la première sélection d’AMF, quelles informations supplémentaires l’Initial AMF apprend pendant l’enregistrement et quels critères le NSSF utilise finalement pour orienter l’UE vers un nouvel AMF de service.
Quand la réaffectation d’AMF est-elle déclenchée ?
L’Initial Registration avec réaffectation d’AMF n’est pas le chemin par défaut de tous les enregistrements 5GC. Les conditions de déclenchement sont précises : le Network Slicing est déployé et l’AMF qui reçoit initialement la Registration Request ne peut pas desservir le slice réseau finalement requis par l’UE.
Dans un scénario d’enregistrement normal, l’Initial AMF sélectionné par le gNB prend déjà en charge le S-NSSAI requis. Le traitement de l’identité, l’authentification, la récupération des données d’abonnement et le Registration Accept peuvent donc rester sur le même AMF pendant toute la procédure.
La réaffectation ne devient nécessaire que lorsque des informations obtenues plus tard montrent que l’AMF actuel ne correspond pas au slice que l’UE est autorisé à utiliser ou qu’il doit utiliser par défaut. La logique peut se résumer ainsi :
La Registration Request atteint l’Initial AMF
→ L’Initial AMF effectue le traitement d’enregistrement nécessaire
→ Les informations complètes d’abonnement et de slices de l’UE sont obtenues
→ L’Initial AMF détermine qu’il ne peut pas desservir le S-NSSAI cible
→ Le NSSF est sollicité pour déterminer le périmètre de service approprié
→ L’enregistrement est transféré au Target AMF
Il faut éviter une confusion fréquente : la présence de deux AMF dans une même trace d’enregistrement ne signifie pas automatiquement que l’AMF d’origine est tombé en panne ou qu’un équilibrage de charge dans un AMF Pool a eu lieu. Dans cette procédure, le véritable déclencheur est une incompatibilité entre la capacité de l’AMF actuel à desservir les slices et le slice réseau finalement requis par l’UE.
Pourquoi le gNB peut-il sélectionner initialement un AMF inadapté ?
Lorsqu’on découvre la réaffectation d’AMF, il est facile de supposer que le gNB s’est trompé. Si différents AMF desservent différents slices, pourquoi le RAN n’envoie-t-il pas directement l’UE vers le bon AMF dès le départ ?
La raison principale est que le gNB peut ne pas disposer de suffisamment d’informations lorsqu’il effectue la sélection initiale de l’AMF. Prenons un véhicule connecté qui démarre pour la première fois avec une USIM 5G abonnée à deux slices réseau :
Slice eMBB (S-NSSAI1) : utilisé pour l’infodivertissement à bord et les services de données généraux ;
Slice V2X (S-NSSAI3) : utilisé pour les communications véhicule-à-tout (V2X) et les services liés à la conduite automatisée.
Supposons que le Default S-NSSAI de l’abonné soit le slice V2X, mais que l’UE entre dans le 5GS pour la première fois, ne possède pas de 5G-GUTI valide et n’inclue pas de Requested NSSAI dans la Registration Request. À ce stade, le gNB n’a aucun moyen direct de savoir que l’UE devra finalement être desservi par l’AMF associé au slice V2X.
Dans des conditions normales, le gNB peut utiliser des informations telles que le GUAMI, le S-NSSAI demandé par l’UE et sa configuration AMF locale lors de la sélection d’un AMF. Ici, toutefois, le GUAMI et le Requested NSSAI ne sont pas disponibles ; le gNB ne peut donc sélectionner un Initial AMF qu’à partir des informations dont il dispose et de sa politique locale de sélection par défaut.
Si le gNB sélectionne d’abord AMF1, qui dessert le slice eMBB, la Registration Request est transportée vers AMF1 dans un NGAP Initial UE Message.
Le fait que cet AMF ne corresponde pas au besoin final de slice de l’UE ne signifie pas nécessairement que le gNB est mal configuré. Une interprétation plus exacte est la suivante : au moment de la première sélection d’AMF, le RAN ne dispose pas encore de suffisamment d’informations pour déterminer l’AMF spécifique au slice final de l’UE.
Comment l’Initial AMF détecte-t-il l’incompatibilité de slice ?
Lorsque la Registration Request atteint l’Initial AMF, celui-ci n’interroge pas immédiatement le NSSF. À ce stade, il ne dispose toujours pas de suffisamment d’informations sur l’abonné pour déterminer s’il est bien l’AMF de service final.
L’AMF suit d’abord la logique normale de l’Initial Registration et exécute les procédures nécessaires, notamment le traitement de l’identité de l’UE, la sélection de l’AUSF, l’authentification 5G-AKA et les procédures de sécurité NAS associées.
L’un des résultats essentiels de cette phase est la confirmation de l’identité de l’UE et l’obtention du SUPI par l’AMF. Une fois le SUPI disponible, l’Initial AMF peut localiser l’UDM approprié et récupérer les Access and Mobility Subscription Data de l’UE.
À ce stade, le réseau dispose de beaucoup plus d’informations qu’au moment où la Registration Request est arrivée. Les données d’abonnement renvoyées par l’UDM peuvent inclure le Subscribed NSSAI et le Default S-NSSAI de l’abonné.
Reprenons l’exemple du véhicule connecté : l’Initial AMF appartient au domaine de service eMBB, mais les données d’abonnement montrent que l’UE est abonné à eMBB et à V2X, le Default S-NSSAI pointant vers V2X, c’est-à-dire S-NSSAI3.
L’Initial AMF peut alors tirer une conclusion que le gNB ne pouvait pas tirer auparavant : même s’il a pu recevoir l’Initial Registration et commencer à le traiter, il n’est pas l’AMF approprié pour assurer durablement le service du slice V2X par défaut de l’UE. Cette conclusion constitue le point de déclenchement de la réaffectation d’AMF.
Étape gNB : seules des informations d’accès limitées sont disponibles
→ Étape Initial AMF : l’identité de l’UE est confirmée
→ Étape UDM : les informations réelles sur le NSSAI souscrit sont obtenues
→ L’AMF actuel est jugé incompatible avec le slice cible
La réaffectation d’AMF n’est donc pas un changement arbitraire de décision en cours d’enregistrement. Elle intervient parce que le cœur de réseau peut prendre une décision plus précise sur l’AMF de service une fois que l’identité de l’abonné et les informations de slice sont complètes.
Comment le NSSF identifie-t-il le nouvel AMF de service ?
Dès que l’Initial AMF détermine qu’il ne peut pas desservir le slice cible, il ne choisit pas simplement un autre AMF de lui-même. Il sollicite la Network Slice Selection Function, ou NSSF.
L’Initial AMF utilise le service Nnssf_NSSelection pour demander une Network Slice Selection. Les entrées peuvent inclure le S-NSSAI souscrit par l’UE, des informations sur l’AMF actuel et le TAI actuel de l’UE. L’objectif est de déterminer quels slices sont autorisés dans la zone d’enregistrement actuelle et quel ensemble d’AMF doit assurer le service.
Les Authorized Network Slice Information renvoyées par le NSSF peuvent inclure :
Allowed NSSAI : les slices réseau que l’UE est autorisé à utiliser dans les conditions actuelles ;
Configured NSSAI : la configuration de slices pouvant être fournie à l’UE lorsque nécessaire ;
Target AMF Set : l’ensemble des AMF capables de desservir le slice réseau concerné ;
Rejected NSSAI : les slices qui ne peuvent pas être acceptés dans le TA actuel ou dans les conditions associées.
Il est important de distinguer Target AMF Set et Target AMF. La première responsabilité du NSSF est de déterminer quel ensemble d’AMF est approprié, en réduisant le périmètre des candidats selon les conditions de slice et de localisation, plutôt que de renvoyer directement l’adresse d’un AMF précis.
Après obtention du Target AMF Set, l’Initial AMF peut utiliser les informations d’instances NF enregistrées dans le NRF afin de récupérer les adresses, capacités, poids et états opérationnels des AMF de cet ensemble. Il peut alors déterminer quel Target AMF précis doit reprendre le Registration.
La relation peut se résumer ainsi :
UDM : fournit les informations d’abonnement aux slices de l’UE
→ Initial AMF : détermine que sa propre capacité de service ne correspond pas
→ NSSF : détermine les slices autorisés et le Target AMF Set
→ NRF : fournit les informations sur les instances AMF disponibles dans l’ensemble
→ Initial AMF : sélectionne le Target AMF
Dans cette procédure, le rôle du NSSF n’est pas celui d’un équilibrage de charge classique. Il associe une exigence de slice à un périmètre de service AMF capable de la prendre en charge.
Comment la Registration Request est-elle transférée au Target AMF ?
Une fois le Target AMF déterminé, l’UE n’a pas besoin d’envoyer une nouvelle Registration Request complète. Le réseau doit seulement transférer la procédure d’enregistrement déjà en cours, avec le contexte nécessaire, afin que le nouvel AMF poursuive le traitement.
Deux mécanismes de transfert sont possibles : un transfert indirect via le gNB ou un transfert direct entre l’Initial AMF et le Target AMF.
Transfert indirect via le gNB
En transfert indirect, l’Initial AMF envoie au gNB un NGAP Reroute NAS Request. Le message transporte des informations associées à l’Initial UE Message d’origine ainsi que le Target AMF Set ID, et demande au NG-RAN de rerouter le message NAS Registration en cours.
Le gNB envoie ensuite au Target AMF un nouvel Initial UE Message contenant le NAS-PDU de la Registration Request d’origine. Le chemin du plan de contrôle peut être représenté ainsi :
UE → gNB → Initial AMF → Reroute NAS Request → gNB → Target AMF
L’UE n’a pas besoin d’effectuer un nouvel accès RRC. Le NG-RAN reroute simplement le message NAS Registration existant vers l’AMF approprié.
Transfert direct entre AMF
En transfert direct, l’Initial AMF ne renvoie pas le message via le gNB. Il transfère directement le message N1 et le Registration Context au Target AMF par l’interface basée sur les services du 5GC.
L’Initial AMF invoque Namf_Communication_N1MessageNotify et envoie la Registration Request complète avec le Registration Context Container au Target AMF.
Les informations transférées ne se limitent pas à un seul message NAS. Le Registration Context peut également inclure UE Context, Access Type, des informations sur le gNB, User Location, Allowed NSSAI, Configured NSSAI, Rejected NSSAI et d’autres informations nécessaires pour poursuivre le traitement de l’enregistrement.
UE → gNB → Initial AMF → Namf_Communication_N1MessageNotify → Target AMF
Les chemins de signalisation diffèrent, mais l’objectif reste le même : le Target AMF reçoit le message NAS et le contexte nécessaires pour poursuivre le Registration sans redémarrer toute la procédure d’Initial Registration.
Après avoir pris le relais, le Target AMF termine le traitement d’enregistrement restant et renvoie un Registration Accept à l’UE. La réponse reflète les résultats de la sélection de slice et de la réaffectation d’AMF ; elle peut inclure Allowed NSSAI, Configured NSSAI, Rejected NSSAI ainsi qu’un nouveau 5G-GUTI.
Du point de vue de l’UE, le résultat important est que l’enregistrement aboutit et que le réseau lui fournit les slices disponibles dans la zone actuelle ainsi que le nouveau contexte de mobilité 5GS. Le changement interne d’AMF de service reste transparent pour l’UE.
Comment vérifier une réaffectation d’AMF dans une trace de signalisation ?
Un Initial Registration avec réaffectation d’AMF peut facilement être confondu avec un routage d’enregistrement anormal ou une première sélection d’AMF ayant échoué. Une méthode de dépannage plus efficace consiste non pas à comparer les numéros de messages un à un, mais à suivre deux fils principaux : la détermination du slice et le transfert du contexte.
Une séquence de signalisation normale doit permettre à l’ingénieur de répondre aux questions suivantes :
Pourquoi la Registration Request a-t-elle d’abord atteint cet Initial AMF ?
→ Où l’Initial AMF a-t-il obtenu le Subscribed / Default NSSAI de l’UE ?
→ Qu’est-ce qui a conduit l’AMF à déterminer qu’il ne pouvait pas continuer à desservir l’UE ?
→ Quel Target AMF Set le NSSF a-t-il renvoyé ?
→ Quel Target AMF précis a finalement été sélectionné ?
→ Quel chemin a été utilisé pour transférer le Registration Context ?
Si l’Initial AMF a déjà obtenu les informations d’abonnement aux slices et déterminé qu’il ne peut pas desservir l’UE, mais qu’aucune procédure de sélection NSSF ne suit, l’analyse doit se concentrer sur la découverte du NSSF, la requête Nnssf_NSSelection et la configuration de slice associée.
Si le NSSF renvoie un Target AMF Set mais qu’aucun Target AMF précis ne peut être identifié, les vérifications suivantes doivent porter sur la configuration de l’AMF Set, les NF Profiles dans le NRF, l’état des instances AMF et leurs informations de capacité.
Si un NGAP Reroute NAS Request est présent mais que le Target AMF ne reçoit jamais le nouvel Initial UE Message, le dépannage doit quitter la sélection de slice pour se concentrer sur le reroutage NAS au niveau du gNB et la joignabilité N2 vers le Target AMF.
Si le transfert direct est utilisé, la trace doit être vérifiée pour Namf_Communication_N1MessageNotify et le Registration Context, au lieu d’attendre un Reroute NAS Request qui n’apparaîtra pas sur ce chemin.
En considérant l’ensemble de la procédure, la réaffectation d’AMF résout un problème précis : les informations disponibles lors de la première sélection d’AMF sont incomplètes et le cœur de réseau corrige ensuite la décision concernant l’AMF de service après avoir obtenu l’identité complète de l’abonné et les informations d’abonnement aux slices.
Lorsque l’UE entre pour la première fois sur le réseau, le gNB peut ne disposer que d’informations GUAMI limitées, d’informations Requested NSSAI ou de sa configuration AMF par défaut. Après l’authentification et la récupération de l’abonnement, le 5GC peut enfin déterminer quels slices l’abonné est autorisé à utiliser. Le NSSF convertit alors l’exigence de slice en Target AMF Set, tandis que le NRF aide à identifier l’instance AMF réelle capable de poursuivre le Registration.
La question la plus utile lors de l’analyse de ce flux de signalisation n’est donc pas « Pourquoi l’AMF a-t-il changé en cours d’enregistrement ? », mais plutôt : à quel moment le réseau a-t-il enfin obtenu suffisamment d’informations pour déterminer quel AMF devait continuer à desservir l’UE ?
Questions fréquentes
La réaffectation d’AMF est-elle identique à l’équilibrage de charge dans un AMF Pool ?
Non. L’équilibrage de charge dans un AMF Pool porte généralement sur la capacité, la pondération et la répartition haute disponibilité entre plusieurs instances AMF. Dans cette procédure, la réaffectation est déclenchée parce que l’Initial AMF ne peut pas desservir le slice réseau finalement requis par l’UE. Les deux mécanismes peuvent aboutir à un AMF de service différent, mais leurs conditions de déclenchement et leur logique de signalisation sont fondamentalement différentes.
Tout déploiement de Network Slicing exige-t-il une sélection NSSF et une réaffectation d’AMF ?
Non. Même lorsque le Network Slicing est déployé, la réaffectation d’AMF n’est pas nécessaire si l’AMF sélectionné initialement par le gNB peut déjà desservir le slice finalement requis par l’UE. La réaffectation est une branche conditionnelle de l’enregistrement, et non une étape obligatoire pour tout réseau utilisant le slicing.
L’UE peut-il détecter directement que l’AMF a changé pendant l’enregistrement ?
Du point de vue de l’UE, la question principale est de savoir si le Registration aboutit et quelles valeurs Allowed NSSAI, Configured NSSAI, Rejected NSSAI et 5G-GUTI sont renvoyées par le réseau. La réaffectation d’AMF et le transfert du Registration Context sont des procédures de contrôle internes au 5GC et restent largement transparents pour l’UE.
Le transfert indirect ou direct est-il toujours le plus courant ?
Aucune conclusion universelle ne peut être tirée de la seule définition de la procédure. Le mécanisme utilisé dépend de l’architecture de déploiement 5GC, de l’implémentation du fournisseur, des capacités de communication basée sur les services entre AMF et de la configuration du RAN et du cœur de réseau. Le dépannage réel doit suivre le chemin de signalisation observé sur le réseau en production.
