Wenn ein UE eine Video-App öffnet, muss der eigentliche Nutzerverkehr vom gNB zum UPF gelangen, bevor er das Datennetz erreicht. Die Steuerungsebene richtet die PDU Session ein, weist Adressen zu und installiert Weiterleitungsregeln; das Protokoll, das die IP-Pakete des Nutzers tatsächlich durch die 5G-Zugangs- und Kernnetz-Nutzerebene transportiert, ist jedoch GTP-U. Um GTP-U zu verstehen, reicht es nicht, sich nur „UDP-Port 2152“ und „TEID“ zu merken. In 5G kann ein einzelner N3-Tunnel mehrere QoS Flows tragen. Auch Pfadüberwachung, die Behandlung unbekannter Tunnel und die Bereinigung der Nutzerebene nach Mobilitätsereignissen stützen sich auf GTP-U-Verwaltungsmeldungen. Betrachtet man Protokollstack, Tunnel, TEIDs, QFIs und Verwaltungsverfahren als einen vollständigen Nutzerebenenpfad, wird deutlich leichter verständlich, wie 5G-Verkehr tatsächlich den UPF erreicht.

Wo befindet sich GTP-U in der 5G-Architektur?

GTP-U steht für GPRS Tunnelling Protocol for the User Plane. In der 5G-Nutzerebenenarchitektur dient es hauptsächlich dazu, Nutzverkehr höherer Schichten zwischen Knoten der Nutzerebene zu kapseln und zu transportieren.

Aus Sicht des 5G Core sind die beiden am häufigsten mit GTP-U verwendeten Schnittstellen N3 und N9. N3 verbindet den gNB mit dem UPF und transportiert Nutzerverkehr zwischen Funkzugangsnetz und 5G Core. N9 wird zwischen UPFs verwendet. Innerhalb des RAN kann auch Xn-U zwischen gNBs GTP-U nutzen.

Das unterscheidet sich deutlich von der 5G-Steuerungsebene. Netzwerkfunktionen wie AMF und SMF verwenden servicebasierte Schnittstellen, die weitgehend auf HTTP/2 beruhen, während der Nutzerebenenpfad weiterhin GTP-U für den eigentlichen Teilnehmerverkehr nutzt. Der Übergang zu einer Service-Based Architecture in 5G bedeutet also nicht, dass auch die Nutzerebene selbst auf HTTP umgestellt wurde.

GTP-U läuft über UDP und verwendet weiterhin den UDP-Port 2152. Betrachtet man den Protokollstack vom Anwendungspaket des Nutzers nach unten, lässt sich die Struktur wie folgt verstehen.

Anwendungsverkehr wird zunächst zu einem TCP- oder UDP-Paket und anschließend zu einem IP-Paket des UE. Sobald dieses in die 5G-Nutzerebene gelangt, wird das ursprüngliche Nutzerpaket in GTP-U gekapselt. Für den Transport zwischen den GTP-U-Endpunkten werden anschließend ein äußerer UDP-Header, ein äußerer IP-Header und Ethernet-Frames der darunterliegenden Schichten hinzugefügt.

Eine Paketaufzeichnung kann daher zwei unterschiedliche Sätze von IP-Adressen enthalten. Die inneren IP-Adressen beschreiben die Kommunikation zwischen UE und Anwendungsserver im Datennetz, während die äußeren IP-Adressen zwischen GTP-U-Tunnelendpunkten wie gNB und UPF verwendet werden. Das Verwechseln innerer und äußerer IP-Header ist eine häufige Fehlerquelle bei der Analyse von N3-Verkehr.

Worin unterscheiden sich GTP Path, Tunnel und TEID?

GTP Path, GTP Tunnel, Tunnel Endpoint und TEID sind eng miteinander verknüpfte Begriffe, beschreiben jedoch unterschiedliche Ebenen des GTP-U-Transportmodells.

Ein GTP Path kann als verbindungsloser Kommunikationspfad zwischen zwei GTP-Tunnelendpunkten verstanden werden. Können ein gNB und ein UPF über das IP-Netz GTP-U-Pakete austauschen, besteht zwischen diesen Endpunkten ein GTP Path. Mehrere GTP-U-Tunnel können denselben Path gemeinsam nutzen.

Ein GTP Tunnel stellt einen spezifischeren logischen Nutzerebenentunnel dar. Ein GTP-U-Tunnel wird anhand einer Kombination aus TEID, IP-Adressierung und UDP-Transportinformationen identifiziert, während der Tunnelendpunkt selbst durch die IP-Adresse des Knotens und den UDP-Port bestimmt wird.

Der TEID, also Tunnel Endpoint Identifier, ist eines der wichtigsten Felder in GTP-U. Im GTPv1-U-Basisheader ist der TEID vier Byte lang. Erreicht ein GTP-U-Paket den empfangenden Knoten, verwendet dieser den TEID zusammen mit seinem lokalen Tunnelkontext, um festzustellen, zu welchem Nutzerebenentunnel das Paket gehört und welche PDU Session beziehungsweise welcher Weiterleitungskontext es verarbeiten soll.

Deshalb darf ein TEID niemals isoliert interpretiert werden. Derselbe numerische TEID-Wert kann in unterschiedlichen Tunnelkontexten vorkommen. Gehören Pakete zu unterschiedlichen GTP-Endpunkten oder Richtungen, sind sie nicht zwangsläufig Teil desselben Tunnels.

Beim Blick auf die Nutzlast sind zwei weitere Begriffe hilfreich. Ein T-PDU ist die ursprüngliche Nutzerdaten-Einheit einer höheren Schicht, während ein G-PDU den T-PDU nach dem Hinzufügen des GTP-U-Headers bezeichnet. Über N3 wird daher nicht nur das rohe IP-Paket des UE transportiert, sondern ein durch GTP-U gekapseltes G-PDU.

GTP-U ist außerdem nicht auf den Transport von Nutzerdaten beschränkt. Es besitzt eigene Verwaltungsmeldungen. Das Auftreten von UDP-Port 2152 in einer Paketaufzeichnung bedeutet deshalb nicht automatisch, dass das Paket zum Anwendungsverkehr eines Nutzers gehört. Echo Request, Echo Response, Error Indication, End Marker und weitere GTP-U-Meldungen verwenden dasselbe Protokollgerüst.

Warum benötigt 5G einen QFI, obwohl es bereits den TEID gibt?

Wer GTP-U zunächst aus 4G-Sicht kennenlernt, nimmt leicht an, dass der TEID zur Identifikation des Bearers ausreicht. In 5G ist diese Annahme nicht mehr vollständig.

Die 4G-QoS-Architektur basiert auf EPS Bearers. Unterschiedliche Bearer besitzen eigene Nutzerebenen-Transportkontexte und GTP-U-Tunnel, sodass Tunnel und TEID verschiedene Bearer-Verkehre auf natürliche Weise voneinander unterscheiden helfen.

5G ändert das QoS-Modell zu PDU Session plus QoS Flow. Eine PDU Session kann einen oder mehrere QoS Flows enthalten, und auch ein DRB kann einen oder mehrere QoS Flows tragen. N3 richtet jedoch nicht für jeden QoS Flow innerhalb derselben PDU Session einen separaten GTP-U-Tunnel ein.

Mit anderen Worten: Der TEID kann den der PDU Session zugeordneten GTP-U-Tunnel identifizieren, mehrere QoS Flows können diesen Tunnel jedoch weiterhin gemeinsam nutzen.

Damit stellt sich eine weitere Frage: Woher weiß der empfangende Knoten, zu welchem QoS Flow ein einzelnes Paket gehört?

Genau dafür ist unter anderem der Erweiterungsheader PDU Session Container vorgesehen. 5G verwendet diesen GTP-U-Erweiterungsheader, um nutzerebenenbezogene Informationen zur PDU Session zu transportieren, darunter den QFI, also QoS Flow Identifier.

Der QFI ist ein 6-Bit-Identifikator zur Kennzeichnung eines QoS Flow. Bei der Analyse von 5G-N3-Verkehr lassen sich TEID und QFI daher auf zwei unterschiedlichen Ebenen betrachten:

Der TEID identifiziert den GTP-U-Tunnel beziehungsweise den PDU Session-Kontext, während der QFI den konkreten QoS Flow innerhalb dieses Tunnels kennzeichnet.

Der Downlink-PDU Session Container kann außerdem Informationen wie RQI und PPI tragen. RQI wird für Reflective-QoS-bezogene Signalisierung verwendet, während PPI mit Paging Policy Differentiation zusammenhängt und unterschiedliche Paging-Behandlungen für verschiedene Verkehrstypen innerhalb derselben PDU Session unterstützen kann.

Das E-Bit im GTP-U-Basisheader zeigt an, ob ein Extension Header folgt. Daher tragen nicht alle GTP-U-Pakete zwangsläufig dieselben Erweiterungsheader. Ob ein PDU Session Container vorhanden ist, hängt vom jeweiligen Paket und der ausgeführten Funktion ab.

Was geschieht tatsächlich mit einem N3-Nutzerpaket?

Die bisherigen Konzepte werden deutlich verständlicher, wenn man sie in einen realen Uplink-Paketfluss einordnet.

Angenommen, ein UE greift auf einen Online-Videodienst zu. Das UE erzeugt zunächst Anwendungsverkehr, der über TCP oder UDP transportiert und anschließend in ein normales IP-Paket eingebettet wird. Im inneren IP-Header ist die Quelladresse die dem UE zugewiesene IP-Adresse; die Zieladresse gehört zum Internet-Anwendungsserver.

Erreicht das Paket den gNB, leitet der gNB das IP-Paket des UE nicht einfach direkt an den UPF weiter. Stattdessen führt er anhand des aktuellen Nutzerebenenkontexts der PDU Session eine GTP-U-Kapselung durch.

Der GTP-U-Header enthält den zugehörigen TEID. Muss das Paket einen bestimmten QoS Flow kennzeichnen, kann der PDU Session Container zusätzlich den QFI tragen. Anschließend fügt der gNB den UDP-Header mit Zielport 2152 sowie danach den äußeren IP-Header hinzu.

An diesem Punkt beschreiben die äußeren IP-Adressen nicht mehr die Kommunikation zwischen UE und Internet. Sie repräsentieren die Transportbeziehung zwischen der N3-Schnittstelle des gNB und der N3-Schnittstelle des UPF.

Wenn das Paket den UPF erreicht, läuft der Vorgang umgekehrt ab. Der UPF empfängt das Paket anhand der äußeren Transportinformationen, liest den TEID, um den richtigen Nutzerebenen-Tunnelkontext zu finden, verarbeitet bei Bedarf QFI und weitere Erweiterungsinformationen, entfernt die GTP-U-Kapselung und leitet das ursprüngliche UE-IP-Paket anschließend in Richtung Datennetz weiter.

Bei der Fehlersuche in N3-Verkehr mit Wireshark oder einem anderen Paketanalysewerkzeug ist es sinnvoll, von außen nach innen vorzugehen. Zunächst werden die äußeren IP-Adressen von gNB und UPF geprüft, danach UDP-Port 2152, anschließend TEID sowie gegebenenfalls PDU Session Container und QFI. Erst danach werden die innere IP-Kommunikation des Nutzers, TCP oder UDP und der Anwendungsschichtverkehr untersucht.

Diese Methode ist häufig wirkungsvoller als der Einstieg beim Anwendungspaket, weil viele N3-Fehler durch Tunnelkontext, TEID oder Endpunktprobleme verursacht werden und nicht durch die Anwendung des Nutzers selbst.

Warum benötigt GTP-U eigene Verwaltungsmeldungen?

Obwohl GTP-U ein Nutzerebenenprotokoll ist, beschränkt es sich nicht auf G-PDU-Meldungen für Nutzerdaten. Es definiert auch Meldungen für Pfad- und Tunnelmanagement, die den Betrieb des Nutzerebenentransports unterstützen.

Echo Request und Echo Response prüfen die Pfadverfügbarkeit

Ein Echo Request prüft, ob der GTP Path und der entfernte GTP-Knoten erreichbar und betriebsbereit sind. Der Peer antwortet mit einem Echo Response.

Diese Meldungen testen die grundlegende Beziehung zwischen zwei GTP-Endpunkten. Erhält ein gNB wiederholt keine Echo Responses von einem UPF, ist das Problem möglicherweise nicht mehr auf ein einzelnes UE oder eine einzelne PDU Session beschränkt. Es kann auf eine Störung des GTP Path selbst oder des Peer-Knotens hinweisen.

GTP-U definiert außerdem die Meldung Supported Extension Headers Notification. Damit kann ein Knoten angeben, welche GTP-Erweiterungsheader er unterstützt. Dies ist relevant, wenn 5G-Nutzerebenenfunktionen von Erweiterungsheadern wie dem PDU Session Container abhängen.

Error Indication behandelt unbekannte TEIDs

Empfängt ein GTP-Endpunkt ein G-PDU, findet jedoch keinen lokalen EPS Bearer oder PDU Session-Kontext für den empfangenen TEID und ist der TEID nicht null, kann er dem Peer eine Error Indication senden.

Damit wird dem sendenden Knoten mitgeteilt, dass er Daten an einen Nutzerebenentunnel weiterleitet, den die Empfangsseite nicht mehr kennt.

Treten bei der Fehlersuche wiederholt Error Indication-Meldungen auf, sollte zuerst geprüft werden, ob beide Endpunkte einen konsistenten TEID-Status besitzen und ob ein PDU Session-Update, ein Mobilitätsverfahren oder eine Änderung des Nutzerebenenpfads beide Seiten aus dem Takt gebracht hat.

End Marker unterstützt den Abschluss eines Nutzerebenen-Pfadwechsels

Der End Marker wird häufig mit Mobilität und Nutzerebenen-Pfadumschaltungen in Verbindung gebracht. Er zeigt an, dass das letzte G-PDU auf dem alten GTP-U-Pfad gesendet wurde und nachfolgender Nutzerverkehr nicht mehr über diesen bisherigen Pfad laufen soll.

Wechselt ein UE beispielsweise von einem Quell-gNB zu einem Ziel-gNB, kann sich auch der Nutzerebenenpfad im Kernnetz ändern. Der Verkehr darf nicht unbegrenzt über den alten Pfad weiterlaufen, da sich sonst alter und neuer Pfad überlappen und Probleme bei Paketreihenfolge oder Weiterleitung verursachen könnten.

Der End Marker ist deshalb nicht einfach eine Meldung zum „Löschen des Tunnels“. Er wirkt eher als Grenzmarkierung des alten Nutzerebenenpfads und informiert die Empfangsseite darüber, dass das letzte Paket auf diesem Pfad bereits übertragen wurde.

Betrachtet man diese Mechanismen gemeinsam, wird die Rolle von GTP-U wesentlich klarer. Es ist nicht nur ein Protokoll, das einem IP-Paket des Nutzers einen TEID voranstellt. Es stellt ein vollständiges Nutzerebenen-Tunneling-Framework bereit, das bei Änderungen des Netzwerkzustands identifiziert, überwacht, verwaltet und aktualisiert werden kann.

Eine praktische Reihenfolge für die 5G-GTP-U-Fehlersuche lautet daher: Zuerst den Zustand der GTP-Endpunkte und des Path prüfen, anschließend TEID und Tunnelkontext verifizieren, gegebenenfalls PDU Session Container und QFI untersuchen und erst danach zum ursprünglichen Nutzerverkehr nach innen gehen. Tritt das Problem während Mobilität oder Pfadaktualisierungen auf, sollten zusätzlich Error Indication und End Marker ausgewertet werden.

Mit dieser Reihenfolge wird aus einer N3-Paketaufzeichnung mit einer großen Zahl von UDP-2152-Paketen ein Nutzerebenen-Weiterleitungspfad, der Schicht für Schicht rekonstruiert werden kann.

Häufig gestellte Fragen

Transportiert jedes Paket auf UDP-Port 2152 Nutzerverkehr?

Nein. G-PDU-Meldungen transportieren Nutzerebenendaten über GTP-U und UDP-Port 2152, aber auch GTP-U-Verwaltungsmeldungen wie Echo Request, Echo Response, Error Indication, End Marker und Supported Extension Headers Notification verwenden dasselbe Protokollgerüst. Der GTP-U Message Type sollte geprüft werden, um festzustellen, was das Paket tatsächlich darstellt.

Muss ein TEID im gesamten 5G-Netz weltweit eindeutig sein?

Nein. Ein TEID sollte nicht als netzweit global eindeutiger Identifikator betrachtet werden. Die Identifikation eines GTP-U-Tunnels hängt auch von den Tunnelendpunkten, der IP-Adressierung, den Transportinformationen und der Richtung ab. Bei der Fehlersuche ist daher der vollständige Tunnelkontext zu berücksichtigen, statt nur TEID-Werte zu vergleichen.

Enthält jedes 5G-GTP-U-Paket einen PDU Session Container?

Nein. Der PDU Session Container ist ein GTP-U-Erweiterungsheader; ob er vorhanden ist, hängt vom jeweiligen Paket und der ausgeführten Funktion ab. Das E-Bit im GTP-U-Basisheader zeigt an, ob weitere Extension Headers folgen. Deshalb besitzen nicht alle N3-Pakete dieselbe Headerstruktur.

Bedeutet ein End Marker, dass die gesamte PDU Session freigegeben wurde?

Nicht unbedingt. Ein End Marker zeigt in erster Linie an, dass der Verkehr auf einem bestimmten GTP-U-Nutzerebenenpfad beendet ist, und tritt häufig bei Pfadumschaltungen nach Mobilitätsereignissen auf. Er markiert das Ende des Verkehrs auf diesem Pfad und nicht die vollständige Freigabe der PDU Session.