In der Control Plane des 5G Core übernimmt die AMF zentrale Funktionen wie UE-Zugangsverwaltung, Mobilitätsverwaltung und NAS-Signalisierung. Die Zuverlässigkeit der AMF-Architektur wirkt sich daher direkt auf die gesamte Dienstkontinuität aus. In einer traditionellen Bereitstellung kann eine gNB statisch einer bestimmten AMF zugeordnet sein. Bei kleinen Netzen ist dieses Modell relativ einfach, doch mit steigenden Teilnehmerzahlen, dynamischeren Verkehrsmustern und zunehmender Cloud-Nutzung treten seine Grenzen immer deutlicher hervor. Eine AMF, die ein stark frequentiertes Geschäftsviertel versorgt, kann zu Spitzenzeiten dauerhaft hoch ausgelastet sein, während benachbarte Ressourcen unzureichend genutzt werden. Fällt eine einzelne AMF aufgrund eines Software- oder Hardwarefehlers aus, können Nutzer in ihrem Servicegebiet betroffen sein. Auch Routinearbeiten wie Software-Upgrades und Konfigurationsänderungen können sorgfältig geplante Wartungsfenster erfordern.
Der AMF Pool, der in der 3GPP-Architektur durch das Konzept des AMF Set dargestellt wird, adressiert diese Probleme durch ein gemeinsam genutztes Multi-AMF-Bereitstellungsmodell. Mehrere AMFs bilden eine logische Servicegruppe, während gNBs N2-Konnektivität zu den AMFs im Pool aufbauen können. In Verbindung mit der hierarchischen GUAMI-Identitätsstruktur, gewichteter AMF-Auswahl und UE-Kontextkontinuität unterstützt diese Architektur Lastverteilung, Ausfallsicherheit, reduzierte Signalisierung während der Mobilität und flexiblere Wartung. Die Bündelung von Control-Plane-Knoten ist kein ausschließliches 5G-Konzept. Ähnliche Ansätze gab es bereits beim SGSN Pool in GPRS und beim MME Pool in 4G. Alle folgen demselben Prinzip: starre Knotenbindungen werden durch gemeinsam genutzte Netzressourcen ersetzt. In 5G ergänzt AMF Pooling zudem Cloud-native-Bereitstellung und elastisches Ressourcenmanagement.
Warum AMF Pooling wichtig ist
Ein Hauptgrund für den Einsatz eines AMF Pool ist die Diskrepanz zwischen einer sich verändernden Teilnehmerverteilung und fester Knotenkapazität. Mobiler Verkehr ist naturgemäß dynamisch. Während der Arbeitszeit können sich viele Teilnehmer in Geschäftsvierteln sammeln, während sich der Verkehr am Abend in Wohngebiete verlagert. Konzerte, Sportveranstaltungen und Reiseverkehr an Feiertagen können ebenfalls kurzfristige Verkehrsspitzen verursachen. Wenn ein geografisches Gebiet nur von wenigen statisch zugewiesenen AMFs abhängt, können einzelne Knoten stark ausgelastet sein, während andere unzureichend genutzt werden.
Wenn mehrere AMFs im selben Pool arbeiten, können gNBs die Verbindung zu allen relevanten AMF-Instanzen aufrechterhalten und neu eintreffende UEs entsprechend den konfigurierten AMF-Gewichten verteilen. Versorgen beispielsweise drei AMFs mit identischer Verarbeitungskapazität dasselbe Gebiet, können gleiche Gewichtungen neue UE-Registrierungen und Mobilitätskontexte relativ gleichmäßig auf die Instanzen verteilen und so die gesamte Ressourcenauslastung verbessern.
Der zweite große Vorteil ist die Ausfallsicherheit. Kommt es bei einer AMF zu einem Software- oder Hardwarefehler, bleiben die übrigen AMFs im Pool verfügbar, um nachfolgende Zugangs- und Mobilitätsanfragen zu bearbeiten. Für die Control Plane des 5G Core reduziert dieses Mehrknotenmodell die Abhängigkeit von einer einzelnen AMF und schafft eine robustere Grundlage für Hochverfügbarkeitsbetrieb.
Pooling erhöht außerdem die betriebliche Flexibilität. Vor einem Software-Upgrade, einer Konfigurationsänderung oder einer Erweiterung einer AMF-Instanz können Betreiber zunächst die aktive Last dieses Knotens reduzieren oder migrieren und andere AMFs im Pool neuen oder umverteilten Verkehr übernehmen lassen. Sobald die AMF keine aktiven Nutzer mehr trägt, kann die Wartung mit geringeren Auswirkungen auf laufende Dienste und mit größerer Freiheit bei der Wahl des Wartungsfensters durchgeführt werden.
Mobilitätsoptimierung innerhalb des Pools
Der Nutzen eines AMF Pool geht über Mehrknotenredundanz hinaus. Ein wichtiger Vorteil ist die Verringerung der Signalisierung, wenn sich ein UE durch das Netz bewegt. Ein Pool kann mehrere Tracking Areas abdecken, während gNBs innerhalb dieses Servicebereichs N2-Konnektivität zu den AMFs desselben AMF Set aufrechterhalten.
Angenommen, ein UE registriert sich zunächst in TA1 und AMF1 erstellt den UE-Kontext. Bewegt sich das UE später innerhalb desselben Pools nach TA2, kann die neue gNB weiterhin AMF1 auswählen, um die NAS-Signalisierung dieses UE zu verarbeiten. Solange sich das UE im Servicegebiet desselben AMF Pool befindet, kann das Netz versuchen, die ursprüngliche AMF-Zuordnung beizubehalten.
Dieses Design reduziert unnötige Mobilitätssignalisierung. Ohne Pooling könnte ein Wechsel zwischen Servicegebieten einen Wechsel der Serving AMF erfordern und damit zusätzliche Kontextübertragungen und Registrierungsverfahren auslösen. Pooling entkoppelt Standortänderungen auf der Funkseite von zwingenden Änderungen des Control-Plane-Knotens und ermöglicht einem UE, sich zwischen gNBs und Tracking Areas zu bewegen, ohne automatisch seine Serving AMF zu wechseln.
Aus Engineering-Sicht erweitert der Pool effektiv den geografischen Bereich, in dem ein AMF-Kontext stabil bleiben kann. Ein UE kann sich über mehrere gNBs und TAs bewegen und denselben AMF-Anker behalten, sofern es im Servicegebiet des jeweiligen AMF Set bleibt. Dadurch werden Control-Plane-Interaktionen reduziert und die Kontinuität des Mobilitätsmanagements verbessert.
In der 3GPP-Architektur wird diese Logik durch eine hierarchische Struktur dargestellt. Ein AMF Set enthält mehrere AMFs, die ein definiertes Gebiet bedienen und denselben Network Slice oder dieselben Slices unterstützen. Innerhalb einer einzigen AMF Region können mehrere AMF Sets existieren, sodass größere Netze die Control Plane in handhabbare Servicebereiche aufteilen können.
Wie GUAMI eine AMF identifiziert
Wenn sich die Control Plane von einem Einzelknoten zu einer Pool-Architektur entwickelt, benötigt das Netz eine strukturierte Methode zur Identifikation von Regionen, Sets und einzelnen AMF-Instanzen. GUAMI, der Globally Unique AMF Identifier, liefert diese Hierarchie.
Ein GUAMI besteht aus MCC, MNC, AMF Region ID, AMF Set ID und AMF Pointer. Zusammen bilden diese Felder ein hierarchisches Adressierungsmodell über PLMN, AMF Region, AMF Set bis zur einzelnen AMF-Instanz. Die AMF Region ID identifiziert die übergeordnete AMF Region, die AMF Set ID ein bestimmtes AMF Set innerhalb dieser Region und der AMF Pointer eine einzelne AMF innerhalb des Sets.
Dieselbe Hierarchie erscheint auch in temporären UE-Identitäten. Ein 5G-GUTI besteht aus GUAMI und 5G-TMSI. Informationen in der temporären Identität eines UE können somit auf die AMF hinweisen, die das UE zuvor bedient hat. Der 5G-S-TMSI enthält AMF Set ID, AMF Pointer und 5G-TMSI und liefert Informationen, die unter anderem bei Paging-Verfahren verwendet werden.
Aus diesem Grund beeinflusst GUAMI die AMF-Auswahl direkt. Liefert ein UE beim RRC-Aufbau Informationen, die die zuvor zuständige Serving AMF identifizieren, muss die gNB nicht zwingend eine vollständig neue lastbasierte Auswahl durchführen. Stattdessen kann sie versuchen, die ursprüngliche AMF auszuwählen und die bestehende Servicebeziehung zu erhalten.
Neben binären Kennungen kann die AMF-Erkennung auch FQDN- und DNS-Mechanismen nutzen. Eine gNB kann einen AMF Set-FQDN erzeugen und über DNS Informationen zu den AMFs eines bestimmten Sets abfragen, die anschließend für den Aufbau einer N2-Assoziation genutzt werden. Ein AMF Instance-FQDN identifiziert eine einzelne AMF-Instanz und kann in geeigneten Mobilitäts- oder Interworking-Szenarien helfen, eine zuvor zuständige AMF zu finden.
Wie die gNB eine AMF auswählt
Sobald ein AMF Pool in Betrieb ist, muss die gNB zwei grundsätzlich unterschiedliche UE-Situationen behandeln. Die erste betrifft ein neu eintreffendes UE ohne verwertbare Informationen zu einer vorherigen Serving AMF. Die zweite betrifft ein UE, das Informationen zur Identifikation seiner vorherigen AMF mitführt. Für diese Fälle gelten unterschiedliche Auswahlprioritäten.
Wenn das UE beim RRC-Aufbau weder GUAMI noch andere Informationen zur Identifikation seiner vorherigen AMF liefert, wählt die gNB anhand der konfigurierten Gewichtswerte eine AMF aus dem AMF Set. Jeder AMF kann typischerweise entsprechend ihrer Verarbeitungskapazität ein Gewicht zwischen 0 und 255 zugewiesen werden. Eine leistungsfähigere AMF kann ein höheres Gewicht erhalten und mehr neue Nutzer aufnehmen, während eine Instanz mit geringerer Kapazität niedriger gewichtet werden kann.
Werden beispielsweise drei AMFs mit den Gewichten 100, 50 und 50 konfiguriert, kann die erste AMF bei ansonsten vergleichbaren Bedingungen ungefähr die Hälfte der neu zugewiesenen Nutzer erhalten. Diese Gewichte müssen nicht statisch bleiben. Wird eine AMF erweitert, verkleinert oder ändert sich ihre Kapazität anderweitig, können aktualisierte Gewichtsinformationen über ein N2-Konfigurationsupdate an verbundene gNBs übermittelt werden, sodass nachfolgende UE-Zuweisungen die neue Kapazitätsverteilung berücksichtigen.
Liefert das UE hingegen einen gültigen GUAMI, ändert sich das Auswahlziel. Anstatt das UE sofort zur Lastverteilung auf eine andere AMF zu verschieben, versucht die gNB die vorherige Serving AMF zu identifizieren und auszuwählen. Die Beibehaltung der ursprünglichen AMF trägt zur Kontextkontinuität bei und vermeidet unnötige Änderungen in der Control Plane.
Die AMF-Auswahl innerhalb eines Pools lässt sich daher durch zwei Prinzipien zusammenfassen: Wenn keine historische AMF-Zuordnung verfügbar ist, hat Lastverteilung Priorität; wenn eine vorherige AMF-Zuordnung bekannt ist, hat Servicekontinuität Priorität. Das erste verbessert die Ressourcennutzung, das zweite reduziert Mobilitätssignalisierung. Ein effizienter AMF Pool ist daher nicht darauf ausgelegt, jedes UE stets auf die momentan am wenigsten belastete AMF zu verschieben, sondern balanciert Ressourcenverteilung und Kontextstabilität.
Von der Erstbereitstellung zur elastischen Skalierung
Die Inbetriebnahme eines AMF Set umfasst mehrere Schritte. Zunächst werden mehrere AMF-Instanzen über ein MANO-Orchestrierungssystem oder eine Netzwerkmanagementplattform erstellt und die für N2-Konnektivität erforderlichen SCTP-Assoziationsadressen konfiguriert.
Anschließend baut die gNB SCTP-Assoziationen zu den AMFs im Pool auf und führt mit jeder relevanten AMF den N2-Setup-Vorgang durch. N2 Setup stellt nicht nur die Verbindung her. Es ermöglicht der gNB außerdem, Parameter zur AMF-Funktion und -Auswahl zu erhalten, darunter relative Kapazität oder Gewicht, unterstützte Slices und Servicegebietsinformationen. Sobald diese Beziehungen aufgebaut sind, kann das AMF Set UEs bedienen.
Wenn ein neues UE eintrifft, entscheidet die gNB, ob eine frühere AMF-Zuordnung beibehalten oder anhand verfügbarer Poolinformationen und konfigurierter Gewichte eine AMF ausgewählt werden soll. Haben alle AMFs ähnliche Verarbeitungskapazitäten und identische Gewichte, sollte sich ihre Teilnehmerlast im Laufe der Zeit relativ gleichmäßig verteilen.
Architektonisch sollte ein AMF Pool nicht als klassische Active-Standby-Lösung betrachtet werden. In einem Active-Standby-Design kann ein Ersatzknoten bis zum Auftreten eines Fehlers weitgehend inaktiv bleiben. In einem AMF Pool können mehrere AMFs gleichzeitig aktiv Nutzer bedienen. Ausfallsicherheit ist ein Ergebnis des Poolings, das übergeordnete Ziel besteht jedoch darin, mehrere AMF-Instanzen als eine logische Servicegruppe arbeiten zu lassen.
Diese Eigenschaft macht AMF Pooling zugleich zu einer wichtigen Grundlage für cloudbasierte 5GC-Bereitstellungen. In einer Cloud-native-Umgebung können AMF-Instanzen über Orchestrierung skaliert werden. Instanzanzahl, Verarbeitungskapazität und Auswahlgewichte können sich im Laufe der Zeit ändern, während das gNBs und UEs präsentierte logische AMF Set stabil bleibt. Pooling bietet somit eine konsistente Servicegrenze über dynamisch wechselnden Core-Netzressourcen und unterstützt das von einem cloudorientierten 5G Core erwartete elastische Verhalten.
Häufig gestellte Fragen
Kann eine AMF Region mehr als ein AMF Set enthalten?
Ja. Eine einzelne AMF Region kann mehrere AMF Sets enthalten. Unterschiedliche Sets können verschiedene Gebiete bedienen, während die AMFs innerhalb eines bestimmten Sets denselben Network Slice oder die für dieses Set erforderlichen Slices unterstützen.
Entspricht eine Tracking Area genau einer gNB?
Nein. Zwischen Tracking Area und gNB besteht keine Eins-zu-eins-Beziehung. Eine TA kann mehrere Zellen enthalten, während eine gNB mehrere Zellen enthalten kann, die zu einer oder mehreren Tracking Areas gehören.
Was ist der Unterschied zwischen AMF Pointer und AMF Set ID?
Die AMF Set ID identifiziert ein AMF Set, während der AMF Pointer eine bestimmte AMF-Instanz innerhalb dieses Sets unterscheidet. Zusammen mit der AMF Region ID bilden sie wichtige Bestandteile der im GUAMI enthaltenen hierarchischen Adressierungsinformationen.
Müssen nach einer Änderung des AMF-Gewichts alle N2-Verbindungen neu aufgebaut werden?
Nein. Ändert sich die AMF-Kapazität, können aktualisierte Gewichts- oder relative Kapazitätsinformationen über das entsprechende N2-Konfigurationsupdate an bereits verbundene gNBs übermittelt werden. Der neue Wert kann anschließend die Zuweisung neuer UEs beeinflussen, ohne dass bestehende N2-Konnektivität neu aufgebaut werden muss.
