Dans un réseau 5G Core, un pool d’AMF est généralement associé à une meilleure disponibilité et au partage de charge, mais le simple déploiement de plusieurs instances d’AMF ne suffit pas. Lorsqu’un gNB se connecte à un pool d’AMF, il doit savoir davantage que quels AMF sont en ligne. Il doit aussi connaître les GUAMI desservis par chaque AMF, les PLMN et tranches réseau pris en charge, la capacité relative et la manière dont le trafic doit être redirigé lorsqu’un AMF est retiré du service pour maintenance.

L’interface N2 fournit le chemin de plan de contrôle nécessaire à cet échange d’informations. Elle fonctionne sur SCTP et utilise la signalisation NGAP pour échanger les capacités et synchroniser l’état entre le gNB et l’AMF. Lors de l’initialisation du réseau, l’association SCTP est d’abord établie, puis la procédure NG Setup est exécutée. En exploitation, les changements de capacité de l’AMF, d’informations GUAMI ou d’points de terminaison SCTP doivent être signalés au gNB via des procédures de mise à jour de configuration. Avant une maintenance planifiée, l’AMF peut aussi indiquer quels GUAMI vont devenir indisponibles et fournir des informations sur un AMF de secours.

L’interface N2 d’un pool d’AMF doit donc être considérée comme une relation de contrôle maintenue en permanence, et non comme une connexion configurée une fois puis laissée inchangée. Cette approche permet de comprendre beaucoup plus facilement les procédures d’établissement, de mise à jour et de resélection comme un processus de gestion complet.

Pourquoi un pool d’AMF exige plus qu’une simple connexion établie

Du point de vue de la connectivité de base, une fois qu’une association SCTP entre un gNB et un AMF est établie, les deux nœuds peuvent échanger des messages NGAP. Dans un pool d’AMF, toutefois, la connectivité seule ne suffit pas.

Une même zone de service peut contenir AMF1, AMF2, AMF3 et d’autres instances d’AMF. Le gNB doit savoir non seulement si ces AMF sont joignables, mais aussi quels GUAMI, PLMN et tranches réseau ils prennent en charge, ainsi que la part relative de charge que chaque AMF est actuellement apte à traiter. Sans ces informations, toutes les associations SCTP pourraient être à l’état UP tandis que le gNB manquerait encore des données nécessaires pour sélectionner un AMF approprié pour de nouveaux UE.

La gestion de l’interface N2 peut être divisée en trois étapes principales :

Ces trois procédures correspondent à trois étapes différentes du cycle de vie de la relation avec un AMF : découverte initiale, changement de capacité ou de configuration et retrait temporaire du service. Les examiner ensemble permet de mieux comprendre comment un pool d’AMF prend en charge le partage de charge et la maintenance planifiée entre plusieurs nœuds du cœur de réseau.

Que font respectivement SCTP et NG Setup lors de l’établissement de N2 ?

Dans les échanges entre ingénieurs, toute cette phase est souvent appelée simplement « établissement N2 ». Au niveau protocolaire, elle se compose toutefois de deux étapes successives : établir d’abord l’association SCTP, puis exécuter la procédure NGAP NG Setup.

Le gNB doit d’abord obtenir l’adresse de l’point de terminaison SCTP de l’interface N2 côté AMF. Cette adresse peut être configurée statiquement ou obtenue à l’aide d’un mécanisme approprié de résolution d’adresse. Le gNB établit ensuite une association SCTP avec l’AMF.

Une association SCTP classique est établie au moyen de quatre échanges : INIT, INIT ACK, COOKIE ECHO et COOKIE ACK. Une fois ces échanges terminés, la couche de transport est prête à véhiculer la signalisation NGAP. Le gNB ne dispose toutefois pas encore de toutes les informations de service de l’AMF dont il a besoin ; la procédure NG Setup est donc exécutée ensuite.

Le gNB envoie un NG Setup Request, qui peut contenir des informations telles que Global gNB ID, Supported TA List, RAN Node Name et Default Paging DRX. Concrètement, ce message indique à l’AMF quel nœud RAN se connecte, quelles zones de suivi il prend en charge et quels sont ses principaux paramètres de fonctionnement.

Après réception de la requête, l’AMF renvoie un NG Setup Response. La réponse fournit des informations essentielles côté AMF, notamment AMF Name, Served GUAMI List, les informations de PLMN pris en charge et RelativeAMFCapacity.

RelativeAMFCapacity est particulièrement important dans un pool d’AMF. Il ne doit pas être interprété simplement comme le nombre maximal d’abonnés qu’un AMF peut prendre en charge. Il fournit plutôt une référence de capacité relative que le gNB peut utiliser pour comparer plusieurs AMF et prendre des décisions de sélection d’AMF et de partage de charge pour les UE suivants.

Si le pool contient AMF1, AMF2 et AMF3, le gNB peut établir des associations N2 avec les AMF concernés en suivant le même processus et obtenir les informations de service et de capacité relative renvoyées par chaque nœud. C’est ce qui permet à plusieurs AMF de fonctionner comme un pool coordonné plutôt que comme des nœuds de plan de contrôle isolés.

Une capture de paquets montre également clairement cette séquence : le échange d’établissement SCTP apparaît en premier, suivi des messages NG Setup Request et NG Setup Response. Une fois l’association N2 de base prête, la signalisation d’enregistrement et de mobilité liée aux UE peut utiliser le chemin de plan de contrôle ainsi établi.

Pourquoi le gNB doit-il être mis à jour lorsque les capacités de l’AMF changent ?

L’état opérationnel d’un pool d’AMF n’est pas statique. Dans un 5G Core basé sur le cloud, un AMF peut être mis à l’échelle lorsque la demande des abonnés augmente, et ses informations GUAMI, sa zone de service, ses adresses d’point de terminaison ou sa capacité de traitement peuvent également changer.

Si le gNB continue d’utiliser les paramètres obtenus lors du démarrage initial, la logique de sélection d’AMF côté RAN peut ne plus refléter les capacités réelles du cœur de réseau. C’est là que la procédure AMF Configuration Update devient importante.

Cette procédure n’est pas liée à un UE particulier. Elle permet à l’AMF de notifier au NG-RAN les changements apportés à sa propre configuration. Par exemple, après une montée en capacité d’un AMF, sa capacité relative de traitement peut augmenter et une nouvelle valeur RelativeAMFCapacity peut être communiquée au gNB. Les changements d’informations GUAMI peuvent être synchronisés par la même procédure, tout comme les ajouts ou suppressions d’adresses d’point de terminaison SCTP.

Prenons le cas où un système d’orchestration ou de gestion détecte une forte augmentation du nombre d’utilisateurs pris en charge par AMF1 et étend automatiquement ses ressources de traitement. Après cette extension, AMF1 peut absorber une part relative plus importante de la charge du plan de contrôle ; sa valeur de capacité est donc ajustée en conséquence.

AMF1 envoie alors un AMF CONFIGURATION UPDATE au gNB. Le message peut contenir des informations GUAMI mises à jour, une nouvelle valeur RelativeAMFCapacity et des modifications d’points de terminaison SCTP. Après avoir appliqué la mise à jour, le gNB répond par un AMF CONFIGURATION UPDATE ACKNOWLEDGE.

À partir de ce moment, lorsque de nouveaux UE arrivent ou que le gNB doit effectuer une nouvelle sélection d’AMF, il peut utiliser les informations mises à jour plutôt que les valeurs apprises lors du démarrage initial du réseau.

Cela illustre un principe important du fonctionnement d’un pool d’AMF : le partage de charge n’est pas calculé une seule fois au démarrage du réseau. Il peut être ajusté à mesure que les ressources du cœur de réseau évoluent.

Ce point est particulièrement important dans un 5G Core cloud-native. Les ressources de calcul peuvent être mises à l’échelle dynamiquement, mais une augmentation de la capacité de calcul ne modifie pas automatiquement le comportement de sélection d’AMF côté RAN. Les paramètres mis à jour du plan de contrôle doivent également être communiqués au gNB. AMF Configuration Update fournit le mécanisme de signalisation qui relie les changements de ressources du cœur de réseau aux changements de comportement de sélection côté RAN.

Comment le gNB se prépare-t-il à la resélection d’AMF avant une maintenance ?

La mise à l’échelle ajoute de la capacité. La maintenance crée la situation inverse : un AMF peut devoir devenir temporairement indisponible en raison d’une mise à niveau logicielle, d’une maintenance planifiée ou d’une autre tâche d’exploitation.

Si un AMF passe simplement hors ligne sans en informer le NG-RAN, le gNB peut continuer à le sélectionner à partir des informations précédemment stockées jusqu’à ce que des échecs surviennent. Dans un pool d’AMF, une meilleure approche consiste à informer à l’avance le gNB que certaines identités AMF vont devenir indisponibles.

La procédure AMF Status Indication de NGAP est utilisée pour ce type de scénario de gestion d’AMF.

Supposons qu’AMF1 doive faire l’objet d’une mise à niveau logicielle. Avant le début de la maintenance, AMF1 peut envoyer un AMF STATUS INDICATION au gNB et identifier les GUAMI qui vont devenir indisponibles. Si le message contient également un Backup AMF Name, par exemple AMF2, le gNB peut en tenir compte lors des resélections ultérieures, à condition que la capacité correspondante soit prise en charge.

Lorsque le gNB reçoit l’indication d’état, il considère les GUAMI indiqués comme indisponibles et ajuste en conséquence les sélections et resélections d’AMF ultérieures.

Cela ne signifie pas que tous les contextes UE existants sont mécaniquement déplacés d’AMF1 vers AMF2 exactement au même instant. L’objectif est plutôt d’empêcher le NG-RAN de continuer à sélectionner un AMF en cours de retrait du service lorsqu’une sélection ou une resélection d’AMF sera ensuite nécessaire.

Par exemple, lorsqu’un UE lance ultérieurement une mise à jour d’enregistrement de mobilité, le gNB peut acheminer la signalisation correspondante vers un autre AMF. Le nouvel AMF peut alors continuer à assurer les fonctions de gestion de mobilité et, lorsque la procédure l’exige, attribuer un nouveau 5G-GUTI à l’UE.

Du point de vue des opérations, AMF Status Indication est essentiellement un mécanisme de retrait planifié du service. Il traduit un événement opérationnel tel que « AMF1 passe en maintenance » en informations d’état au niveau protocolaire que le NG-RAN peut comprendre et utiliser avant que l’AMF ne devienne réellement indisponible.

Que gère réellement le pool d’AMF au moyen de ces trois procédures ?

Lorsque NG Setup, AMF Configuration Update et AMF Status Indication sont étudiés séparément, ils peuvent facilement apparaître comme trois procédures NGAP sans rapport. En les observant sur l’ensemble du cycle de vie d’un pool d’AMF, leur relation devient beaucoup plus claire.

NG Setup établit la relation initiale. Lorsque le gNB se connecte pour la première fois à un AMF, il doit savoir avec quel AMF il communique, quels services celui-ci fournit et quelle est sa capacité relative de traitement au sein du pool.

AMF Configuration Update gère les changements de capacité et de configuration. L’AMF reste disponible, mais ses informations GUAMI, sa capacité relative ou ses points de terminaison de transport ont changé ; le NG-RAN doit donc actualiser les informations qu’il a stockées.

AMF Status Indication gère les changements de disponibilité. Lorsqu’un AMF se prépare à une maintenance ou à un retrait temporaire, le gNB doit considérer les GUAMI concernés comme indisponibles et se préparer à une resélection ultérieure d’AMF.

Ensemble, ces procédures permettent au gNB de maintenir une vue opérationnelle essentielle : quels AMF sont disponibles, quels services ils fournissent, quelle charge relative ils sont aptes à traiter et quels AMF sont en cours de retrait du service.

Un pool d’AMF n’atteint donc pas une haute disponibilité par le simple déploiement de plusieurs instances d’AMF. Le gNB doit maintenir en permanence une vue à jour des capacités et de l’état des AMF et utiliser ces informations lors des décisions de sélection. Ce n’est qu’ainsi qu’un déploiement multi-AMF peut réellement assurer le partage de charge, la mise à l’échelle élastique et la maintenance planifiée.

La même logique est utile pour le dépannage. Commencez par vérifier que l’association SCTP est saine, puis confirmez que NG Setup s’est terminé correctement. Si la connexion reste active mais que la répartition de charge est anormale, vérifiez la signalisation AMF Configuration Update et RelativeAMFCapacity. Si le trafic continue d’être dirigé vers un AMF en cours de retrait, examinez AMF Status Indication, les informations de disponibilité GUAMI et le comportement de resélection d’AMF.

Questions fréquentes

Comment distinguer rapidement les défaillances SCTP des défaillances NGAP dans une capture de paquets ?

Commencez par vérifier que l’association SCTP a été correctement établie. Si l’échange INIT, INIT ACK, COOKIE ECHO et COOKIE ACK ne se termine pas, le problème se situe encore au niveau de la couche de transport. Si SCTP est établi mais qu’aucun NG Setup Response n’est reçu, ou si une erreur de niveau NGAP est renvoyée, le dépannage doit se poursuivre sur les paramètres NGAP, la configuration TA, les informations PLMN et les paramètres côté AMF.

RelativeAMFCapacity représente-t-il le nombre maximal d’UE qu’un AMF peut prendre en charge ?

Non. RelativeAMFCapacity doit plutôt être compris comme un indicateur de capacité relative utilisé au sein d’un pool d’AMF. Il aide le NG-RAN à comparer la capacité relative de traitement des différents AMF à des fins de sélection. Il ne doit pas être interprété directement comme une limite absolue du nombre d’abonnés.

Pourquoi la modification de la configuration locale de l’AMF ne suffit-elle pas lorsque les informations GUAMI changent ?

Le gNB a déjà stocké des informations de service AMF obtenues via l’interface N2. Si l’AMF modifie sa configuration GUAMI sans en informer le NG-RAN, les deux côtés peuvent avoir des vues incohérentes de l’identité de l’AMF et de la disponibilité du service. Les informations mises à jour doivent donc être synchronisées au moyen de la procédure de gestion NGAP appropriée.

AMF Status Indication doit-il toujours contenir un Backup AMF Name ?

Non. Backup AMF Name est facultatif. Même lorsqu’il n’est pas inclus, le NG-RAN doit traiter les GUAMI identifiés comme indisponibles et appliquer le comportement approprié de gestion et de resélection d’AMF. Si Backup AMF Name est inclus et que le NG-RAN prend en charge la procédure correspondante, l’AMF de secours indiqué peut être pris en compte lors de la resélection.