Zu welchem Teilnehmer gehört dieses UE?

Darf es auf das aktuelle Netz zugreifen?

Gibt es einen früheren Mobilitätskontext, der noch wiederverwendet werden kann?

Welche Netzslices und Zugriffsmöglichkeiten sind für das UE abonniert, und welches AMF soll es bedienen?

Wenn ein 5G-Gerät eingeschaltet wird, muss das Kernnetz diese grundlegenden Fragen beantworten, bevor Nutzerdatendienste aufgebaut werden können. Dies geschieht während der 5G-Erstregistrierung. Aus Sicht einer Signalisierungsaufzeichnung ist der Ablauf wesentlich mehr als ein einfaches „Registrierungsanfrage, gefolgt von erfolgreicher Registrierung“. Zwischen dem Senden des Registration Request durch das UE und dem abschließenden Registration Complete kann das Netz Identitätsverarbeitung, Abruf eines alten AMF-Kontexts, 5G-AKA-Authentifizierung, Aufbau der NAS-Sicherheit, UDM-Registrierung, Abruf von Teilnehmerdaten und Verarbeitung von Zugriffsrichtlinien durchführen.

Ein häufiger Fehler beim Studium dieses Ablaufs besteht darin, jede Nachricht in ihrer Reihenfolge auswendig lernen zu wollen. Praktischer ist die Frage, welches Problem das AMF in der jeweiligen Phase löst. Der vollständige Signalisierungsweg lässt sich so verstehen: das anfragende UE identifizieren, eine vertrauenswürdige Identität herstellen, den erforderlichen Teilnehmerkontext vervollständigen und erst danach die Registrierung abschließen.

Die Erstregistrierung stellt das Zugriffsrecht des UE auf das Netz her

Die Registrierung im 5GS ist kein einzelnes Verfahren. Abhängig vom Auslöser kann das UE Initial Registration, Mobility Registration Update, Periodic Registration Update oder Emergency Registration durchführen. Das UE kennzeichnet das jeweilige Verfahren über das Feld 5GS registration type im Registration Request.

Initial Registration findet typischerweise statt, wenn ein UE eingeschaltet wird und in das 5GS eintritt. Zum Lernen wird der Vorgang häufig mit dem LTE/EPC-Attach-Verfahren verglichen, beide sollten jedoch nicht als identisch betrachtet werden. In der servicebasierten Architektur des 5G Core sind Mobilitätsmanagement, Authentifizierung, Teilnehmerdaten und Richtliniensteuerung auf Netzfunktionen wie AMF, AUSF, UDM und PCF verteilt. Ein einzelnes Registrierungsverfahren kann daher mehrere servicebasierte Interaktionen zwischen Netzfunktionen umfassen.

Noch wichtiger ist: Initial Registration stellt in erster Linie den Zustand für Zugriffs- und Mobilitätsmanagement her und nicht eine Nutzerdatensitzung. Das Netz muss das UE identifizieren, einen Mobilitätskontext aufbauen, die zulässige NSSAI und geltende Gebietsrestriktionen bestimmen sowie die Sicherheitsbeziehung für die nachfolgende Signalisierung herstellen. Erst wenn diese Voraussetzungen erfüllt sind, verfügt das UE über die Grundlage, eine PDU Session anzufordern.

Der Empfang eines Registration Accept bedeutet daher nicht automatisch, dass der Teilnehmer bereits auf das Internet zugreifen kann. Registrierung und Aufbau einer PDU Session sind im 5G Core getrennte Phasen.

Der Registration Request bringt das UE in den Registrierungsablauf des 5G Core

Das Registrierungsverfahren im Kernnetz beginnt mit dem NAS Registration Request. Das UE sendet die NAS-Nachricht zunächst über die Funkschnittstelle an den gNB. Anschließend transportiert der gNB die NAS-PDU innerhalb einer NGAP Initial UE Message zum AMF. Für einen Kernnetz-Ingenieur ist diese Nachricht der Einstiegspunkt in den gesamten Registrierungsablauf.

Neben dem Registration Request liefert die Initial UE Message dem AMF auch Informationen zum Zugriffsort, beispielsweise NR-CGI und TAI. Die NAS-Nachricht selbst kann Parameter wie 5GS registration type, 5GS mobile identity, UE Security Capability und Requested NSSAI enthalten.

Diese Parameter sind mehr als eine einfache Liste der UE-Fähigkeiten. Das AMF nutzt sie, um den weiteren Registrierungsablauf zu bestimmen. Registration Type zeigt, ob das UE eine Initial Registration oder eine andere Registrierungsaktualisierung durchführt. Die mobile identity bestimmt, ob vorhandener Teilnehmerkontext dem UE zugeordnet werden kann. Requested NSSAI beschreibt die vom UE angeforderten Netzslices, während UE Security Capability als Grundlage für die spätere Auswahl der NAS-Sicherheitsalgorithmen dient.

Ein Detail wird leicht missverstanden: Ein UE, das Initial Registration durchführt, besitzt nicht zwangsläufig keinerlei frühere 5G-Informationen. Wenn das UE noch eine zuvor zugewiesene 5G-GUTI gespeichert hat, kann es diese Identität in einem neuen Initial Registration Request mitsenden. Ob das Netz die damit verknüpften Informationen wiederverwenden kann, beeinflusst die nächsten Schritte unmittelbar.

Das neue AMF klärt Identität und früheren UE-Kontext

Nehmen wir ein UE, das zuvor in einem 5GS in Guangzhou registriert war, ausgeschaltet wurde, nach Beijing wechselte und dort über einen Beijing-gNB erneut eingeschaltet wird. Das UE wird nun von einem neuen AMF bedient, kann aber weiterhin die 5G-GUTI besitzen, die zuvor vom AMF in Guangzhou vergeben wurde.

Die in der 5G-GUTI enthaltene GUAMI kann Informationen liefern, mit denen sich das frühere AMF identifizieren lässt. Stellt das neue AMF fest, dass die alte Netzfunktion noch nützlichen UE-Kontext enthält, kann es über die Kommunikation zwischen AMFs einen UE Context Transfer anfordern und Informationen wie SUPI, GPSI, PEI sowie Teile des Mobilitätsmanagement-Kontexts abrufen.

Das verdeutlicht einen wichtigen Punkt: „Initial“ bezeichnet den Typ des aktuellen Registrierungsverfahrens. Es bedeutet nicht, dass der Teilnehmer zum ersten Mal ein 5G-Netz betritt. Das UE kann weiterhin eine zuvor zugewiesene 5G-Identität besitzen, und das neue AMF kann gegebenenfalls Kontext aus dem alten AMF wiederverwenden.

Eine Interaktion mit dem alten AMF ist nicht bei jeder Initial Registration erforderlich. Wenn das neue AMF die benötigten Identitätsinformationen bereits besitzt oder kein früherer UE-Kontext verfügbar ist, kann der Signalisierungsweg anders aussehen. Benötigt das AMF weiterhin die SUCI des UE, kann es einen Identity Request senden, worauf das UE die angeforderte Identität in einer Identity Response zurückgibt.

Das Fehlen eines Identity Request oder UE Context Transfer in einem Pakettrace weist daher nicht für sich allein auf einen Registrierungsfehler hin. Zuerst sollte geprüft werden, welche Identitäts- und Kontextinformationen das AMF bereits besitzt.

5G-AKA macht aus einer behaupteten Identität einen vertrauenswürdigen Teilnehmer

Zu wissen, als wen sich das UE ausgibt, reicht nicht aus, damit das Netz ihm vertraut. Das Verfahren wechselt daher in eine seiner wichtigsten Sicherheitsphasen: die Authentifizierung.

Das AMF muss ein AUSF ermitteln, das den Teilnehmer authentifizieren kann. In einem servicebasierten 5G Core gehört dazu üblicherweise die Ermittlung von Netzfunktionen über das NRF. Auf Grundlage des benötigten Dienstes und teilnehmerbezogener Informationen wählt das AMF eine geeignete AUSF-Instanz aus und sendet eine Authentifizierungsanfrage.

Das AUSF arbeitet anschließend mit den Authentifizierungsfunktionen zusammen, die dem UDM des Heimnetzes zugeordnet sind. Wird SUCI verwendet, kann das Heimnetz die zugehörige SUPI wiederherstellen und die für 5G-AKA erforderlichen Authentifizierungsdaten vorbereiten. Danach übermittelt das AMF Parameter wie RAND und AUTN in einem NAS Authentication Request an das UE. Das UE führt die Authentifizierungsberechnung mit den in der USIM gespeicherten Zugangsdaten durch und sendet eine Authentication Response mit RES* zurück.

Die Authentifizierung beruht nicht auf einem einzigen Vergleich durch eine einzelne Netzfunktion. Die Seite des versorgenden Netzes und die Heimnetzseite führen jeweils ihre Prüfungen durch. Das AMF leitet HRES* aus der vom UE empfangenen Antwort ab und vergleicht es mit HXRES*. Das AUSF prüft das zurückgesendete RES* gegen das erwartete XRES*. Erst wenn die erforderlichen Prüfungen erfolgreich sind, akzeptiert das Netz die Teilnehmeridentität als authentifiziert.

Nach der Authentifizierung richtet das Netz üblicherweise den NAS Security Context ein oder aktualisiert ihn. Anhand von Informationen wie UE Security Capability wählt das AMF geeignete Algorithmen für Integritätsschutz und Verschlüsselung aus und verwendet das Security Mode-Verfahren, damit nachfolgende kritische NAS-Signalisierung geschützt werden kann.

Aus technischer Sicht bildet diese Phase eine klare Sicherheitsgrenze: Vor der Authentifizierung verarbeitet das Netz ein Gerät, das Zugriff anfordert; nach erfolgreicher Einrichtung von Authentifizierung und NAS-Sicherheit besitzt das AMF einen vertrauenswürdigen und geschützten UE-Control-Plane-Kontext.

Teilnehmer- und Richtliniendaten vervollständigen den UE-Kontext

Eine erfolgreiche Authentifizierung beantwortet die Frage, ob die Teilnehmeridentität echt ist. Das AMF muss jedoch weiterhin wissen, was der Teilnehmer im Netz tatsächlich tun darf. Die nächste Phase wandelt die authentifizierte Identität in einen nutzbaren Access-and-Mobility-Kontext um.

Das AMF wählt das geeignete UDM aus und registriert sich über 3GPP-Zugriff als das AMF, das die SUPI derzeit bedient. Diese Registrierung ist wichtig, weil das UDM wissen muss, welches AMF spätere mobilitätsbezogene Benachrichtigungen, Deregistrierungsereignisse oder Änderungen der Teilnehmerdaten für diesen Teilnehmer erhalten soll.

Anschließend ruft das AMF die Access and Mobility Subscription Data ab. Je nach Teilnehmerprofil können dazu Subscribed NSSAI, UE-AMBR, Parameter für die periodische Registrierung, RAT-Beschränkungen und Gebietsrestriktionen gehören. Die Authentifizierung bestätigt also, dass die Identität gültig ist, während die Teilnehmerdaten eine andere Frage beantworten: Was darf dieser gültige Teilnehmer im aktuellen Netz tun?

Das AMF kann außerdem Teilnehmerdaten abrufen, die später für die SMF-Auswahl verwendet werden, einschließlich Informationen zu S-NSSAI, DNNs und einem Standard-DNN. Das führt beim Lesen von Signalisierungsaufzeichnungen häufig zu Verwirrung: Wenn bereits während der Registrierung SMF Selection Subscription Data erscheinen, ist das SMF dann schon Teil des Verfahrens?

Nicht unbedingt. In dieser Phase erhält das AMF lediglich Informationen, die für eine spätere SMF-Auswahl benötigt werden könnten. Initial Registration verlangt nicht, dass gleichzeitig eine PDU Session aufgebaut wird. Das AMF kann diese Teilnehmerdaten daher abrufen, ohne einen SM Context zu erstellen oder ein aktives SMF-Sitzungsmanagement-Verfahren einzubeziehen.

Für die Zugriffsrichtlinie kann das AMF zudem ein PCF auswählen und eine AM Policy Association aufbauen. Vom PCF zurückgegebene Richtlinien können beispielsweise Zugriffsrestriktionen für bestimmte Gebiete beeinflussen. Zu diesem Zeitpunkt hat sich der im AMF gespeicherte UE-Kontext von einer grundlegenden Identität zu einer Kombination aus Identitäts-, Sicherheits-, Teilnehmer-, Netzslice-, Standort- und Richtlinieninformationen entwickelt.

Registration Accept überträgt das Ergebnis auf UE und gNB

Der größte Teil der vorherigen Verarbeitung findet im Kernnetz statt. Das Endergebnis muss jedoch noch an das Zugangsnetz und das UE übermittelt werden. Sobald die erforderlichen Bedingungen erfüllt sind, sendet das AMF einen Initial Context Setup Request an den gNB, überträgt die zum Aufbau des UE-Kontexts benötigten Informationen und leitet den NAS Registration Accept an das UE weiter.

Ein Registration Accept kann Informationen wie eine neu zugewiesene 5G-GUTI, Allowed NSSAI, den Timer T3512 für die periodische Registrierung und die geltende Tracking-Area-Liste enthalten. Diese Parameter bestimmen, wie das UE im 5GS registriert bleibt, welche Netzslices es aktuell nutzen darf und wann es später ein Periodic Registration Update durchführen muss.

Gleichzeitig richtet der gNB den entsprechenden UE-Kontext über das Initial Context Setup-Verfahren ein. Nach Abschluss seiner Verarbeitung sendet der gNB eine Initial Context Setup Response zurück. Das UE bestätigt anschließend das Registrierungsergebnis, indem es ein NAS Registration Complete an das AMF sendet.

Registration Accept und Registration Complete sind daher mehr als einfache Erfolgsmeldungen. Sie wenden das im Kernnetz erzeugte Registrierungsergebnis sowohl auf das UE als auch auf das RAN an und bringen Netz, gNB und Gerät in einen konsistenten 5GS-Registrierungszustand.

Registrierung und Aufbau einer PDU Session sind getrennte Signalisierungswege

Diese Unterscheidung ist bei der Analyse des vollständigen Signalisierungsablaufs entscheidend. Nach Abschluss der 5GS Initial Registration weiß das AMF, wer der Teilnehmer ist, wo sich das UE befindet, welche Zugriffsgebiete und Netzslices erlaubt sind und welcher Sicherheits- und Mobilitätskontext gilt. Keiner dieser Schritte richtet automatisch einen Nutzerdatenpfad in der Nutzerebene ein.

Um auf das Internet oder ein Unternehmensdatennetz zuzugreifen, muss das UE weiterhin PDU Session Establishment durchführen. In dieser Phase übernimmt das SMF das Sitzungsmanagement, wählt oder steuert das UPF und provisioniert über N4 Regeln der Nutzerebene wie PDR, FAR, QER und URR. Auch die N3-Ressourcen zwischen gNB und UPF werden im Rahmen des Sitzungsaufbaus vorbereitet.

In der betrieblichen Fehlersuche ergeben sich daraus zwei sehr unterschiedliche Fehlerkategorien:

Registrierungsfehler: UE-Identität, Authentifizierung, NAS-Sicherheit, UDM-Teilnehmerdaten, NSSAI, Gebietsrestriktionen und AMF-Richtlinienverarbeitung prüfen.

Registrierung erfolgreich, aber Datendienst funktioniert nicht: Die Untersuchung sollte auf PDU Session Establishment, SMF, UPF, N3/N4-Signalisierung und Weiterleitung in der Nutzerebene verlagert werden, statt Registration Request und Registration Accept wiederholt zu prüfen.

Eine klare Trennung dieser Bereiche kann die 5GC-Fehlersuche deutlich verkürzen. Eine 5G-Anzeige am Gerät zeigt lediglich, dass Funkzugriff und Registrierung einen bestimmten Zustand erreicht haben. Ob tatsächlich eine Datenverbindung besteht, hängt weiterhin von Sitzungsmanagement- und Nutzerebenenverfahren ab.

Die Aufzeichnung als Zustandsübergang lesen, nicht als Nachrichtenliste

Standardisierte Signalisierungsdiagramme sind bewusst umfassend, weil sie unterschiedliche Betreiber, Roaming-Szenarien, Zugriffsarten und optionale Netzfunktionen abdecken müssen. Eine Aufzeichnung aus einem realen Netz enthält jedoch nicht zwingend jeden Schritt eines Referenzverfahrens. Eine Interaktion mit dem alten AMF kann fehlen, ein Identity Request kann unnötig sein, EIR muss nicht eingesetzt werden, und ein normaler NR-Zugriff enthält keine Netzfunktionen, die nur für andere Zugriffsarten gelten.

Für die Fehlersuche bei Initial Registration ist es hilfreicher, die Zustandsänderungen des UE zu verfolgen:

Registration Request erreicht das AMF
→ UE-Identität und früherer Kontext werden geklärt
→ Authentifizierung und NAS-Sicherheit werden aufgebaut
→ Teilnehmerdaten werden aus dem UDM abgerufen
→ Geltende Zugriffsrichtlinie wird vom PCF bezogen
→ Das AMF vervollständigt den Registrierungskontext
→ Registration Accept wird zugestellt
→ Das UE sendet Registration Complete zurück

Erreicht der Registration Request das AMF, aber die Authentifizierung beginnt nicht, sollten zunächst Identitätsverarbeitung und Auswahl der Netzfunktion untersucht werden. Ist die Authentifizierung erfolgreich, aber Registration Accept wird nicht zurückgegeben, sind UDM-Daten, NSSAI, Zugriffsrestriktionen und Richtlinienverarbeitung weiter zu prüfen. Ist Registration Accept bereits abgeschlossen und funktionieren lediglich die Nutzerdaten nicht, sollte die Untersuchung schnell zum Signalisierungsweg für die PDU Session wechseln.

Das Verständnis der 5G Initial Registration besteht daher weniger darin, Dutzende Nachrichten auswendig zu lernen, sondern darin zu verfolgen, wie der UE-Kontext im AMF schrittweise vollständig wird: vom Empfang einer Zugriffsanforderung über die Feststellung, wer der Teilnehmer ist, und den Nachweis seiner vertrauenswürdigen Identität bis zur Entscheidung, unter welchen Bedingungen dieser Teilnehmer im 5GS registriert bleiben darf.

Häufige Fragen

Welche Funktion hat T3512 im Registration Accept?

T3512 steuert das Verhalten des UE für periodische Registrierungsaktualisierungen nach der Registrierung. Ein UE bleibt nicht unbegrenzt registriert, ohne regelmäßig mit dem Mobility Management zu interagieren. Das Netz kann mit diesem Timer festlegen, wann das UE ein Periodic Registration Update ausführen soll.

Warum fehlt EIR in manchen kommerziellen 5G-Registrierungsaufzeichnungen?

Die Prüfung der Geräteidentität ist optional. Ob ein EIR eingesetzt wird und unter welchen Bedingungen eine Prüfung der Geräteidentität ausgelöst wird, hängt von Architektur und Betriebsrichtlinien des Netzbetreibers ab. Das Fehlen von EIR-Signalisierung in einem ansonsten normalen Initial-Registration-Verfahren ist daher kein ausreichender Hinweis auf einen Fehler.

Warum fehlt N3IWF normalerweise bei einer standardmäßigen 5G-NR-Registrierung?

N3IWF wird hauptsächlich für nicht vertrauenswürdigen non-3GPP-Zugriff verwendet, beispielsweise für bestimmte Wi-Fi-Zugriffsszenarien auf den 5G Core. Verbindet sich das UE über standardmäßigen 3GPP-NR-Zugriff direkt mit einem gNB, stellt das NG-RAN den Zugriffsweg bereit; N3IWF gehört daher normalerweise nicht zur Registrierungssignalisierung.

Warum kann die Netzfunktionssuche über das NRF in Aufzeichnungen verschiedener Hersteller unterschiedlich oft erscheinen?

Reale 5G-Core-Implementierungen können sich durch Caching der Netzfunktionssuche, statische Konfiguration, SCP-Bereitstellungsmodelle und herstellerspezifisches Service-Routing unterscheiden. Ein vollständiger Austausch zur Netzfunktionssuche über das NRF muss daher nicht vor jeder Serviceoperation erscheinen. Bei der Analyse der Aufzeichnung sollte die ausgewählte NF-Instanz mit der nachfolgenden Serviceanfrage korreliert werden, statt den Ablauf nur anhand der Anzahl der NRF-Nachrichten zu beurteilen.