Nachdem ein UE in einem 5G-Netz registriert wurde, muss das Kernnetz grob wissen, wo es sich befindet, damit es bei Paging, eingehenden Diensten oder Downlink-Daten erreichbar bleibt. Ein UE bleibt jedoch nicht an einem Ort. Es kann von einer Tracking Area in eine andere wechseln oder sogar den Versorgungsbereich seines aktuellen AMF verlassen. Müsste das UE nach jeder Bewegung eine neue Registrierung durchführen, würde die Signalisierung im Control Plane übermäßig zunehmen. Würde es seine Position dagegen nie aktualisieren, könnte das Netz schließlich den Bezug dazu verlieren, wo das UE erreichbar ist. Mobility Registration Update ist dafür ausgelegt, die Genauigkeit der Standortinformation mit dem Signalisierungsaufwand auszubalancieren.
Eine häufige Frage beim Einstieg in die 5GC-Signalisierung lautet: Wenn das UE bereits registriert ist, warum muss es nach dem Wechsel in einen neuen Bereich erneut einen Registration Request senden? Löst der Wechsel zu einem anderen gNB immer ein Update aus? Bedeutet der Eintritt in eine neue Tracking Area immer, dass sich der AMF ändern muss? All diese Fragen führen zum selben Grundsatz: Das UE bleibt im Zustand 5GS Registered, seine aktuelle Position kann jedoch außerhalb der zuvor vom Netz zugewiesenen Registration Area liegen. Der 5GC muss daher den Standort des UE aktualisieren, feststellen, ob derselbe Serving AMF zuständig bleiben soll, und die Registration Area für die nächste Mobilitätsphase festlegen. Dies ist keine erneute Einschaltregistrierung, und das UE registriert sich auch nicht bei jedem Zellwechsel neu. Es handelt sich um einen Mechanismus zur Aufrechterhaltung der Kontinuität des 5GS-Mobilitätskontexts des UE.
Das Verlassen der Registration Area ist der wichtigste Auslöser für das Mobility Update
Die Registrierung im 5GC beschränkt sich nicht auf Initial Registration. Der im Registration Request übertragene 5GS registration type unterscheidet Verfahren wie Initial Registration, Mobility Registration Update, Periodic Registration Update und Emergency Registration. In Mobilitätsszenarien ist die Unterscheidung zwischen Tracking Area (TA) und Registration Area eine der häufigsten Ursachen für Missverständnisse.
Eine TA ist ein grundlegender Bereich für das Location Management des Netzes, während eine Registration Area aus einer oder mehreren TAs besteht, innerhalb derer der AMF dem UE erlaubt, registriert zu bleiben. Eine Registration Area kann nur eine TA oder mehrere TAs enthalten. Angenommen, ein AMF versorgt TA1, TA2, TA3 und TA4, weist einem bestimmten UE aufgrund seines Mobilitätsverhaltens aber nur TA1 und TA2 als aktuelle Registration Area zu. Wechselt dieses UE von TA1 nach TA2, befindet es sich weiterhin innerhalb des registrierten Bereichs und muss nicht allein wegen des TA-Wechsels ein Mobility Registration Update durchführen.
Die Situation ändert sich, wenn das UE weiter nach TA3 wechselt und TA3 nicht zur aktuell gespeicherten Registration Area gehört. Das UE erkennt, dass der aktuelle TAI außerhalb seines registrierten Bereichs liegt, sendet einen neuen NAS Registration Request und setzt den 5GS registration type auf mobility registration updating. Ein Zellwechsel löst daher nicht automatisch ein Mobility Registration Update aus, und selbst ein TA-Wechsel führt nicht zwangsläufig dazu. Der typische Auslöser ist der Eintritt in eine TA außerhalb der aktuellen Registration Area des UE.
Genau darin liegt der Zweck der Registration Area. Sie ermöglicht es dem UE, sich innerhalb eines definierten Bereichs zu bewegen, ohne bei jedem Überschreiten einer TA-Grenze mit dem 5GC zu interagieren, und hilft so, Standortgenauigkeit und Signalisierungslast im Control Plane auszubalancieren. Das Netz kann einem UE mit größerem Mobilitätsradius eine umfangreichere TA-Liste zuweisen oder die Registration Area verkleinern, wenn eine präzisere Standortverfolgung gewünscht ist. Die Registration Area ist damit selbst Bestandteil der Mobility-Management-Policy.
Wie bringt der Registration Request den bestehenden Mobilitätszustand zurück in den 5GC?
Der deutlichste Unterschied zwischen Mobility Registration Update und Initial Registration besteht darin, dass das UE kein vollständig unbekannter Teilnehmer ist. Es hat die 5GS-Registrierung bereits abgeschlossen und behält normalerweise Informationen wie den vom Netz zugewiesenen 5G-GUTI, seine Registration Area und den relevanten NAS-Kontext. Der neue Registration Request dient daher nicht dazu, die Identität von Grund auf neu aufzubauen. Stattdessen teilt er dem Netz sinngemäß mit: „Ich bin dasselbe UE, das ihr bereits kennt, aber mein Mobilitätsstandort hat sich geändert.“
Zunächst stellt das UE über den neuen gNB den Zugriff auf die Steuerungsebene her. Der gNB transportiert anschließend den NAS Registration Request innerhalb einer NGAP Initial UE Message zum AMF. Neben der NAS-PDU enthält die Initial UE Message Zugriffsstandortinformationen wie den aktuellen NR-CGI und TAI. Bei einem typischen Mobility Registration Update kann der Registration Request mehrere wichtige Informationselemente enthalten: Der 5GS registration type kennzeichnet das Verfahren als mobility registration updating; der 5G-GUTI hilft dem Netz, den AMF oder GUAMI zu identifizieren, der mit der vorherigen Registrierung des UE verknüpft ist; Last Visited Registered TAI referenziert den zuvor registrierten Standort; UE Security Capability beschreibt die unterstützten NAS-Algorithmen für Verschlüsselung und Integritätsschutz; PDU Session Status zeigt, welche PDU-Sitzungen das UE noch als aktiv betrachtet; und Requested NSSAI kann bei Bedarf die vom UE angeforderten Netzwerkslices übermitteln.
Bei der Trace-Analyse sollte die erste Frage daher nicht lauten, ob später im Verfahren eine Authentisierung erfolgt. Zuerst ist zu prüfen, ob der Registration Request selbst eindeutig zeigt, dass es sich um ein Mobility Registration Update und nicht um eine Initial Registration handelt. Wird der Registration Type falsch interpretiert, kann der restliche Signalisierungsablauf leicht aus der falschen Perspektive analysiert werden.
Warum folgen Same-AMF- und Inter-AMF-Updates unterschiedlichen Pfaden?
Das Verlassen der Registration Area bedeutet nicht zwangsläufig, dass auch der Versorgungsbereich des aktuellen AMF verlassen wird. Diese Unterscheidung bestimmt unmittelbar die Komplexität des weiteren Signalisierungsverfahrens und gehört zu den ersten Verzweigungen, die bei der Analyse eines Mobility Registration Update erkannt werden sollten.
Der Serving AMF bleibt gleich
Angenommen, ein AMF versorgt sowohl TA1 als auch TA2, während das Netz dem UE zuvor nur TA1 als Registration Area zugewiesen hat. Wechselt das UE von TA1 nach TA2, liegt TA2 außerhalb seiner aktuellen Registration Area, sodass ein Mobility Registration Update erforderlich ist. TA2 befindet sich jedoch weiterhin im Versorgungsbereich desselben AMF.
In diesem Fall findet keine tatsächliche Migration vom Old AMF zum New AMF statt. Der aktuelle AMF besitzt bereits den Mobilitätskontext des UE und muss lediglich den neuen Standort verarbeiten, die Registration Area aktualisieren und erforderliche Policy- oder Kontextinformationen auffrischen. Die Registration Area ändert sich, der Serving AMF jedoch nicht.
Der Serving AMF wechselt
Komplexer wird das Verfahren, wenn sich das UE von einer TA im Versorgungsbereich eines AMF in eine TA bewegt, die von einem anderen AMF bedient wird. Beispielsweise kann das UE die Registrierung unter AMF1 abgeschlossen und einen mit AMF1 verknüpften 5G-GUTI erhalten haben. Nach dem Wechsel über einen neuen gNB in den Versorgungsbereich von AMF2 muss der New AMF wissen, um welches UE es sich handelt, welcher AMF es zuvor betreut hat und welcher Kontext wiederverwendet werden kann.
Ein Inter-AMF Mobility Registration Update ist daher mehr als nur eine Standortaktualisierung. Es umfasst auch die Übergabe des Mobility-Management-Kontexts des UE vom bisherigen Serving AMF an den neuen.
Wie findet der New AMF den Old AMF und ruft den UE-Kontext ab?
In einem Inter-AMF-Mobilitätsszenario besteht die erste Aufgabe des New AMF nach Empfang des Registration Request nicht darin zu klären, ob der Teilnehmer einen Datendienst aufbauen kann. Zunächst muss er erkennen, welcher AMF das UE zuvor verwaltet hat. Der 5G-GUTI spielt dabei eine wichtige Rolle. GUAMI-bezogene Informationen in der temporären Identität helfen dem Netz, den zuvor zuständigen AMF zu bestimmen. Anschließend kann der New AMF den Old AMF ermitteln und über den Dienst Namf_Communication den vorhandenen UE Context anfordern.
Die typische Logik ist einfach: Das UE sendet ein Mobility Registration Update mit seinem bisherigen 5G-GUTI; der New AMF extrahiert daraus die AMF-bezogene Identität; der Old AMF wird identifiziert; der New AMF fordert den UE Context an; und der Old AMF liefert den übertragbaren Mobilitätskontext zurück. Diese Informationen können dem New AMF helfen, Identitäts- und Mobilitätsdaten wie SUPI, GPSI, PEI und Teile des Access and Mobility Context wiederherzustellen. Dadurch kann der neue Serving AMF auf einem bestehenden UE-Zustand aufsetzen, anstatt das Gerät als vollständig unbekannt zu behandeln.
Der Erhalt des Kontexts vom Old AMF bedeutet nicht, dass alle nachfolgenden Sicherheitsverfahren grundsätzlich übersprungen werden können. Reichen die verfügbaren Identitätsinformationen oder der Sicherheitskontext nicht aus, kann das Netz den SUCI des UE erneut anfordern und abhängig von den aktuellen Sicherheitsbedingungen eine Identitätsprüfung oder 5G-AKA-Authentisierung durchführen. Bei der Trace-Analyse sollten daher zwei starre Annahmen vermieden werden: Ein Mobility Registration Update erfordert nicht immer eine vollständige neue Authentisierung, doch ein verfügbarer Old AMF Context garantiert auch nicht, dass niemals erneut authentisiert wird. Ob Identity Request oder ein vollständiges 5G-AKA erscheint, hängt vom übertragenen UE Context, dem NAS Security Context und der Netzrichtlinie ab.
Wie schließen UDM, NRF und PCF die Übernahme durch den Serving AMF ab?
Der Abruf des UE Context vom Old AMF bedeutet nicht, dass die Servicebeziehung bereits vollständig übertragen wurde. Im 5GC sind Teilnehmerstandort und Servicezustand auf mehrere Network Functions verteilt. Insbesondere muss das UDM wissen, welcher AMF nun für das UE zuständig ist.
Der New AMF kann über das NRF ein UDM ermitteln, das die benötigten Dienste bereitstellt, und anschließend die neue 3GPP Access Registration im UDM registrieren. Dieser Schritt ist in einem Inter-AMF-Szenario besonders wichtig, weil der Serving-AMF-Eintrag im UDM vom Old AMF auf den New AMF wechseln muss. Das UDM kann anschließend die entsprechende Deregistration Notification an den Old AMF auslösen, damit die bisherige Servicebeziehung freigegeben wird.
Der New AMF benötigt außerdem die aktuellen Access and Mobility Subscription Data, die unter anderem GPSI, Subscribed NSSAI, UE-AMBR, Parameter für periodische Registrierung, RAT-Beschränkungen und Gebietszugriffsbeschränkungen enthalten können. Erfordert die spätere PDU-Session-Verarbeitung eine SMF-Auswahl, kann der AMF zusätzlich SMF Selection Subscription Data abrufen, einschließlich DNN- und Default-DNN-Informationen zum relevanten S-NSSAI, und Änderungen dieser Teilnehmerdaten abonnieren. Der PCF ergänzt diesen Prozess durch Bereitstellung der Access and Mobility Policy. Der New AMF kann den geeigneten PCF auswählen und eine AM Policy Association aufbauen, um Mobilitätsrichtlinien wie Gebietsbeschränkungen zu erhalten.
Diese Schritte lösen unterschiedliche Aufgaben. Der Old AMF Context zeigt dem New AMF, welchen Zustand das UE zuvor hatte. Die UDM Registration teilt dem Kernnetz mit, welcher AMF das UE nun betreut. Subscription Data zeigen dem New AMF, welche Dienste der Teilnehmer nutzen darf. Die PCF Policy gibt dem AMF vor, welche Mobilitäts- und Zugriffsregeln aktuell gelten. Ein Mobility Registration Update darf deshalb nicht auf „der AMF aktualisiert einen TAI“ reduziert werden. In einem Inter-AMF-Szenario wird zugleich die Verantwortung für das Mobility Management von einem AMF auf einen anderen übertragen.
Wie definiert Registration Accept den nächsten Mobilitätsbereich des UE?
Nachdem Identität, Kontext, Teilnehmerdaten und Richtlinien verarbeitet wurden, muss der AMF den neuen Registrierungszustand sowohl auf den gNB als auch auf das UE anwenden. In einem typischen Verfahren kann der AMF mit einem NGAP Initial Context Setup Request den UE-bezogenen Kontext im gNB aufbauen oder aktualisieren und gleichzeitig den NAS Registration Accept an das UE zustellen.
Der wichtigste Aspekt des Registration Accept ist nicht nur, dass die Registrierung erfolgreich war. Die Nachricht liefert auch Parameter, die festlegen, wie sich das UE in der nächsten Mobilitätsphase verhalten soll. Nach einem Inter-AMF-Wechsel kann ein neuer 5G-GUTI zugewiesen werden, der den neuen Serving AMF widerspiegelt. Allowed NSSAI kennzeichnet die aktuell für das UE zulässigen Network Slices. T3512 definiert das Timing für eine künftige Periodic Registration Update. Die TA List beziehungsweise Registration Area zeigt dem UE, durch welche TAs es sich bewegen kann, während es registriert bleibt, ohne erneut ein Mobility Registration Update desselben Typs auszulösen.
Nachdem der gNB die entsprechende Kontextverarbeitung abgeschlossen hat, sendet er eine Initial Context Setup Response zurück, und das UE übermittelt Registration Complete. Damit ist das aktuelle Mobility Registration Update beendet. Aus Sicht der Zustandsübergänge lässt sich der Ablauf so zusammenfassen: Das UE verlässt seine bestehende Registration Area; der Registration Request bringt die vorherige Mobilitätsidentität in den 5GC; das Netz entscheidet, ob sich der Serving AMF ändern muss; bei Bedarf wird der UE Context vom Old AMF übertragen; der New AMF schließt die UDM-Registrierung ab und erhält die erforderlichen Teilnehmer- und Policy-Informationen; Registration Accept liefert den neuen 5G-GUTI und die neue Registration Area; schließlich sendet das UE Registration Complete zurück.
Auch die Fehlersuche kann derselben Zustandskette folgen. Erreicht der Registration Request den New AMF, der Old AMF kann jedoch nicht gefunden werden, sollten 5G-GUTI, GUAMI und AMF-Adressierung geprüft werden. Wird der Old AMF Context erfolgreich abgerufen, das Verfahren stoppt aber in der UDM-Phase, sollten als Nächstes UDM-Discovery, AMF Registration und der Abruf der Teilnehmerdaten geprüft werden. Ist die interne Kernnetzverarbeitung abgeschlossen, aber kein Registration Accept erreicht das UE, sollte die Analyse mit Policy-Ergebnissen, Gebietsbeschränkungen, NGAP-Downlink-Signalisierung und RAN-Kontextaufbau fortgesetzt werden. Beim Verständnis des 5GC Mobility Registration Update geht es daher nicht darum, Dutzende HTTP/2- und NGAP-Nachrichten auswendig zu lernen, sondern zu verstehen, wie das Netz nach der Bewegung eines registrierten UE drei Fragen beantwortet: Wo befindet sich das UE jetzt, welcher AMF soll es weiter verwalten und welche Registration Area soll für die nächste Mobilitätsphase gelten?
Häufig gestellte Fragen
Führt das UE jedes Mal ein Mobility Registration Update durch, wenn es eine neue Tracking Area betritt?
Nicht unbedingt. Entscheidend ist, ob die neue TA weiterhin Teil der aktuellen Registration Area des UE ist. Hat der AMF TA1 und TA2 bereits als Registration Area des UE zugewiesen, löst ein Wechsel von TA1 nach TA2 normalerweise nicht allein wegen des TA-Wechsels dieses Update aus. Der Eintritt in eine TA außerhalb der Registration Area ist der typische Auslöser.
Ändert ein Mobility Registration Update immer den AMF?
Nein. Das UE kann seine aktuelle Registration Area verlassen, während die neue TA weiterhin zum Versorgungsbereich desselben AMF gehört. In diesem Fall bleibt der Serving AMF unverändert. Eine Kontextübertragung vom Old AMF zum New AMF ist nur erforderlich, wenn sich das UE in einen Bereich bewegt, der von einem anderen AMF bedient werden muss.
Wird bei jedem Mobility Registration Update 5G-AKA wiederholt?
Es sollte keine feste Regel angenommen werden. Ob Identitätsverfahren oder 5G-AKA wiederholt werden, hängt vom verfügbaren UE Context, dem NAS Security Context und der Netzrichtlinie ab. Kann ein gültiger Kontext weiterverwendet werden, müssen bestimmte Sicherheitsverfahren möglicherweise nicht vollständig wiederholt werden. Sind Identitäts- oder Sicherheitsbedingungen unzureichend, kann das Netz die erforderlichen Authentisierungsschritte erneut durchführen.
Wie unterscheidet sich ein 5GC Mobility Registration Update von einem Update beim Wechsel eines UE von 4G zu 5G?
Beide Szenarien können den Registration Type Mobility Registration Update verwenden, die Quelle des Mobilitätskontexts ist jedoch unterschiedlich. Mobilität vollständig innerhalb des 5GS umfasst typischerweise Mobilitätskontext zwischen einem Old AMF und einem New AMF. Ein Idle-Mode-Interworking-Szenario von 4G zu 5G kann zusätzlich MME, N26 und die Übersetzung zwischen EPS- und 5GS-Kontext betreffen. Bei der Analyse eines Signalisierungstraces sollte zuerst festgestellt werden, ob sich das UE innerhalb des 5GS bewegt oder vom EPC in den 5GC eintritt.
