Bei der Aufzeichnung der 5G-Registrierungssignalisierung ist auf derselben N2-Verbindung häufig folgende Abfolge zu sehen: Zuerst erscheint Initial UE Message, gefolgt von Uplink NAS Transport und Downlink NAS Transport, dann Initial Context Setup. Sobald das UE tatsächlich beginnt, die Datenkonnektivität aufzubauen, erscheint PDU Session Resource Setup. Die einzelnen Nachrichten zu verstehen, ist nicht besonders schwierig. Anspruchsvoller ist zu verstehen, warum sie in dieser Reihenfolge auftreten und welche Aufgabe NGAP tatsächlich im gesamten 5G-Steuerungsebene übernimmt. N2 lässt sich sinnvoll als dauerhafter Steuerkanal zwischen gNB und AMF betrachten. Zunächst bauen die Netzknoten ihre Beziehung auf, anschließend wird der UE-Kontext erstellt, und erst danach werden die RAN-Ressourcen für die PDU-Sitzung vorbereitet. Wenn sich das UE bewegt, in den Idle-Zustand wechselt oder sich seine Dienstparameter ändern, werden weitere NGAP-Prozeduren ausgelöst.
Was macht die N2-Schnittstelle tatsächlich?
N2 ist die Schnittstelle der Steuerungsebene zwischen gNB und AMF und verwendet NGAP, das NG Application Protocol (NG-Anwendungsprotokoll). Funktional weist sie Ähnlichkeiten mit der in 4G verwendeten S1-MME-Schnittstelle auf, arbeitet jedoch innerhalb der 5G-Systemarchitektur.
SCTP dient als Transportschicht für N2. NGAP läuft über SCTP, während NAS-Nachrichten, die zwischen UE und 5G Core ausgetauscht werden, über NGAP zwischen gNB und AMF transportiert werden können. Ein typischer N2-Protokollstack lässt sich daher so verstehen: IP stellt die Netzerreichbarkeit zwischen gNB und AMF bereit, SCTP stellt die N2-Transportassoziation bereit, NGAP überträgt N2-Steuerprozeduren und -parameter, und 5G NAS wird bei Bedarf als NAS-PDU transportiert.
NGAP selbst transportiert nicht den normalen Verkehr der Nutzerebene des UE. Die eigentlichen Nutzerdaten werden in der Regel über die N3-Nutzerebene übertragen. N2 ist für Steuerfunktionen wie Ressourcenaufbau, UE-Kontextverwaltung, Transport von NAS-Signalisierung und Mobilitätskoordination zuständig. Funktional unterstützt N2 den Aufbau, die Pflege und die Freigabe von NG-RAN-Ressourcen, die PDU-Sitzungen zugeordnet sind, und wirkt zugleich bei UE-Kontextverwaltung, Mobilitätsmanagement, NAS-Signalisierungstransport und Steuerung von Ressourcen der Nutzerebene mit.
Warum werden NGAP-Prozeduren in UE-zugeordnete und nicht UE-zugeordnete Prozeduren unterteilt?
Wer NGAP erstmals untersucht und direkt in Dutzende Prozeduren und Nachrichtennamen einsteigt, landet schnell beim reinen Auswendiglernen. Praktischer ist es, zunächst zu klären, ob die jeweilige Prozedur einem bestimmten UE zugeordnet ist.
UE-zugeordnete Prozeduren beziehen sich auf den Kontext, die Sitzung oder den Mobilitätszustand eines bestimmten Nutzers. Beispiele sind PDU-Sitzungsressourcenverwaltung, UE-Kontextverwaltung, Handover, Paging, NAS-Transport, Standortmeldung und Prozeduren zur UE-Funkfähigkeit. Nicht UE-zugeordnete Prozeduren halten dagegen in erster Linie die Beziehung auf Knotenebene zwischen gNB und AMF aufrecht. Typische Beispiele sind NG Setup, RAN Configuration Update, AMF Configuration Update, NG Reset, AMF Status Indication und Overload Start/Stop.
Diese Unterscheidung ist bei der Fehleranalyse von Paketmitschnitten äußerst hilfreich. Sind Nutzer eines gesamten gNB betroffen, sollten zunächst Prozeduren auf Knotenebene wie SCTP, NG Setup, Reset, AMF-Status oder Überlastbehandlung geprüft werden. Ist nur ein UE betroffen, sollte die Analyse stattdessen dessen NGAP-IDs, NAS-Transportnachrichten, Kontextprozeduren und PDU-Sitzungsressourcensignalisierung verfolgen.
NGAP-Prozeduren lassen sich außerdem danach, ob eine Antwort erforderlich ist, in Class 1 und Class 2 unterteilen. Class-1-Prozeduren umfassen typischerweise Request und Response und können zusätzlich ein Failure-Ergebnis enthalten. Class-2-Prozeduren erfordern keine prozedurbezogene Antwort des Gegenübers. In der praktischen Fehleranalyse ist es meist hilfreicher zu prüfen, ob eine Prozedur einen erfolgreichen oder erfolglosen Ausgang erwartet, als die Klasse jeder NGAP-Nachricht auswendig zu lernen.
Wie baut N2 den Zustand vom gNB-Start bis zur UE-Registrierung auf?
Bevor überhaupt ein UE erscheint, geht es für den gNB zunächst nicht um die Teilnehmerregistrierung. Er muss zuerst feststellen, ob er ordnungsgemäß mit der AMF kommunizieren kann.
Der erste Schritt ist üblicherweise NG Setup. Nachdem die SCTP-Assoziation zwischen gNB und AMF aufgebaut wurde, sendet der gNB einen NG Setup Request. Akzeptiert die AMF die Verbindung, antwortet sie mit einem NG Setup Response. In einer AMF-Pool-Bereitstellung muss der gNB gegebenenfalls N2-Beziehungen zu mehreren AMFs herstellen und Informationen abrufen, die später für die AMF-Auswahl benötigt werden. Zu diesem Zeitpunkt besteht lediglich die Beziehung auf Knotenebene; ein konkreter UE-Kontext existiert noch nicht.
Beginnt ein UE mit der Registrierung, wechselt die Signalisierung auf die nächste Ebene. Nach Empfang der ersten NAS-Nachricht des UE kann der gNB diese über Initial UE Message an die AMF weiterleiten. Die nachfolgende NAS-Signalisierung zwischen UE und AMF wird typischerweise über N2 mit Uplink NAS Transport und Downlink NAS Transport übertragen. Wichtig ist, dass der gNB nicht die gesamte NAS-Dienstlogik interpretieren muss. Bei einem großen Teil der NAS-Signalisierung besteht seine Hauptaufgabe darin, den richtigen UE-Kontext zu identifizieren und das NAS-PDU an die zuständige AMF zuzustellen.
Im weiteren Verlauf der Registrierung muss die AMF den gNB auch dazu veranlassen, den UE-Kontext auf RAN-Seite aufzubauen. Hier erscheinen Initial Context Setup Request und Initial Context Setup Response. Initial Context Setup Request kann wichtige UE-bezogene Informationen wie Allowed NSSAI, GUAMI, UE Security Capabilities, Mobility Restriction List und NAS-PDU enthalten. In dieser Phase leitet der gNB nicht mehr nur NAS-Signalisierung weiter, sondern beginnt, den Zustand aufzubauen, der für die weitere Versorgung dieses UE erforderlich ist.
Wie richtet NGAP PDU-Sitzungsressourcen ein, wenn das UE Daten nutzt?
Eine erfolgreiche Registrierung bedeutet nicht, dass bereits alle Ressourcen der Nutzerebene für das UE verfügbar sind. Wenn das UE auf ein Datennetz zugreifen muss und eine PDU-Sitzung aufbaut, beteiligt sich N2 auch an der Vorbereitung der entsprechenden RAN-Ressourcen.
Eine der zentralen Prozeduren ist PDU Session Resource Setup. Die AMF sendet einen PDU Session Resource Setup Request an den gNB. Diese Nachricht transportiert Informationen zur PDU-Sitzung und zu deren QoS Flows in Richtung NG-RAN, etwa PDU Session ID, S-NSSAI, Tunnelinformationen der Nutzerebene und QoS Flow List. Der gNB weist anschließend entsprechend den lokalen Bedingungen die erforderlichen Funkressourcen zu, beispielsweise indem er die benötigten DRBs für die QoS Flows konfiguriert und die N3-Nutzerebene-Verbindung vorbereitet.
Nach Abschluss der Ressourcenzuweisung sendet der gNB einen PDU Session Resource Setup Response an die AMF und zeigt damit an, welche Ressourcen erfolgreich eingerichtet wurden. Die Antwort kann Informationen der Nutzerebene des gNB sowie die erfolgreich zugelassenen QoS Flows enthalten.
An dieser Stelle werden die Rollen von N1, N2 und N3 häufig verwechselt. N1 transportiert NAS-Schicht-Informationen zur PDU-Sitzung zum UE. N2 koordiniert die RAN-Ressourcen und die Ressourcen der Nutzerebene, die der gNB einrichten muss. N3 transportiert den eigentlichen Verkehr der Nutzerebene, nachdem diese Ressourcen bereitstehen.
Deshalb sollte die Fehlersuche bei einer fehlgeschlagenen PDU-Sitzung nicht enden, sobald die NAS-Schicht eine Accept-Nachricht zurückgibt. Wenn die N2-Prozedur PDU Session Resource Setup nicht erfolgreich abgeschlossen wird, kann das UE die Sitzungsparameter bereits empfangen haben, während die Nutzerebene noch nicht betriebsbereit ist.
N2 arbeitet auch nach dem Aufbau der PDU-Sitzung weiter
NGAP stoppt nicht, sobald die PDU-Sitzung aktiv ist. Solange das UE im Netz verbleibt, können Zustandsänderungen oder geänderte Dienstbedingungen weitere N2-Prozeduren auslösen.
Wechselt das UE zu einem anderen gNB, kann ein N2- oder Xn-basierter Handover ausgelöst werden. Ein N2-Handover kann Handover Required, Handover Request, Handover Request Acknowledge, Handover Command und Handover Notify umfassen. Ist der neue Pfad eingerichtet, können Path Switch Request und dessen Antwort folgen, während der alte UE-Kontext auf dem Quell-gNB freigegeben wird.
Befindet sich das UE im Idle-Zustand und trifft Downlink-Verkehr ein, kann die AMF über NGAP eine Paging-Nachricht an das NG-RAN senden, woraufhin das RAN das funkseitige Paging-Verfahren ausführt. Paging ist eine typische einseitige NGAP-Prozedur. Muss das Netz QoS oder andere RAN-Ressourcen anpassen, kann PDU Session Resource Modify ausgelöst werden. Wird die Sitzung nicht mehr benötigt, kommt PDU Session Resource Release zum Einsatz. Der N2-Lebenszyklus einer PDU-Sitzung umfasst daher nicht nur Setup, sondern auch Modify, Release, Notify und zugehörige Indication-Prozeduren.
Neben UE-bezogenen Dienstprozeduren können Ingenieure auch Schnittstellenverwaltungsnachrichten wie NG Reset, Error Indication, Overload Start, Overload Stop, AMF Status Indication und Konfigurationsaktualisierungen sehen. Sie sind besonders hilfreich, um festzustellen, ob ein Problem nur ein UE betrifft oder eine umfassendere Änderung der N2-Knotenbeziehung widerspiegelt.
In welcher Reihenfolge sollte ein NGAP-Paketmitschnitt am besten analysiert werden?
NGAP enthält sehr viele Nachrichten, doch in der praktischen Fehleranalyse muss die 3GPP-Nachrichtenliste nicht von oben nach unten geprüft werden. Besser ist es, der Reihenfolge zu folgen, in der der Netzzustand aufgebaut wird.
Der erste Schritt ist die Prüfung von SCTP. Wenn die Transport Network Layer Association zwischen gNB und AMF nicht korrekt aufgebaut wurde, bringt die Analyse der anschließend erwarteten NGAP-Dienstprozeduren wenig.
Im zweiten Schritt wird NG Setup geprüft und bestätigt, dass die N2-Beziehung auf Knotenebene fehlerfrei ist. Ist NG Setup fehlgeschlagen, ist es normalerweise wenig sinnvoll, direkt zur Fehleranalyse der UE-Registrierung zu springen.
Der dritte Schritt besteht darin, das betreffende UE zu identifizieren. UE-zugeordnete NGAP-Nachrichten enthalten normalerweise die entsprechenden UE-NGAP-ID-Werte. Die Paketanalyse sollte dieselben UE-Kennungen über die Zeit verfolgen, statt nur nach Nachrichtentyp zu filtern.
Im vierten Schritt wird geprüft, ob die NAS-Signalisierung korrekt transportiert wird. Kontrollieren Sie, ob Initial UE Message, Uplink NAS Transport und Downlink NAS Transport eine durchgängige Sequenz bilden. Hat das NAS-PDU die AMF bereits erreicht, ohne dass eine Antwort folgt, ist die Untersuchungsrichtung eine ganz andere als in einem Fall, in dem der gNB die NAS-Nachricht gar nicht erst zugestellt hat.
Im fünften Schritt wird der Aufbau des UE-Kontexts geprüft. Wenn die Registrierung bis Initial Context Setup fortgeschritten ist, sollten die Parameter im Request geprüft und der erfolgreiche Abschluss des Response bestätigt werden.
Im sechsten Schritt werden die PDU-Sitzungsressourcen untersucht. Ist das UE registriert, kann aber nicht auf das Datennetz zugreifen, sollte der Fokus auf PDU Session Resource Setup Request/Response und den zurückgegebenen Ergebnissen für PDU-Sitzungs- und QoS-Flow-Ressourcen liegen.
Tritt das Problem während der Mobilität auf, sollte sich die Analyse auf Handover, Path Switch und die Freigabe des alten UE-Kontexts verlagern. Ist ein inaktives UE für Downlink-Verkehr nicht erreichbar, sollte Paging geprüft werden.
Der Ablauf SCTP → NG Setup → UE-Identifikation → NAS → UE-Kontext → PDU-Sitzung → Mobilität ist in der praktischen Arbeit meist deutlich effektiver, als Dutzende NGAP-Nachrichtennamen auswendig zu lernen.
Häufig gestellte Fragen
Wie hängen NGAP und 5G NAS zusammen?
NGAP ist das Anwendungsschichtprotokoll auf der N2-Schnittstelle zwischen gNB und AMF, während NAS die Steuersignalisierung zwischen UE und 5G Core transportiert. Viele NAS-Nachrichten werden als NAS-PDUs in NGAP-Nachrichten gekapselt und vom gNB zwischen UE und AMF weitergeleitet, sodass beide Protokolle auf unterschiedlichen Schichten arbeiten.
Transportiert die N2-Schnittstelle den Internetverkehr des UE?
Nein. N2 dient nicht als normaler Pfad der Nutzerebene für UE-Daten, sondern transportiert Signalisierung der Steuerungsebene. Nutzerverkehr wird typischerweise über N3 zwischen gNB und UPF übertragen, während NGAP dem RAN mitteilt, welche zugehörigen Ressourcen aufgebaut, geändert oder freigegeben werden müssen.
Bedeutet ein erfolgreiches NG Setup, dass sich das UE normal registrieren kann?
Nein. NG Setup stellt lediglich die N2-Beziehung auf Knotenebene zwischen gNB und AMF her. Sobald ein bestimmtes UE hinzukommt, müssen Initial UE Message, NAS-Transport, UE-Kontextaufbau und die späteren PDU-Sitzungsressourcenprozeduren weiterhin erfolgreich abgeschlossen werden.
Warum sollte die NGAP-Fehleranalyse nicht nur auf Nachrichtentyp-Filtern beruhen?
Ein einzelner gNB kann gleichzeitig viele UEs verarbeiten, und dieselben NGAP-Nachrichtentypen können für verschiedene Nutzer wiederholt auftreten. Eine Filterung nur nach Nachrichtennamen kann leicht unabhängige Prozeduren vermischen. Bei UE-spezifischer Fehleranalyse sollten UE-NGAP-ID-Werte, Nachrichtenzeitpunkte und der jeweilige NAS- oder PDU-Sitzungskontext gemeinsam betrachtet werden.
