Dans le plan de contrôle du cœur 5G, l’AMF assure des fonctions essentielles telles que la gestion de l’accès UE, la gestion de mobilité et la signalisation NAS. La fiabilité de l’architecture AMF a donc un impact direct sur la continuité globale du service. Dans un déploiement traditionnel, un gNB peut être associé statiquement à une AMF particulière. Cette approche reste relativement simple lorsque le réseau est réduit, mais ses limites deviennent de plus en plus visibles avec l’augmentation du nombre d’abonnés, la dynamique croissante des profils de trafic et la généralisation des déploiements cloud. Une AMF desservant un quartier d’affaires très fréquenté peut rester fortement chargée aux heures de pointe tandis que des ressources voisines sont sous-utilisées. Si une seule AMF subit une panne logicielle ou matérielle, les utilisateurs de sa zone de service peuvent être affectés. Les opérations courantes telles que les mises à niveau logicielles et les modifications de configuration peuvent également exiger des fenêtres de maintenance soigneusement planifiées.

AMF Pool, représenté dans l’architecture 3GPP par le concept d’AMF Set, répond à ces problèmes grâce à un modèle de déploiement partagé à plusieurs AMF. Plusieurs AMF forment un même groupe logique de service, tandis que les gNB peuvent établir une connectivité N2 avec les AMF du pool. Associée à la structure hiérarchique d’identité GUAMI, à la sélection pondérée des AMF et à la continuité du contexte UE, cette architecture permet la répartition de charge, la résilience aux pannes, la réduction de la signalisation en mobilité et une maintenance plus flexible. Le regroupement de nœuds du plan de contrôle n’est pas propre à la 5G. Des concepts similaires existaient déjà dans le SGSN Pool du GPRS et le MME Pool de la 4G, selon le même principe : remplacer une liaison rigide à un nœud par des ressources réseau partagées. En 5G, l’AMF Pooling complète en outre les déploiements cloud-native et la gestion élastique des ressources.

Pourquoi l’AMF Pooling est important

L’une des principales raisons de déployer un AMF Pool est de corriger le décalage entre une distribution d’abonnés variable et une capacité de nœud fixe. Le trafic mobile est intrinsèquement dynamique. Pendant les heures de travail, de nombreux abonnés peuvent se concentrer dans les quartiers commerciaux, puis le trafic se déplace vers les zones résidentielles le soir. Les concerts, événements sportifs et départs en vacances peuvent également provoquer des pointes temporaires soudaines. Si une zone géographique dépend uniquement d’un petit nombre d’AMF attribuées statiquement, certains nœuds peuvent devenir très chargés tandis que d’autres restent sous-utilisés.

Lorsque plusieurs AMF fonctionnent dans le même pool, les gNB peuvent maintenir une connectivité avec toutes les instances AMF concernées et les nouveaux UE peuvent être répartis en fonction des poids AMF configurés. Par exemple, si trois AMF de capacité de traitement identique desservent la même zone, des poids équivalents peuvent répartir relativement uniformément les nouvelles inscriptions UE et les contextes de mobilité, améliorant ainsi l’utilisation globale des ressources.

Le deuxième avantage majeur est la résilience. Si une AMF rencontre une défaillance logicielle ou matérielle, les autres AMF du pool restent disponibles pour traiter les demandes d’accès et de mobilité suivantes. Pour le plan de contrôle du cœur 5G, ce modèle multinœud évite une dépendance excessive à une seule AMF et fournit une base plus solide pour une exploitation à haute disponibilité.

Le pooling améliore également la flexibilité opérationnelle. Avant de mettre à niveau un logiciel, modifier une configuration ou étendre une instance AMF, les opérateurs peuvent d’abord réduire ou migrer la charge active associée au nœud concerné et permettre aux autres AMF du pool de reprendre le trafic nouveau ou redistribué. Une fois que l’AMF ne porte plus d’utilisateurs actifs, la maintenance peut être réalisée avec moins d’impact sur les services en production et avec davantage de liberté pour choisir la fenêtre d’intervention.

Optimisation de la mobilité dans le pool

La valeur d’un AMF Pool va au-delà de la redondance multinœud. L’un de ses avantages importants est de réduire la signalisation lorsqu’un UE se déplace dans le réseau. Un pool peut couvrir plusieurs Tracking Areas, tandis que les gNB de ce domaine de service maintiennent une connectivité N2 avec les AMF appartenant au même AMF Set.

Supposons qu’un UE s’enregistre initialement dans TA1 et qu’AMF1 crée son contexte UE. Si l’UE se déplace ensuite vers TA2 au sein du même pool, le nouveau gNB peut continuer à sélectionner AMF1 pour traiter la signalisation NAS de cet UE. Tant que l’UE reste dans la zone de service du même AMF Pool, le réseau peut chercher à conserver l’association AMF initiale.

Cette conception réduit la signalisation de mobilité inutile. Sans pooling, un déplacement entre zones de service pourrait imposer un changement d’AMF servante, entraînant des transferts de contexte et des procédures liées à l’enregistrement supplémentaires. Le pooling dissocie les changements de position côté radio des changements obligatoires de nœud du plan de contrôle, de sorte qu’un UE peut se déplacer entre gNB et Tracking Areas sans changer automatiquement d’AMF servante.

D’un point de vue d’ingénierie, le pool agrandit effectivement la zone géographique dans laquelle un contexte AMF peut rester stable. Un UE peut traverser plusieurs gNB et TA tout en conservant le même ancrage AMF, à condition de rester dans la zone de service de l’AMF Set concerné. Cela réduit les interactions du plan de contrôle et améliore la continuité de la gestion de mobilité.

Dans l’architecture 3GPP, cette logique est représentée par une structure hiérarchique. Un AMF Set contient plusieurs AMF qui desservent une zone définie et prennent en charge le même Network Slice ou les mêmes slices. Plusieurs AMF Sets peuvent exister au sein d’une même AMF Region, ce qui permet aux grands réseaux de diviser le plan de contrôle en domaines de service plus faciles à gérer.

Comment GUAMI identifie une AMF

Lorsque le plan de contrôle passe d’un nœud unique à une architecture mutualisée, le réseau a besoin d’un moyen structuré d’identifier les régions, les sets et les instances AMF individuelles. GUAMI, Globally Unique AMF Identifier, fournit cette hiérarchie.

Un GUAMI se compose du MCC, du MNC, de l’AMF Region ID, de l’AMF Set ID et de l’AMF Pointer. Ensemble, ces champs forment un modèle d’adressage hiérarchique couvrant le PLMN, l’AMF Region, l’AMF Set et l’instance AMF individuelle. L’AMF Region ID identifie la région AMF étendue, l’AMF Set ID identifie un AMF Set spécifique dans cette région, et l’AMF Pointer distingue une AMF individuelle dans le set.

La même hiérarchie apparaît aussi dans les identités temporaires UE. Un 5G-GUTI se compose du GUAMI et du 5G-TMSI. Les informations associées à l’identité temporaire de l’UE peuvent donc indiquer l’AMF qui desservait précédemment cet UE. Le 5G-S-TMSI contient l’AMF Set ID, l’AMF Pointer et le 5G-TMSI, fournissant des informations utilisées dans des procédures telles que le paging.

C’est pourquoi GUAMI influence directement la sélection de l’AMF. Si un UE fournit pendant l’établissement RRC des informations identifiant l’AMF servante précédente, le gNB n’a pas forcément besoin d’effectuer une nouvelle sélection entièrement fondée sur la charge. Il peut tenter de sélectionner l’AMF d’origine et de préserver la relation de service existante.

Outre les identifiants binaires, la découverte d’AMF peut également utiliser les mécanismes FQDN et DNS. Un gNB peut construire un AMF Set-FQDN et interroger DNS afin d’obtenir des informations sur les AMF appartenant à un set donné, ce qui fournit des éléments pour l’établissement ultérieur de l’association N2. Un AMF Instance-FQDN identifie une instance AMF individuelle et peut aider à localiser une AMF servante précédente dans les scénarios de mobilité ou d’interfonctionnement applicables.

Comment le gNB sélectionne une AMF

Une fois l’AMF Pool opérationnel, le gNB doit gérer deux situations UE fondamentalement différentes. La première concerne un nouvel UE ne disposant d’aucune information exploitable sur une AMF servante précédente. La seconde concerne un UE qui transporte des informations permettant d’identifier son AMF précédente. Ces cas nécessitent des priorités de sélection différentes.

Si l’UE ne fournit pas de GUAMI ni d’autre information permettant d’identifier son AMF précédente pendant l’établissement RRC, le gNB sélectionne une AMF dans l’AMF Set à l’aide des poids configurés. Chaque AMF peut recevoir un poids compris entre 0 et 255, généralement selon sa capacité de traitement. Une AMF de capacité supérieure peut recevoir un poids plus élevé et accepter davantage de nouveaux utilisateurs, tandis qu’une instance de capacité inférieure peut se voir attribuer un poids plus faible.

Par exemple, si trois AMF sont configurées avec des poids de 100, 50 et 50, la première AMF peut recevoir environ la moitié des nouveaux utilisateurs attribués lorsque les autres conditions sont comparables. Ces poids n’ont pas besoin de rester statiques. Si une AMF est étendue, réduite ou change autrement de capacité, les nouvelles informations de poids peuvent être envoyées aux gNB connectés via une procédure de mise à jour de configuration N2, afin que les allocations UE suivantes reflètent la nouvelle distribution de capacité.

Si l’UE fournit un GUAMI valide, l’objectif de sélection change cependant. Au lieu de rééquilibrer immédiatement l’UE vers une autre AMF, le gNB tente d’identifier et de sélectionner l’AMF servante précédente. Le maintien de l’AMF d’origine contribue à préserver la continuité du contexte et à éviter des changements inutiles du plan de contrôle.

La sélection d’AMF dans un pool peut donc être résumée par deux principes : lorsqu’aucune association AMF historique n’est disponible, privilégier la répartition de charge ; lorsqu’une association AMF précédente est connue, privilégier la continuité du service. Le premier améliore l’utilisation des ressources, tandis que le second réduit la signalisation de mobilité. Un AMF Pool efficace n’est donc pas conçu pour déplacer chaque UE vers l’AMF actuellement la moins chargée, mais pour équilibrer la distribution des ressources avec la stabilité du contexte.

Du déploiement initial à la mise à l’échelle élastique

La mise en service d’un AMF Set comprend plusieurs étapes. Tout d’abord, plusieurs instances AMF sont créées via un système d’orchestration MANO ou une plateforme de gestion de réseau, puis les adresses d’association SCTP nécessaires à la connectivité N2 sont configurées.

Le gNB établit ensuite des associations SCTP avec les AMF du pool et exécute la procédure N2 Setup avec chaque AMF concernée. N2 Setup ne sert pas uniquement à établir la connectivité. Il permet également au gNB d’obtenir des paramètres liés au fonctionnement et à la sélection des AMF, notamment la capacité relative ou le poids, les slices pris en charge et les informations de zone de service. Une fois ces relations établies, l’AMF Set est prêt à servir les UE.

Lorsqu’un nouvel UE arrive, le gNB détermine s’il doit conserver une association AMF antérieure ou sélectionner une AMF selon les informations disponibles sur le pool et les poids configurés. Si toutes les AMF ont des capacités de traitement similaires et des poids identiques, leurs charges d’abonnés devraient tendre vers une répartition relativement équilibrée au fil du temps.

D’un point de vue architectural, un AMF Pool ne doit pas être considéré comme une solution active-standby classique. Dans une architecture active-standby, un nœud de secours peut rester largement inactif jusqu’à ce qu’une panne survienne. Dans un AMF Pool, plusieurs AMF peuvent servir activement des utilisateurs en même temps. La résilience est l’un des résultats du pooling, mais l’objectif plus large consiste à faire fonctionner plusieurs instances AMF comme un seul groupe logique de service.

Cette caractéristique fait également de l’AMF Pooling une base importante pour les déploiements 5GC basés sur le cloud. Dans un environnement cloud-native, les instances AMF peuvent être mises à l’échelle via orchestration. Le nombre d’instances, la capacité de traitement et les poids de sélection peuvent évoluer dans le temps, tandis que l’AMF Set logique présenté aux gNB et aux UE reste stable. Le pooling fournit ainsi une frontière de service cohérente au-dessus de ressources de cœur de réseau qui évoluent dynamiquement et prend en charge le comportement élastique attendu d’un cœur 5G orienté cloud.

Questions fréquentes

Une AMF Region peut-elle contenir plusieurs AMF Sets ?

Oui. Une seule AMF Region peut contenir plusieurs AMF Sets. Des sets différents peuvent desservir des zones différentes, tandis que les AMF d’un même set prennent en charge le même Network Slice ou les slices requis par ce set.

Un Tracking Area correspond-il à un seul gNB ?

Non. Il n’existe pas de relation un-à-un entre un Tracking Area et un gNB. Un TA peut contenir plusieurs cellules, tandis qu’un gNB peut contenir plusieurs cellules appartenant à un ou plusieurs Tracking Areas.

Quelle est la différence entre AMF Pointer et AMF Set ID ?

AMF Set ID identifie un AMF Set, tandis qu’AMF Pointer distingue une instance AMF particulière au sein de ce set. Avec AMF Region ID, ils constituent des éléments importants des informations d’adressage hiérarchique contenues dans le GUAMI.

La modification du poids d’une AMF impose-t-elle de rétablir toutes les connexions N2 ?

Non. Lorsque la capacité d’une AMF change, les nouvelles informations de poids ou de capacité relative peuvent être communiquées aux gNB déjà connectés via la procédure correspondante de mise à jour de configuration N2. La valeur révisée peut alors influencer l’allocation des nouveaux UE sans nécessiter la reconstruction de la connectivité N2 existante.