La réallocation d’AMF permet au cœur 5G de réacheminer une Registration Request en cours lorsque l’AMF initiale ne convient pas pour desservir l’UE. Le cas lié aux tranches ci-dessous répond à une question pratique : pourquoi l’AMF peut-elle changer après que le gNB a déjà transmis la demande ? La réponse dépend des informations disponibles lors de la sélection, des données d’abonnement et des conditions de transfert de l’enregistrement.
Pourquoi la première sélection d’AMF peut être provisoire
Le gNB sélectionne une AMF initiale à partir des informations et de la configuration disponibles dans le réseau d’accès. Les informations RRC, telles qu’une identité temporaire et les tranches demandées, peuvent faciliter cette sélection ; le gNB ne récupère pas d’abord le profil UDM complet de l’abonné et n’interprète pas NAS comme l’AMF. Un NGAP Initial UE Message transporte la Registration Request NAS vers l’AMF sélectionnée.
Prenons l’exemple d’un véhicule connecté abonné à une tranche eMBB, S-NSSAI1, et à une tranche liée au V2X, S-NSSAI3, cette dernière étant indiquée par défaut. Ces libellés décrivent un exemple de configuration, pas des identifiants de tranche normalisés ni une garantie de conduite automatisée. Sans 5G-GUTI exploitable ou Requested NSSAI disponible, le gNB peut sélectionner AMF1 avec les informations dont il dispose. L’absence de Requested NSSAI ne nécessite pas, à elle seule, une réallocation.
Lors de l'inscription initiale 5GC, si l'UE ne dispose pas d'un 5G-GUTI et que la demande d'inscription n'indique pas de NSSAI demandé, le gNB ne peut alors sélectionner l'AMF initial qu'en se basant sur les informations disponibles et la configuration par défaut.
Les données d’abonnement et la sélection des tranches affinent la décision
L’AMF initiale traite l’identité, le contexte et la sécurité lorsque cela est nécessaire pour décider du réacheminement. Elle ne répète pas systématiquement une authentification complète avant de consulter le NSSF. Si les données d’abonnement nécessaires à la sélection des tranches n’ont pas été obtenues auprès d’une ancienne AMF, elle sélectionne un UDM et utilise Nudm_SDM_Get pour obtenir les S-NSSAI souscrits et leurs indications par défaut.
Dans l’exemple du véhicule, la réallocation devient pertinente si la sélection autorisée des tranches exige une capacité d’AMF que AMF1 ne peut pas fournir. Un S-NSSAI par défaut est une entrée de la sélection ; il n’impose pas à lui seul une relocalisation. Les tranches demandées, l’abonnement, la localisation, la configuration réseau et les capacités de l’AMF doivent être considérés ensemble.
Lorsqu’une sélection de tranches est nécessaire, Nnssf_NSSelection_Get peut fournir au NSSF Requested NSSAI, les S-NSSAI souscrits avec leurs indications par défaut, le TAI et d’autres informations applicables. La réponse peut comprendre Allowed NSSAI, un ensemble d’AMF cible ou une liste configurée d’AMF candidates, ainsi que des informations conditionnelles sur les tranches configurées ou rejetées. Un ensemble d’AMF cible définit un périmètre de candidats, pas nécessairement une instance finale.
La découverte NRF est conditionnelle : l’AMF initiale interroge Nnrf_NFDiscovery lorsqu’elle a besoin de l’adresse cible et ne la possède pas déjà localement. Les capacités des candidats et les règles de sélection aident à choisir une cible adaptée. L’absence d’échange NRF dans une trace n’est donc pas automatiquement une erreur.
Le réacheminement direct et celui via le RAN obéissent à des conditions différentes
Les deux chemins ne sont pas interchangeables dans toutes les situations. Selon TS 23.502, si une association de sécurité est déjà établie entre l’UE et l’AMF initiale, celle-ci doit utiliser le transfert direct. Le réacheminement via le RAN ne transfère pas ce contexte de sécurité et peut désynchroniser l’UE et l’AMF cible.
Transfert direct vers l’AMF cible
L’AMF initiale invoque Namf_Communication_N1MessageNotify pour transmettre la Registration Request complète et le contexte d’enregistrement applicable. Cela comprend les informations du réseau d’accès et, lorsqu’ils sont disponibles, le SUPI et le contexte MM ; les informations applicables obtenues du NSSF sont également transportées. L’AMF cible poursuit l’enregistrement et met à jour le RAN avec les nouvelles informations de terminaison N2. La politique locale et les données d’abonnement influencent aussi l’utilisation de ce chemin.
Transfert indirect via le gNB
Dans le cas autorisé issu de CM-IDLE, l’AMF initiale envoie NGAP Reroute NAS Request. Le gNB utilise les informations fournies, notamment AMF Set ID, pour réacheminer l’Initial UE Message vers une AMF cible. Il s’agit d’un réacheminement NAS côté réseau, pas d’une obligation pour l’UE de répéter l’accès radio. La branche indirecte n’est pas prise en charge lorsque l’enregistrement est arrivé en CM-CONNECTED via Uplink NAS Transport ; la contrainte de sécurité déjà établie s’applique également.
Poursuivre l’enregistrement et localiser le véritable point de défaillance
L’AMF cible effectue les traitements d’enregistrement restants nécessaires. Dans cette procédure, le contexte de sécurité reçu de l’AMF initiale prévaut sur celui récupéré auprès d’une ancienne AMF. Registration Accept peut fournir un nouveau 5G-GUTI et les informations de tranches applicables. L’UE reçoit le résultat de l’enregistrement sans avoir à gérer lui-même la sélection interne de l’AMF.
Vérifiez pourquoi la demande a atteint l’AMF initiale : informations RRC disponibles pour la sélection, configuration de l’AMF initiale et message NGAP entrant.
Vérifiez les tranches souscrites et demandées, le TAI, les capacités de desserte de l’AMF et tout résultat NSSF. Si la sélection est conditionnelle ou si les données sont en cache, ne supposez pas que chaque échange du schéma de référence doit apparaître.
Si aucune cible ne peut être sélectionnée, examinez l’ensemble d’AMF, les capacités des candidats, les résultats de découverte et la joignabilité de la cible. Si Reroute NAS Request est envoyé mais qu’aucun nouvel Initial UE Message n’arrive, examinez le réacheminement RAN et la connectivité N2.
Pour le transfert direct, corrélez Namf_Communication_N1MessageNotify, le contexte transféré et le premier message N2 de la cible. Vérifiez la continuité du contexte de sécurité avant de considérer le changement d’AMF comme un transfert réussi.
Questions fréquentes
Est-ce la même chose que l’équilibrage de charge d’un pool d’AMF ?
Non. Le cas décrit résout l’adéquation de l’AMF de desserte pendant l’enregistrement, notamment sa capacité à gérer les tranches. La capacité et la pondération peuvent influencer la sélection d’instance, mais deux AMF dans une trace ne prouvent à elles seules ni une incompatibilité de tranches ni un événement d’équilibrage de charge.
Tout réseau utilisant des tranches exige-t-il une réallocation ?
Non. Si l’AMF initiale peut desservir les tranches autorisées, l’enregistrement peut y rester. L’absence de Requested NSSAI ou l’utilisation d’une tranche par défaut ne suffisent pas à établir qu’une réallocation doit avoir lieu.
L’UE envoie-t-il une nouvelle Registration Request ?
Le réacheminement décrit transmet la demande existante à l’intérieur du réseau. L’UE reçoit ensuite la signalisation NAS d’enregistrement et peut recevoir une nouvelle identité temporaire ; il ne sélectionne pas lui-même l’AMF cible.
Quel chemin de transfert est le plus courant ?
La norme n’établit pas de fréquence de déploiement. Déterminez le chemin à partir des messages réels, de l’état de connexion et du contexte de sécurité, sans supposer qu’une méthode est universellement privilégiée.
Procédures et normes associées
Enregistrement initial général : identité, authentification et contexte d’accès
Mobility Registration Update après le déplacement d’un UE enregistré
3GPP TS 23.502, paragraphe 4.2.2.2.3 : enregistrement avec réallocation d’AMF
