Wann wird eine AMF-Neuzuweisung ausgelöst?

Initial Registration mit AMF-Neuzuweisung ist nicht der Standardpfad für jede 5GC-Registrierung. Die Auslösebedingungen sind klar: Network Slicing ist implementiert, und der AMF, der die Registration Request zunächst empfängt, kann den Network Slice nicht bedienen, den das UE letztlich benötigt.

In einem normalen Registrierungsszenario unterstützt der vom gNB ausgewählte Initial AMF den erforderlichen S-NSSAI bereits. Identitätsverarbeitung, Authentifizierung, Abruf der Teilnehmerdaten und Registration Accept können daher während des gesamten Verfahrens auf demselben AMF verbleiben.

Eine Neuzuweisung wird erst notwendig, wenn später gewonnene Informationen zeigen, dass der aktuelle AMF nicht zu dem Slice passt, den das UE verwenden darf oder standardmäßig verwenden soll. Die Logik lässt sich wie folgt zusammenfassen:

Registration Request erreicht den Initial AMF
           → Initial AMF führt die erforderliche Registrierungsverarbeitung durch
           → Vollständige Teilnehmer- und Slice-Informationen des UE werden ermittelt
           → Initial AMF stellt fest, dass er den Ziel-S-NSSAI nicht bedienen kann
           → NSSF wird aufgerufen, um den geeigneten Servicebereich zu bestimmen
           → Registrierung wird an den Target AMF übertragen

Ein häufiges Missverständnis sollte vermieden werden: Zwei AMFs in derselben Registrierungsspur bedeuten nicht automatisch, dass der ursprüngliche AMF ausgefallen ist oder dass Lastverteilung innerhalb eines AMF Pools stattgefunden hat. Der tatsächliche Auslöser ist in diesem Verfahren eine Abweichung zwischen der Slice-Servicefähigkeit des aktuellen AMF und dem Network Slice, den das UE letztlich benötigt.

Warum kann der gNB zunächst einen ungeeigneten AMF auswählen?

Beim ersten Blick auf die AMF-Neuzuweisung liegt die Annahme nahe, dass der gNB einen Fehler gemacht hat. Wenn verschiedene AMFs unterschiedliche Slices bedienen, warum sendet das RAN das UE nicht von Anfang an direkt zum richtigen AMF?

Der Hauptgrund ist, dass dem gNB bei der ersten AMF-Auswahl möglicherweise noch nicht genügend Informationen vorliegen. Nehmen wir ein vernetztes Fahrzeug, das erstmals mit einer 5G-USIM startet, die für zwei Network Slices freigeschaltet ist:

• eMBB-Slice (S-NSSAI1): für Infotainment im Fahrzeug und allgemeine Datendienste;

• V2X-Slice (S-NSSAI3): für Vehicle-to-Everything-Kommunikation und Dienste im Zusammenhang mit automatisiertem Fahren.

Angenommen, der Default S-NSSAI des Teilnehmers ist der V2X-Slice, das UE betritt das 5GS jedoch zum ersten Mal, besitzt keinen gültigen 5G-GUTI und übermittelt in der Registration Request kein Requested NSSAI. Zu diesem Zeitpunkt hat der gNB keine direkte Grundlage, um zu wissen, dass das UE letztlich vom AMF des V2X-Slices bedient werden soll.

Unter normalen Bedingungen kann der gNB bei der AMF-Auswahl Informationen wie GUAMI, den vom UE angeforderten S-NSSAI und seine lokale AMF-Konfiguration nutzen. In diesem Szenario stehen jedoch weder GUAMI noch Requested NSSAI zur Verfügung. Der gNB kann daher nur anhand der aktuell vorhandenen Informationen und seiner lokalen Standardauswahlrichtlinie einen Initial AMF wählen.

Wählt der gNB zunächst AMF1, der den eMBB-Slice bedient, wird die Registration Request in einer NGAP Initial UE Message an AMF1 weitergeleitet.

Dass dieser AMF nicht zum endgültigen Slice-Bedarf des UE passt, weist nicht zwangsläufig auf einen Konfigurationsfehler des gNB hin. Präziser ist folgende Interpretation: Zum Zeitpunkt der ersten AMF-Auswahl verfügt das RAN noch nicht über genügend Informationen, um den endgültigen slice-spezifischen AMF des UE zu bestimmen.

Wie erkennt der Initial AMF die Slice-Abweichung?

Wenn die Registration Request den Initial AMF erreicht, fragt dieser den NSSF nicht sofort ab. Zu diesem Zeitpunkt fehlen ihm noch genügend Teilnehmerinformationen, um festzustellen, ob er der richtige endgültige Serving AMF ist.

Der AMF folgt zunächst der normalen Initial-Registration-Logik und führt die erforderlichen Verfahren aus, darunter UE-Identitätsverarbeitung, AUSF-Auswahl, 5G-AKA-Authentifizierung und die zugehörigen NAS-Sicherheitsverfahren.

Ein wesentliches Ergebnis dieser Phase besteht darin, dass der AMF die UE-Identität bestätigt und den SUPI erhält. Mit verfügbarem SUPI kann der Initial AMF den passenden UDM ermitteln und die Access and Mobility Subscription Data des UE abrufen.

Zu diesem Zeitpunkt verfügt das Netz über deutlich mehr Informationen als beim ersten Eintreffen der Registration Request. Die vom UDM zurückgegebenen Teilnehmerdaten können den Subscribed NSSAI und den Default S-NSSAI des Teilnehmers enthalten.

Im Beispiel des vernetzten Fahrzeugs gehört der Initial AMF zum eMBB-Servicebereich. Die Teilnehmerdaten zeigen jedoch, dass das UE sowohl eMBB als auch V2X abonniert hat und der Default S-NSSAI auf V2X beziehungsweise S-NSSAI3 verweist.

Der Initial AMF kann nun eine Schlussfolgerung ziehen, zu der der gNB zuvor nicht in der Lage war: Obwohl er die Initial Registration empfangen und mit der Verarbeitung beginnen konnte, ist er nicht der geeignete AMF für den dauerhaften Dienst des standardmäßigen V2X-Slices des UE. Diese Feststellung wird zum Auslösepunkt der AMF-Neuzuweisung.

gNB-Phase: nur begrenzte Zugangsinformationen verfügbar
           → Initial-AMF-Phase: UE-Identität wird bestätigt
           → UDM-Phase: tatsächliche Subscribed-NSSAI-Informationen werden abgerufen
           → Aktueller AMF wird als inkompatibel mit dem Ziel-Slice erkannt

Die AMF-Neuzuweisung ist somit keine willkürliche Entscheidungsänderung mitten in der Registrierung. Sie erfolgt, weil das Core Network eine präzisere Serving-AMF-Entscheidung treffen kann, sobald Teilnehmeridentität und Slice-Informationen vollständig vorliegen.

Wie identifiziert der NSSF den neuen Serving AMF?

Sobald der Initial AMF feststellt, dass er den Ziel-Slice nicht bedienen kann, wählt er nicht einfach selbst einen anderen AMF aus. Stattdessen ruft er die Network Slice Selection Function, kurz NSSF, auf.

Der Initial AMF verwendet den Dienst Nnssf_NSSelection, um eine Network Slice Selection anzufordern. Zu den Eingaben können der abonnierte S-NSSAI des UE, Informationen über den aktuellen AMF und der aktuelle TAI des UE gehören. Ziel ist es festzustellen, welche Slices im aktuellen Registrierungsbereich autorisiert sind und welches AMF-Set den Dienst bereitstellen soll.

Die vom NSSF zurückgegebenen Authorized Network Slice Information können Folgendes enthalten:

• Allowed NSSAI: die Network Slices, die das UE unter den aktuellen Bedingungen verwenden darf;

• Configured NSSAI: Slice-Konfiguration, die dem UE bei Bedarf bereitgestellt werden kann;

• Target AMF Set: die Gruppe von AMFs, die den betreffenden Network Slice bedienen können;

• Rejected NSSAI: Slices, die im aktuellen TA oder unter den betreffenden Bedingungen nicht akzeptiert werden können.

Es ist wichtig, zwischen Target AMF Set und Target AMF zu unterscheiden. Die erste Aufgabe des NSSF besteht darin, festzulegen, welches AMF-Set geeignet ist. Er grenzt also anhand von Slice- und Standortbedingungen den Kandidatenbereich ein, anstatt direkt die Adresse eines einzelnen AMF zurückzugeben.

Nach Erhalt des Target AMF Set kann der Initial AMF die im NRF registrierten NF-Instanzinformationen verwenden, um Adressen, Fähigkeiten, Gewichtungen und Betriebszustände der AMFs innerhalb dieses Sets abzurufen. Anschließend kann er bestimmen, welcher konkrete Target AMF die Registration übernehmen soll.

Die Beziehung lässt sich wie folgt zusammenfassen:

UDM: liefert die Slice-Abonnementinformationen des UE
           → Initial AMF: stellt fest, dass die eigene Servicefähigkeit nicht passt
           → NSSF: bestimmt autorisierte Slices und Target AMF Set
           → NRF: liefert Informationen zu verfügbaren AMF-Instanzen innerhalb des Sets
           → Initial AMF: wählt den Target AMF

Die Rolle des NSSF in diesem Verfahren ist keine klassische Lastverteilung. Er bildet eine Slice-Anforderung auf einen AMF-Servicebereich ab, der diese Anforderung unterstützen kann.

Wie wird die Registration Request an den Target AMF übertragen?

Nachdem der Target AMF bestimmt wurde, muss das UE keine vollständig neue Registration Request senden. Das Netz muss lediglich das bereits laufende Registrierungsverfahren zusammen mit dem erforderlichen Kontext übertragen, damit der neue AMF die Verarbeitung fortsetzen kann.

Zwei Weiterleitungsmechanismen stehen zur Verfügung: indirekte Weiterleitung über den gNB oder direkte Weiterleitung zwischen Initial AMF und Target AMF.

Indirekte Weiterleitung über den gNB

Bei der indirekten Weiterleitung sendet der Initial AMF einen NGAP Reroute NAS Request an den gNB. Die Nachricht enthält Informationen zur ursprünglichen Initial UE Message sowie die Target AMF Set ID und weist das NG-RAN an, die aktuelle NAS Registration Message neu zu routen.

Der gNB sendet anschließend eine neue Initial UE Message an den Target AMF, die das NAS-PDU der ursprünglichen Registration Request enthält. Der Steuerungspfad lässt sich folgendermaßen darstellen:

UE → gNB → Initial AMF → Reroute NAS Request → gNB → Target AMF

Das UE muss keinen erneuten RRC-Zugriff durchführen. Das NG-RAN routet lediglich die bestehende Registration NAS Message zum geeigneten AMF um.

Direkte Weiterleitung zwischen AMFs

Bei der direkten Weiterleitung sendet der Initial AMF die Nachricht nicht über den gNB zurück. Stattdessen überträgt er die N1-Nachricht und den Registration Context direkt über die servicebasierte 5GC-Schnittstelle an den Target AMF.

Der Initial AMF ruft Namf_Communication_N1MessageNotify auf und sendet die vollständige Registration Request zusammen mit dem Registration Context Container an den Target AMF.

Die übertragenen Informationen beschränken sich nicht auf eine einzelne NAS-Nachricht. Der Registration Context kann außerdem UE Context, Access Type, gNB-Informationen, User Location, Allowed NSSAI, Configured NSSAI, Rejected NSSAI und weitere Informationen enthalten, die zur Fortsetzung der Registrierungsverarbeitung benötigt werden.

UE → gNB → Initial AMF → Namf_Communication_N1MessageNotify → Target AMF

Die Signalisierungspfade unterscheiden sich, das Ziel bleibt jedoch gleich: Der Target AMF erhält die NAS-Nachricht und den Kontext, die zur Fortsetzung der Registration erforderlich sind, ohne das gesamte Initial-Registration-Verfahren neu zu starten.

Nach der Übernahme schließt der Target AMF die verbleibende Registrierungsverarbeitung ab und sendet einen Registration Accept an das UE zurück. Die Antwort spiegelt die Ergebnisse der Slice-Auswahl und AMF-Neuzuweisung wider und kann Allowed NSSAI, Configured NSSAI, Rejected NSSAI sowie einen neu zugewiesenen 5G-GUTI enthalten.

Aus Sicht des UE ist entscheidend, dass die Registrierung erfolgreich abgeschlossen wird und das Netz die im aktuellen Gebiet verfügbaren Slices sowie den neuen 5GS-Mobilitätskontext bereitstellt. Der interne Wechsel des Serving AMF bleibt für das UE transparent.

Wie lässt sich eine AMF-Neuzuweisung in einem Signalisierungstrace verifizieren?

Initial Registration mit AMF-Neuzuweisung kann leicht mit ungewöhnlichem Registrierungsrouting oder einer fehlgeschlagenen ersten AMF-Auswahl verwechselt werden. Eine effektivere Fehlersuche vergleicht nicht Nachrichtennummern Schritt für Schritt, sondern folgt zwei Hauptlinien: der Slice-Ermittlung und der Kontextübertragung.

Eine normale Signalisierungsfolge sollte es dem Techniker ermöglichen, die folgenden Fragen zu beantworten:

Warum erreichte die Registration Request zuerst diesen Initial AMF?
           → Woher erhielt der Initial AMF den Subscribed / Default NSSAI des UE?
           → Was führte dazu, dass der AMF feststellte, das UE nicht weiter bedienen zu können?
           → Welches Target AMF Set gab der NSSF zurück?
           → Welcher konkrete Target AMF wurde schließlich ausgewählt?
           → Welcher Pfad wurde zur Übertragung des Registration Context verwendet?

Wenn der Initial AMF die Slice-Abonnementinformationen bereits erhalten und festgestellt hat, dass er das UE nicht bedienen kann, aber kein NSSF-Auswahlverfahren folgt, sollte sich die Untersuchung auf die NSSF-Erkennung, den Nnssf_NSSelection Request und die zugehörige Slice-Konfiguration konzentrieren.

Wenn der NSSF ein Target AMF Set zurückgibt, aber kein konkreter Target AMF ermittelt werden kann, sollten als Nächstes die AMF-Set-Konfiguration, NF Profiles im NRF, der Status der AMF-Instanzen und deren Fähigkeitsinformationen geprüft werden.

Wenn ein NGAP Reroute NAS Request vorhanden ist, der Target AMF die neue Initial UE Message jedoch nie empfängt, sollte sich die Fehlersuche von der Slice-Auswahl auf das NAS-Rerouting im gNB und die N2-Erreichbarkeit zum Target AMF verlagern.

Bei direkter Weiterleitung sollte der Trace auf Namf_Communication_N1MessageNotify und den Registration Context geprüft werden, anstatt auf einen Reroute NAS Request zu warten, der auf diesem Pfad nicht erscheint.

Über den gesamten Ablauf betrachtet löst die AMF-Neuzuweisung ein konkretes Problem: Bei der ersten AMF-Auswahl sind die verfügbaren Informationen unvollständig, und das Core Network korrigiert die Serving-AMF-Entscheidung später, nachdem vollständige Teilnehmeridentitäts- und Slice-Abonnementinformationen vorliegen.

Wenn das UE erstmals in das Netz eintritt, verfügt der gNB möglicherweise nur über begrenzte GUAMI-Informationen, Requested-NSSAI-Informationen oder seine Standard-AMF-Konfiguration. Nach Authentifizierung und Abruf der Teilnehmerdaten kann das 5GC schließlich bestimmen, welche Slices der Teilnehmer verwenden darf. Der NSSF überführt anschließend die Slice-Anforderung in ein Target AMF Set, während der NRF dabei hilft, die tatsächliche AMF-Instanz zu ermitteln, die die Registration fortsetzen kann.

Die wichtigste Frage bei der Analyse dieses Signalisierungsablaufs lautet daher nicht „Warum wechselte der AMF mitten in der Registrierung?“, sondern: Zu welchem Zeitpunkt hatte das Netz schließlich genügend Informationen, um festzustellen, welcher AMF das UE weiterhin bedienen sollte?

Häufig gestellte Fragen

Ist eine AMF-Neuzuweisung dasselbe wie Lastverteilung in einem AMF Pool?

Nein. Lastverteilung in einem AMF Pool konzentriert sich üblicherweise auf Kapazität, Gewichtung und hochverfügbare Verteilung zwischen mehreren AMF-Instanzen. Bei diesem Verfahren wird die AMF-Neuzuweisung dadurch ausgelöst, dass der Initial AMF den letztlich vom UE benötigten Network Slice nicht bedienen kann. Beide Mechanismen können zu einem anderen Serving AMF führen, die Auslösebedingungen und die Signalisierungslogik unterscheiden sich jedoch grundlegend.

Erfordert jeder Network-Slicing-Einsatz NSSF-Auswahl und AMF-Neuzuweisung?

Nein. Auch bei implementiertem Network Slicing ist eine AMF-Neuzuweisung nicht erforderlich, wenn der vom gNB zuerst ausgewählte AMF den letztlich benötigten Slice bereits bedienen kann. Die Neuzuweisung ist ein bedingter Zweig des Registrierungsverfahrens und kein obligatorischer Schritt für jedes geslicte Netz.

Kann das UE direkt erkennen, dass sich der AMF während der Registrierung geändert hat?

Aus Sicht des UE ist hauptsächlich relevant, ob die Registration erfolgreich ist und welche Werte für Allowed NSSAI, Configured NSSAI, Rejected NSSAI und 5G-GUTI das Netz zurückgibt. AMF-Neuzuweisung und Übertragung des Registration Context sind interne 5GC-Steuerungsverfahren und für das UE weitgehend transparent.

Ist indirekte oder direkte Weiterleitung grundsätzlich häufiger?

Aus der Verfahrensdefinition allein lässt sich keine allgemeingültige Aussage ableiten. Der verwendete Mechanismus hängt von der 5GC-Deployment-Architektur, der Implementierung des Herstellers, den servicebasierten Kommunikationsmöglichkeiten zwischen AMFs sowie der RAN- und Core-Network-Konfiguration ab. Die praktische Fehlersuche sollte dem Signalisierungspfad folgen, der im produktiven Netz tatsächlich beobachtet wird.