Ein Smartphone kann bereits ein 5G-Symbol anzeigen, während sich Webseiten trotzdem nicht laden lassen. In dieser Situation wird häufig zuerst der Registrierungsablauf geprüft: Wurde 5G-AKA abgeschlossen? Ist ein Registration Accept eingegangen? Ist T3512 abgelaufen? Nach diesen Prüfungen kann der Registration-Ablauf vollständig normal aussehen, obwohl der Datendienst weiterhin nicht funktioniert.
In vielen Fällen liegt das Problem nicht bei Registration, sondern bei der PDU Session. Registration beantwortet die Frage: „Kann sich das UE beim 5GS registrieren?“ PDU Session Establishment beantwortet die nächste Frage: „Kann das UE tatsächlich ein Datennetz erreichen?“ Dieser Artikel verfolgt den Aufbau der PDU Session von Anfang bis Ende – wie das UE eine Session anfordert, wie das AMF ein SMF auswählt, wie das SMF Teilnehmer- und Policy-Informationen abruft, wie das UPF konfiguriert wird und wie der N3-Tunnel schließlich vollständig aufgebaut wird.
Nachdem das UE die 5GS Registration abgeschlossen hat, verfügt das AMF bereits über Benutzeridentität, Mobilitäts-, Sicherheits- und zugehörigen Teilnehmerkontext. Ein erfolgreicher Registrierungsabschluss bedeutet jedoch nicht, dass bereits ein User-Plane-Pfad vorhanden ist. Das UE kann weiterhin keinen aktiven Pfad zum Internet oder zu einem Unternehmensdatennetz besitzen.
PDU Session Establishment bringt das UE vom Zustand „registriert“ in den Zustand „kann Anwendungsverkehr übertragen“. Das UE fordert eine Session an, das Netz wählt SMF und UPF aus, ruft die zu DNN und S-NSSAI gehörenden Teilnehmerdaten ab, erhält die Session-Policy, installiert PFCP-Regeln im UPF und koordiniert mit dem gNB den Aufbau des N3-Tunnels. Am Ende des Ablaufs besitzt das UE eine IP-Adresse, QoS-Regeln und einen User-Plane-Pfad zum Data Network.
Der Ablauf lässt sich leichter verstehen, wenn er nicht als einzelne isolierte NAS-Nachricht betrachtet wird. Drei Vorgänge laufen zusammen: Session Management, Policy Control und die Konfiguration von User-Plane-Ressourcen. Sie führen schließlich zu einer nutzbaren PDU Session.
Funktionale Trennung zwischen PDU-Session und 5GS-Registrierung
Im 5GC ist die Trennung zwischen Registration und PDU Session klar: Registration stellt die Netzregistrierung her, die PDU Session die Datenkonnektivität.
Registration legt fest, ob das UE in das 5GS eintreten kann. Das AMF prüft die UE-Identität, führt die Authentisierung durch, richtet NAS-Sicherheit ein, ruft mobilitätsbezogene Teilnehmerdaten ab und erstellt den für RM (Registration Management) und CM (Connection Management) erforderlichen Kontext. Nach Abschluss dieser Schritte ist die Management-Beziehung zwischen UE und Core-Netz aufgebaut.
Eine PDU Session ist mit dem tatsächlichen Datendienst verknüpft. Benötigt das UE Internetzugang, IMS-Konnektivität oder ein privates Unternehmensnetz, reicht Registration allein nicht aus. Das Netz muss außerdem bestimmen, welches DNN verwendet wird, welches S-NSSAI gilt, welches SMF die Session steuert, welches UPF die User Plane trägt und welche QoS- und Bandbreitenparameter zulässig sind.
Der Vergleich mit EPC erleichtert das Verständnis. LTE verwendet die Konzepte PDN Connection und EPS Bearer. Im 5GC wird dieses Modell durch PDU Session + QoS Flow ersetzt. Nach dem Aufbau einer PDU Session erzeugt das Netz QoS-Regeln und QoS-Flow-Ressourcen statt eines LTE-typischen Default EPS Bearer.
Wichtig ist außerdem, dass eine PDU Session nicht gleichzeitig mit der initialen Registration aufgebaut werden muss. Ein UE kann die Registration abschließen und ohne PDU Session registriert bleiben, bis eine Anwendung tatsächlich Datendienst benötigt. Das Gerät kann sich beispielsweise beim Einschalten registrieren, während die PDU Session erst eine halbe Stunde später beim Öffnen einer Videoanwendung eingerichtet wird.
Diese Trennung ist bei der Trace-Analyse hilfreich. Wenn Registration erfolgreich abgeschlossen wurde, PDU Session Establishment jedoch nicht, führt die wiederholte Prüfung von 5G-AKA, Registration Accept oder T3512 in der Regel nicht zur Lösung des Datendienstproblems, weil der falsche Ablauf untersucht wird.
DNN, S-NSSAI und Anforderungstyp in der PDU-Session-Anforderung
PDU Session Establishment beginnt mit einer vom UE gesendeten NAS-Nachricht. Ein PDU Session Establishment Request teilt dem Core-Netz nicht nur mit: „Ich benötige Datenzugang.“ Die in der Anforderung enthaltenen Informationselemente beeinflussen die spätere NF-Auswahl und Session-Konfiguration.
Eine typische initiale Anforderung kann PDU Session ID, Request Type, PDU Session Type, SSC Mode, DNN und S-NSSAI enthalten.
PDU Session ID unterscheidet mehrere Sessions desselben UE. Ein UE kann mehrere PDU Sessions gleichzeitig unterhalten – beispielsweise eine für den Internetzugang und eine weitere für ein privates Unternehmensnetz. SUPI identifiziert den Teilnehmer, legt allein aber nicht fest, welche einzelne PDU Session gerade verarbeitet wird.
DNN bezeichnet das Data Network, das das UE erreichen möchte. Betreiber-Internetzugang, IMS und Unternehmensnetze können unterschiedliche DNNs verwenden. Das DNN fließt später außerdem in die SMF-Auswahl, UPF-Auswahl und Policy-Entscheidungen ein.
S-NSSAI ordnet die Session einem bestimmten Netzwerk-Slice (Network Slice) zu. AMF und SMF müssen feststellen, ob der angeforderte Netzwerk-Slice mit dem Teilnehmerprofil, dem angeforderten DNN und den bereitgestellten Netzfähigkeiten übereinstimmt.
Request Type kennzeichnet den Kontext der Anforderung. Neben einer neuen PDU Session kann der Ablauf auch mit einer bestehenden Session, einem Zugangswechsel oder einem Notdienstszenario zusammenhängen. Bei der Trace-Analyse darf daher ein PDU Session Establishment Request nicht automatisch jedes Mal als dasselbe Szenario interpretiert werden.
Der häufigste Fall ist ein Initial Request: Das UE hat Registration bereits abgeschlossen und erstellt nun eine neue PDU Session für ein bestimmtes DNN. SMF-Auswahl, Abruf der UDM-Teilnehmerdaten, PCF-Policy-Steuerung und Aufbau der UPF-Ressourcen werden von diesem Session-Kontext bestimmt.
SMF-Auswahl und Erstellung des SM Context durch das AMF
Die NAS-Session-Management-Nachricht des UE erreicht zunächst das gNB und wird anschließend über NGAP zusammen mit zugangsbezogenen Informationen wie NR-CGI und TAI an das AMF weitergeleitet. Das gNB trifft keine PDU-Session-Steuerungsentscheidungen; es transportiert die NAS-Informationen zum Core-Netz.
Nach Eingang der Anforderung muss das AMF ein SMF identifizieren, das das angeforderte S-NSSAI und DNN bedienen kann.
In einer servicebasierten 5GC-Architektur kann das AMF den NRF zur NF-Discovery verwenden. Die Suchkriterien können den Ziel-NF-Typ, den benötigten Dienst Nsmf_PDUSession, S-NSSAI, DNN und das Serving PLMN umfassen. Der NRF liefert geeignete SMF-Instanzen zurück; anschließend wählt das AMF gemäß Netzrichtlinie das tatsächlich zuständige SMF aus.
Danach ruft das AMF den PDU-Session-Dienst des SMF auf, um einen SM Context zu erstellen. Neben SUPI, PDU Session ID, DNN und S-NSSAI enthält die Anforderung den ursprünglichen PDU Session Establishment Request des UE als N1-SM-Information.
Ab diesem Punkt verlagert sich die zentrale Session-Steuerung vom AMF zum SMF. Das AMF verwaltet weiterhin Zugang und Mobilität und leitet N1-SM-Signalisierung zwischen UE und SMF weiter. Das SMF entscheidet jedoch, wie die PDU Session aufgebaut wird, welches UPF ausgewählt wird, welche Policies gelten und wie die User-Plane-Regeln konfiguriert werden.
Für die Fehlersuche ist ein praktischer Punkt wichtig: Die Zahl der NRF-Transaktionen in einem kommerziellen Netz muss nicht exakt einem Referenz-Signalisierungsdiagramm entsprechen. NF-Discovery-Ergebnisse können zwischengespeichert sein, statische Konfiguration kann verwendet werden oder ein SCP kann das Dienst-Routing übernehmen. Entscheidend ist nicht, ob eine bestimmte NRF-Abfrage im Trace erscheint, sondern ob das gewählte SMF das benötigte DNN, S-NSSAI und die erforderlichen Service-Fähigkeiten tatsächlich unterstützt.
UDM-Teilnehmerdaten und Verarbeitung der PCF-Session-Policy
Sobald das SMF weiß, welche Art von Session das UE anfordert, kann es die User Plane noch nicht sofort einrichten. Zuerst muss bestimmt werden, welche Art von PDU Session der Teilnehmer tatsächlich aufbauen darf.
In einem typischen Ablauf ermittelt das SMF das passende UDM, registriert sich als zuständiges SMF für SUPI und PDU Session und ruft die mit dem angeforderten S-NSSAI und DNN verknüpften Session Management Subscription Data ab.
Die Teilnehmerdaten können den zulässigen PDU Session Type, SSC Mode, Session-AMBR und Standard-QoS-Einstellungen enthalten. Diese Werte definieren die teilnehmerbezogenen Grenzen der Session. Fordert das UE beispielsweise eine IPv4-PDU-Session an, muss das SMF dennoch prüfen, ob das DNN diesen PDU Session Type zulässt und ob der angeforderte SSC Mode erlaubt ist.
Das SMF kann außerdem Änderungen an den SM-Teilnehmerdaten abonnieren. Werden die relevanten Session-Management-Teilnehmerdaten später im UDM geändert, kann das UDM das zuständige SMF über den registrierten Callback URI informieren.
Nutzt die Implementierung eine dynamische SM Policy Control, wählt das SMF ein PCF aus und erstellt eine SM Policy Association. Das SMF liefert Kontextinformationen wie SUPI, PDU Session ID, DNN, S-NSSAI, UE-Standort und abonnierte QoS-Parameter. Das PCF gibt anschließend die autorisierte Session-Policy zurück, die Session-AMBR, Standard-QoS und weitere anwendbare Policy-Regeln enthalten kann.
Diese Phase lässt sich als Zusammenführung der Session-Parameter betrachten:
UE-Dienstanforderung → UDM-Teilnehmergrenzen → PCF-Policy-Autorisierung → SMF legt die endgültigen Session-Steuerparameter fest
Die später im UPF installierten QoS- und Weiterleitungsregeln basieren auf diesen Ergebnissen.
N4-Session-Aufbau und Installation von User-Plane-Regeln im UPF
Nach Festlegung der Session-Parameter wählt das SMF ein UPF aus, das DNN, S-NSSAI und UE-Standort bedienen kann, und baut anschließend über die N4-Schnittstelle eine PFCP Session auf.
PFCP Session Establishment Request ist einer der wichtigsten Schritte im PDU-Session-Aufbau. Bis hierhin hat das Netz vor allem mit abstrakten Dienstanforderungen gearbeitet. Auf N4 werden diese Anforderungen in Regeln umgesetzt, die das UPF auf reale Benutzerpakete anwenden kann.
Das SMF kann PDR-, FAR-, QER- und URR-Regeln im UPF installieren:
PDR: legt fest, wie das UPF Pakete erkennt, die zur PDU Session oder zu einem bestimmten Verkehrsfluss gehören;
FAR: definiert, was mit passenden Paketen geschehen soll, etwa Weiterleitung, Verwerfen, Puffern oder eine andere anwendbare Aktion;
QER: setzt die erforderlichen QoS-Vorgaben im UPF durch;
URR: definiert Anforderungen für Messung und Meldung der User-Plane-Nutzung.
Diese Regeln sollten nicht als vier voneinander unabhängige Funktionen betrachtet werden. Gemeinsam bestimmen sie, wie das UPF den Verkehr verarbeitet. Das PDR erkennt den Paketfluss und verweist auf die zutreffenden FAR-, QER- und URR-Regeln, damit das UPF weiß, wohin Pakete weitergeleitet werden, welche QoS-Vorgaben gelten und ob die Nutzung gemessen werden muss.
Akzeptiert das UPF das PFCP Session Establishment, liefert es sein F-SEID und die erzeugten User-Plane-Parameter zurück. Zu den wichtigsten Ergebnissen gehören die UPF-seitige User-Plane-Adresse und der für N3 verwendete TEID.
Zu diesem Zeitpunkt kann der Downlink-Pfad jedoch noch unvollständig sein, weil das gNB seine N3-Ressourcen noch nicht vollständig zugewiesen hat. PDU Session Establishment endet daher nicht mit einer einzigen PFCP-Anforderung. Der Ablauf benötigt weiterhin die RAN-seitige Fertigstellung des User-Plane-Aufbaus.
N1/N2-Signalisierung vervollständigt N3-Tunnel und QoS-Flow-Aufbau
Nachdem die UPF-seitigen Ressourcen bereitstehen, muss das SMF über das AMF zwei unterschiedliche Informationssätze zurückgeben.
Der erste ist N1 SM information und wird letztlich an das UE geliefert. Er enthält den PDU Session Establishment Accept zusammen mit den Parametern, die das UE nach dem Session-Aufbau benötigt, darunter PDU Session Type, SSC Mode, DNN, S-NSSAI, UE-IP-Adresse, Session-AMBR und die standardmäßige QoS Rule.
Der zweite ist N2 SM information und für das gNB bestimmt. Er teilt dem RAN mit, welche PDU Session aufgebaut wird, welche QoS Flows beteiligt sind und welche UPF-IP-Adresse sowie welcher TEID auf N3 verwendet werden sollen.
Das AMF sendet über NGAP einen PDU Session Resource Setup Request an das gNB. Das gNB weist die erforderlichen Funk- und N3-Ressourcen zu und leitet den PDU Session Establishment Accept an das UE weiter.
Nach dem Resource Setup sendet das gNB einen PDU Session Resource Setup Response zurück. Dieser enthält die eigene N3-User-Plane-Adresse und den TEID sowie Informationen zu den erfolgreich eingerichteten QoS Flows.
Ein wichtiges Timing-Detail ist zu beachten. Beim initialen Aufbau der PFCP Session kennt das SMF bereits die N3-Informationen auf UPF-Seite, möglicherweise jedoch noch nicht die endgültigen Tunnelinformationen auf gNB-Seite. Sobald das gNB seine N3-Adresse und den TEID zurückliefert, übermittelt das AMF diese Informationen an das SMF. Das SMF verwendet dann PFCP Session Modification, um das entsprechende FAR im UPF zu aktualisieren, sodass Downlink-Pakete in den richtigen GTP-U-Tunnel zum gNB gekapselt werden können.
An diesem Punkt sind Up- und Downlink-Pfade der User Plane vollständig:
UE → gNB → N3 GTP-U → UPF → N6 → Data Network
Data Network → N6 → UPF → N3 GTP-U → gNB → UE
Deshalb beweist der Empfang eines PDU Session Establishment Accept allein noch nicht, dass alle User-Plane-Elemente korrekt sind. N3-Tunnelparameter, PFCP Session Modification und die finalen UPF-Regeln müssen zusätzlich anhand der tatsächlichen Paketweiterleitung geprüft werden.
Signalisierungs-Fehlersuche beim PDU-Session-Aufbau
PDU Session Establishment umfasst zahlreiche Network Functions. Wer zur Fehlersuche jede Nachricht ab dem ersten Paket vergleicht, verliert schnell den Überblick. Effizienter ist es, den Ablauf in mehrere Prüfpunkte zu teilen und den Fehlerbereich schrittweise einzugrenzen.
Prüfen, ob die Session-Anforderung das AMF korrekt erreicht
Prüfen Sie zuerst, ob das UE die erforderliche 5GS Registration abgeschlossen hat. Analysieren Sie dann den PDU Session Establishment Request und stellen Sie sicher, dass PDU Session ID, Request Type, DNN, S-NSSAI, PDU Session Type und SSC Mode passend sind. Enthält die Anforderung bereits am Eintrittspunkt einen ungültigen Parameter, können auch ein fehlerfreies SMF und UPF nicht die erwartete Session erzeugen.
Prüfen, ob das SMF einen gültigen SM Context erstellt
Prüfen Sie anschließend, ob das AMF ein geeignetes SMF auswählt und Create SM Context erfolgreich ist. Ziel ist nicht nur, eine NRF-Nachricht im Trace zu finden, sondern zu bestätigen, dass das ausgewählte SMF das benötigte DNN, S-NSSAI und die erforderlichen Service-Fähigkeiten unterstützt.
Prüfen Sie danach, ob die vom UDM gelieferten SM-Teilnehmerdaten die angeforderte PDU Session zulassen und ob die PCF-Policy zur erwarteten QoS-Konfiguration passt.
Prüfen, ob UPF- und N3-Ressourcen vollständig sind
Wenn die Steuerungsebene bereits einen PDU Session Establishment Accept zurückgegeben hat, das UE aber weiterhin keine Daten übertragen kann, sollte die Analyse auf N4 und N3 verlagert werden.
Prüfen Sie nacheinander:
ob PFCP Session Establishment erfolgreich ist und das UPF die zugehörige Session erstellt;
ob PDR, FAR, QER und weitere Regeln zur erwarteten Verkehrsrichtung passen;
ob das gNB seine N3-User-Plane-IP-Adresse und den TEID erfolgreich zurückgibt;
ob das SMF die gNB-Tunnelinformationen über PFCP Session Modification im UPF aktualisiert;
ob auf N3 tatsächlich GTP-U-Pakete mit dem erwarteten TEID erscheinen;
ob das UPF über N6 erfolgreich Verkehr zum Ziel-Data-Network senden und von dort empfangen kann.
Diese Reihenfolge hilft, das Problem auf NAS, SBI, N4, N3 oder die UPF-Paketweiterleitung einzugrenzen, statt das gesamte 5GC als einen undifferenzierten Fehlerbereich zu behandeln.
Häufige Fragen
Warum kann ein UE die 5G-Registrierung abschließen und trotzdem nicht auf das Internet zugreifen?
Registration stellt den Zugangs-, Identitäts-, Sicherheits- und Mobilitätskontext zwischen UE und 5GC her. Sie erzeugt nicht automatisch einen User-Data-Pfad. Bevor das UE auf das Internet oder ein anderes Data Network zugreifen kann, benötigt es weiterhin eine PDU Session, damit das SMF die Session-Parameter, UPF-Ressourcen und die N3-User-Plane konfigurieren kann.
Wird beim Einschalten des UE immer eine PDU Session aufgebaut?
Nein. Eine PDU Session kann zeitnah zur Registration aufgebaut werden, sie kann aber auch erst später initiiert werden, wenn das UE tatsächlich einen Datendienst benötigt. Das 5GS erlaubt einem UE, ohne aktive PDU Session registriert zu bleiben. Der Abschluss von Registration und PDU Session Establishment sollte daher nicht als dasselbe Ereignis betrachtet werden.
Garantiert ein erfolgreicher PDU-Session-Aufbau, dass das UE auf das Internet zugreifen kann?
Nein. Ein PDU Session Establishment Accept auf NAS-Ebene allein ist kein ausreichender Beleg für erfolgreiche Datenkonnektivität. Der tatsächliche Benutzerverkehr hängt außerdem vom N3-Tunnel zwischen gNB und UPF, den PDR/FAR/QER-Regeln im UPF, der N6-Verbindung und dem Ziel-Data-Network ab. Ein UE kann eine IP-Adresse erhalten, obwohl die User-Plane-Weiterleitung weiterhin fehlerhaft ist.
Warum erfolgt PFCP Session Modification nach PFCP Session Establishment?
Wenn die initiale PFCP Session im UPF erstellt wird, hat das gNB seine N3-Ressourcen möglicherweise noch nicht vollständig zugewiesen. Das SMF kennt dann eventuell die endgültige gNB-User-Plane-IP-Adresse und den TEID noch nicht. Nachdem das gNB diese Werte im PDU Session Resource Setup Response zurückgegeben hat, aktualisiert das SMF die entsprechenden UPF-Regeln über PFCP Session Modification, damit Downlink-Verkehr über den richtigen N3-GTP-U-Tunnel gesendet werden kann.
Sind QFI in einer PDU Session und QER an der N4-Schnittstelle dasselbe Konzept?
Nein. QFI identifiziert einen QoS Flow im 5GS, während QER eine vom SMF über N4 im UPF konfigurierte QoS Enforcement Rule ist. Eine QER wirkt an der QoS-Durchsetzung mit und kann gegebenenfalls einem QFI zugeordnet sein; QFI selbst ist jedoch keine QER und beide Konzepte sind nicht austauschbar.
