In einem 5G-Core-Netz wird ein AMF-Pool häufig mit höherer Verfügbarkeit und Lastverteilung in Verbindung gebracht. Die bloße Bereitstellung mehrerer AMF-Instanzen reicht jedoch nicht aus. Wenn sich ein gNB mit einem AMF-Pool verbindet, muss es mehr wissen als nur, welche AMFs online sind. Es benötigt außerdem Informationen darüber, welche GUAMIs von den einzelnen AMFs bedient werden, welche PLMNs und Slices unterstützt werden, wie hoch die relative Kapazität ist und wie der Verkehr umgeleitet werden soll, wenn ein AMF wegen Wartungsarbeiten außer Betrieb genommen wird.
Die N2-Schnittstelle stellt den Kontrollpfad für diesen Informationsaustausch bereit. Sie läuft über SCTP und nutzt NGAP-Signalisierung, um Fähigkeiten auszutauschen und den Status zwischen gNB und AMF zu synchronisieren. Beim initialen Netzaufbau wird zuerst die SCTP-Assoziation hergestellt, anschließend folgt das NG Setup-Verfahren. Im laufenden Betrieb müssen Änderungen an AMF-Kapazität, GUAMI-Informationen oder SCTP-Endpunkten über Konfigurationsaktualisierungen an das gNB gemeldet werden. Vor einer geplanten Wartung kann der AMF außerdem angeben, welche GUAMIs nicht mehr verfügbar sein werden, und Informationen zu einem Backup-AMF bereitstellen.
Die N2-Schnittstelle in einem AMF-Pool sollte daher als kontinuierlich gepflegte Kontrollbeziehung verstanden werden und nicht als Verbindung, die einmal eingerichtet und anschließend unverändert belassen wird. Aus dieser Perspektive lassen sich Aufbau, Aktualisierung und Neuauswahl wesentlich leichter als ein zusammenhängender Verwaltungsprozess verstehen.
Warum ein AMF-Pool mehr als nur eine hergestellte Verbindung benötigt
Aus Sicht der grundlegenden Konnektivität können ein gNB und ein AMF nach dem Aufbau einer SCTP-Assoziation NGAP-Nachrichten austauschen. Für einen AMF-Pool reicht reine Erreichbarkeit jedoch nicht aus.
Ein einzelner Servicebereich kann AMF1, AMF2, AMF3 und weitere AMF-Instanzen umfassen. Das gNB muss nicht nur wissen, ob diese AMFs erreichbar sind, sondern auch, welche GUAMIs, PLMNs und Slices sie unterstützen und welchen relativen Lastanteil jeder AMF aktuell sinnvoll übernehmen kann. Ohne diese Informationen könnten alle SCTP-Assoziationen im Zustand UP sein, während dem gNB dennoch die Grundlage für die Auswahl eines geeigneten AMF für neue UEs fehlt.
Die Verwaltung der N2-Schnittstelle lässt sich in drei Hauptphasen unterteilen:
| Verfahren | Typischer Auslöser | Hauptzweck |
|---|---|---|
| N2-Aufbau | Erstaktivierung eines Standorts, Netzstart oder erste Assoziation mit einem AMF | SCTP-Assoziation herstellen und gNB- sowie AMF-Parameter über NG Setup austauschen |
| AMF Configuration Update | Änderungen an relativer Kapazität, GUAMI-Informationen oder SCTP-Endpunkten | Das gNB mit der aktuellen AMF-Konfiguration synchron halten und die spätere UE-Verteilung unterstützen |
| AMF Status Indication | Software-Upgrade, geplante Wartung oder ein anderer Zustand, durch den ein Teil eines AMF vorübergehend nicht verfügbar ist | Das gNB darüber informieren, dass bestimmte GUAMIs nicht verfügbar sind, und bei Bedarf die AMF-Neuauswahl unterstützen |
Diese drei Verfahren behandeln drei unterschiedliche Phasen im Lebenszyklus einer AMF-Beziehung: die anfängliche Erkennung, Änderungen an Fähigkeiten oder Konfiguration und die vorübergehende Außerbetriebnahme. Betrachtet man sie gemeinsam, wird klarer, wie ein AMF-Pool Lastverteilung und geplante Wartung über mehrere Kernnetzknoten hinweg unterstützt.
Welche Aufgaben haben SCTP und NG Setup jeweils beim Aufbau von N2?
In technischen Diskussionen wird diese gesamte Phase häufig einfach als „N2-Aufbau“ bezeichnet. Auf Protokollebene besteht sie jedoch aus zwei aufeinanderfolgenden Schritten: zuerst wird die SCTP-Assoziation hergestellt, anschließend wird das NGAP-Verfahren NG Setup ausgeführt.
Das gNB muss zunächst die Adresse des SCTP-Endpunkts der N2-Schnittstelle auf AMF-Seite ermitteln. Die Adresse kann statisch konfiguriert oder über einen geeigneten Mechanismus zur Adressauflösung bezogen werden. Danach baut das gNB eine SCTP-Assoziation mit dem AMF auf.
Ein typischer Aufbau einer SCTP-Assoziation besteht aus vier Austauschen: INIT, INIT ACK, COOKIE ECHO und COOKIE ACK. Sobald diese abgeschlossen sind, ist die Transportschicht bereit, NGAP-Signalisierung zu übertragen. Das gNB verfügt zu diesem Zeitpunkt jedoch noch nicht über alle benötigten AMF-Serviceinformationen, deshalb folgt anschließend das NG Setup-Verfahren.
Das gNB sendet einen NG Setup Request, der unter anderem Global gNB ID, Supported TA List, RAN Node Name und Default Paging DRX enthalten kann. Praktisch teilt diese Nachricht dem AMF mit, welcher RAN-Knoten eine Verbindung aufbaut, welche Tracking Areas er unterstützt und welche grundlegenden Betriebsparameter gelten.
Nach Eingang der Anfrage antwortet der AMF mit einem NG Setup Response. Die Antwort enthält wichtige Informationen auf AMF-Seite, darunter AMF Name, Served GUAMI List, unterstützte PLMN-Informationen und RelativeAMFCapacity.
RelativeAMFCapacity ist in einem AMF-Pool besonders wichtig. Der Wert darf nicht einfach als maximale Zahl von Teilnehmern verstanden werden, die ein AMF unterstützen kann. Vielmehr liefert er einen relativen Kapazitätswert, den das gNB beim Vergleich mehrerer AMFs sowie bei AMF-Auswahl und Lastverteilung für nachfolgende UEs verwenden kann.
Enthält der Pool AMF1, AMF2 und AMF3, kann das gNB nach demselben Verfahren N2-Assoziationen zu den relevanten AMFs aufbauen und die von jedem Knoten gelieferten Service- und relativen Kapazitätsinformationen erhalten. Dadurch können mehrere AMFs als koordinierter Pool statt als isolierte Kontrollknoten arbeiten.
Auch ein Paketmitschnitt zeigt diese Reihenfolge deutlich: Zuerst ist der SCTP-Verbindungsaufbau zu sehen, danach folgen NG Setup Request und NG Setup Response. Sobald die grundlegende N2-Assoziation bereitsteht, können UE-bezogene Registrierungs- und Mobilitätssignalisierungen den aufgebauten Kontrollpfad nutzen.
Warum muss das gNB aktualisiert werden, wenn sich AMF-Fähigkeiten ändern?
Der Betriebszustand eines AMF-Pools ist nicht statisch. In einem cloudbasierten 5G Core kann ein AMF bei steigender Teilnehmernachfrage skaliert werden. Ebenso können sich GUAMI-Informationen, Servicebereiche, Endpunktadressen oder Verarbeitungskapazität ändern.
Wenn das gNB weiterhin die beim initialen Start erhaltenen Parameter verwendet, bildet die AMF-Auswahllogik auf RAN-Seite die tatsächlichen Fähigkeiten des Kernnetzes möglicherweise nicht mehr ab. Genau hier ist das Verfahren AMF Configuration Update wichtig.
Dieses Verfahren bezieht sich nicht auf ein bestimmtes UE. Es erlaubt dem AMF vielmehr, dem NG-RAN Änderungen an seiner eigenen Konfiguration mitzuteilen. Wird ein AMF beispielsweise hochskaliert, kann seine relative Verarbeitungskapazität steigen und ein neuer RelativeAMFCapacity-Wert an das gNB gemeldet werden. Änderungen an GUAMI-Informationen lassen sich ebenso über dasselbe Verfahren synchronisieren wie das Hinzufügen oder Entfernen von SCTP-Endpunktadressen.
Angenommen, ein Orchestrierungs- oder Managementsystem erkennt einen deutlichen Anstieg der von AMF1 betreuten Nutzer und erweitert dessen Verarbeitungsressourcen automatisch. Nach der Erweiterung kann AMF1 einen größeren relativen Anteil der Kontrolllast übernehmen, sodass sein Kapazitätswert entsprechend angepasst wird.
AMF1 sendet anschließend ein AMF CONFIGURATION UPDATE an das gNB. Die Nachricht kann aktualisierte GUAMI-Informationen, einen neuen RelativeAMFCapacity-Wert und Änderungen an SCTP-Endpunkten enthalten. Nachdem das gNB die Aktualisierung übernommen hat, antwortet es mit einem AMF CONFIGURATION UPDATE ACKNOWLEDGE.
Von diesem Zeitpunkt an kann das gNB bei neu eintreffenden UEs oder einer erneuten AMF-Auswahl die aktualisierten Informationen verwenden, anstatt weiterhin auf die beim initialen Netzstart erlernten Werte zurückzugreifen.
Dies verdeutlicht ein wichtiges Prinzip im Betrieb eines AMF-Pools: Die Lastverteilung wird nicht nur einmal beim Netzstart berechnet. Sie kann angepasst werden, wenn sich die Ressourcen des Kernnetzes ändern.
Das ist besonders in einem cloudnativen 5G Core relevant. Rechenressourcen können dynamisch skaliert werden, doch eine höhere Rechenkapazität verändert nicht automatisch das AMF-Auswahlverhalten auf RAN-Seite. Auch die aktualisierten Parameter der Kontrollebene müssen an das gNB übermittelt werden. AMF Configuration Update stellt den Signalisierungsmechanismus bereit, der Änderungen an Kernnetzressourcen mit Änderungen des Auswahlverhaltens im RAN verknüpft.
Wie bereitet sich das gNB vor einer Wartung auf die AMF-Neuauswahl vor?
Skalierung erhöht die Kapazität. Wartung schafft die gegenteilige Situation: Ein AMF muss wegen eines Software-Upgrades, geplanter Wartung oder einer anderen Betriebsaufgabe möglicherweise vorübergehend nicht verfügbar sein.
Geht ein AMF ohne Benachrichtigung des NG-RAN einfach offline, kann das gNB ihn auf Grundlage zuvor gespeicherter Informationen weiter auswählen, bis Fehler auftreten. In einem AMF-Pool ist es sinnvoller, das gNB vorab darüber zu informieren, dass bestimmte AMF-Identitäten demnächst nicht mehr verfügbar sein werden.
Für diese Art von AMF-Verwaltungsszenario wird in NGAP das Verfahren AMF Status Indication verwendet.
Angenommen, AMF1 muss ein Software-Upgrade erhalten. Bevor die Wartung beginnt, kann AMF1 eine AMF STATUS INDICATION an das gNB senden und die GUAMIs kennzeichnen, die nicht mehr verfügbar sein werden. Enthält die Nachricht außerdem einen Backup AMF Name, beispielsweise AMF2, kann das gNB diesen AMF bei einer späteren Neuauswahl berücksichtigen, sofern die entsprechende Funktion unterstützt wird.
Sobald das gNB die Statusanzeige empfängt, behandelt es die angegebenen GUAMIs als nicht verfügbar und passt nachfolgende AMF-Auswahl- und Neuauswahlvorgänge entsprechend an.
Das bedeutet nicht, dass sämtliche bestehenden UE-Kontexte exakt zum selben Zeitpunkt mechanisch von AMF1 zu AMF2 verschoben werden. Vielmehr soll verhindert werden, dass das NG-RAN später bei einer erforderlichen AMF-Auswahl oder -Neuauswahl weiterhin einen AMF auswählt, der gerade aus dem Dienst genommen wird.
Wenn ein UE beispielsweise später eine Aktualisierung der Mobilitätsregistrierung startet, kann das gNB die zugehörige Signalisierung an einen anderen AMF weiterleiten. Der neue AMF kann dann die Mobilitätsverwaltungsfunktionen fortführen und dem UE, sofern das Verfahren dies erfordert, eine neue 5G-GUTI zuweisen.
Aus Betriebssicht ist AMF Status Indication im Wesentlichen ein Mechanismus für die geplante Außerbetriebnahme. Ein Betriebsereignis wie „AMF1 geht in Wartung“ wird dabei in Statusinformationen auf Protokollebene übersetzt, die das NG-RAN verstehen und nutzen kann, bevor der AMF tatsächlich nicht verfügbar ist.
Was verwaltet der AMF-Pool mit diesen drei Verfahren tatsächlich?
Werden NG Setup, AMF Configuration Update und AMF Status Indication getrennt betrachtet, wirken sie leicht wie drei voneinander unabhängige NGAP-Verfahren. Über den gesamten Lebenszyklus eines AMF-Pools betrachtet wird ihr Zusammenhang deutlich klarer.
NG Setup stellt die anfängliche Beziehung her. Wenn sich das gNB erstmals mit einem AMF verbindet, muss es wissen, mit welchem AMF es kommuniziert, welche Dienste dieser anbietet und wie hoch seine relative Verarbeitungskapazität innerhalb des Pools ist.
AMF Configuration Update behandelt Änderungen an Fähigkeiten und Konfiguration. Der AMF bleibt verfügbar, aber seine GUAMI-Informationen, relative Kapazität oder Transportendpunkte haben sich geändert, sodass das NG-RAN seine gespeicherten Informationen aktualisieren muss.
AMF Status Indication behandelt Änderungen der Verfügbarkeit. Bereitet sich ein AMF auf Wartung oder eine vorübergehende Außerbetriebnahme vor, muss das gNB die betreffenden GUAMIs als nicht verfügbar behandeln und eine spätere AMF-Neuauswahl vorbereiten.
Zusammen halten diese Verfahren für das gNB eine wichtige Betriebssicht aktuell: welche AMFs verfügbar sind, welche Dienste sie bereitstellen, welchen relativen Lastanteil sie sinnvoll verarbeiten können und welche AMFs gerade aus dem Dienst genommen werden.
Ein AMF-Pool erreicht daher nicht allein durch die Bereitstellung mehrerer AMF-Instanzen hohe Verfügbarkeit. Das gNB muss kontinuierlich ein aktuelles Bild der AMF-Fähigkeiten und -Zustände pflegen und diese Informationen bei Auswahlentscheidungen verwenden. Nur dann kann eine Multi-AMF-Bereitstellung Lastverteilung, elastische Skalierung und geplante Wartung wirksam unterstützen.
Dieselbe Logik hilft auch bei der Fehlersuche. Prüfen Sie zunächst, ob die SCTP-Assoziation stabil ist, und verifizieren Sie anschließend, dass NG Setup erfolgreich abgeschlossen wurde. Bleibt die Verbindung aktiv, ist die Lastverteilung aber auffällig, prüfen Sie die AMF Configuration Update-Signalisierung und RelativeAMFCapacity. Wird Verkehr weiterhin an einen AMF geleitet, der aus dem Dienst genommen wird, prüfen Sie AMF Status Indication, die GUAMI-Verfügbarkeitsinformationen und das Verhalten bei der AMF-Neuauswahl.
Häufige Fragen
Wie lassen sich SCTP- und NGAP-Fehler in einem Paketmitschnitt schnell unterscheiden?
Prüfen Sie zuerst, ob die SCTP-Assoziation erfolgreich hergestellt wurde. Wenn der Austausch aus INIT, INIT ACK, COOKIE ECHO und COOKIE ACK nicht abgeschlossen wird, liegt das Problem weiterhin auf der Transportschicht. Ist SCTP aufgebaut, wird aber kein NG Setup Response empfangen oder ein Fehler auf NGAP-Ebene zurückgegeben, sollte die Fehlersuche bei NGAP-Parametern, TA-Konfiguration, PLMN-Informationen und den Einstellungen auf AMF-Seite fortgesetzt werden.
Stellt RelativeAMFCapacity die maximale Anzahl von UEs dar, die ein AMF unterstützen kann?
Nein. RelativeAMFCapacity ist besser als relativer Kapazitätsindikator innerhalb eines AMF-Pools zu verstehen. Der Wert hilft dem NG-RAN, die relative Verarbeitungskapazität verschiedener AMFs für Auswahlentscheidungen zu vergleichen. Er sollte nicht direkt als absolute Teilnehmerobergrenze interpretiert werden.
Warum reicht es nicht aus, nur die lokale AMF-Konfiguration zu ändern, wenn sich GUAMI-Informationen ändern?
Das gNB hat bereits über die N2-Schnittstelle erhaltene AMF-Serviceinformationen gespeichert. Ändert der AMF seine GUAMI-Konfiguration, ohne das NG-RAN zu benachrichtigen, können beide Seiten unterschiedliche Sichtweisen auf AMF-Identität und Serviceverfügbarkeit haben. Die aktualisierten Informationen müssen daher über das entsprechende NGAP-Verwaltungsverfahren synchronisiert werden.
Muss AMF Status Indication immer einen Backup AMF Name enthalten?
Nein. Backup AMF Name ist optional. Auch wenn er nicht enthalten ist, muss das NG-RAN die als nicht verfügbar gekennzeichneten GUAMIs verarbeiten und das entsprechende AMF-Verwaltungs- und Neuauswahlverhalten ausführen. Ist ein Backup AMF Name enthalten und unterstützt das NG-RAN das entsprechende Verfahren, kann der angegebene Backup-AMF bei der Neuauswahl berücksichtigt werden.