GPRS Tunnelling Protocol

GPRS Tunnelling Protocol (GTP) is a group of IP-based communications protocols used to carry general packet radio service (GPRS) within GSM, UMTS, LTE and 5G NR radio networks. In 3GPP architectures, GTP and Proxy Mobile IPv6 based interfaces are specified on various interface points.

GTP can be decomposed into separate protocols, GTP-C, GTP-U and GTP'.

GTP-C is used within the GPRS core network for signaling between gateway GPRS support nodes (GGSN) and serving GPRS support nodes (SGSN). This allows the SGSN to activate a session on a user's behalf (PDP context activation), to deactivate the same session, to adjust quality of service parameters, or to update a session for a subscriber who has just arrived from another SGSN.

GTP-U is used for carrying user data within the GPRS core network and between the radio access network and the core network. The user data transported can be packets in any of IPv4, IPv6, or PPP formats.

GTP' (GTP prime) uses the same message structure as GTP-C and GTP-U, but has an independent function. It can be used for carrying charging data from the charging data function (CDF) of the GSM or UMTS network to the charging gateway function (CGF). In most cases, this should mean from many individual network elements such as the GGSNs to a centralized computer that delivers the charging data more conveniently to the network operator's billing center.

Different GTP variants are implemented by RNCs, SGSNs, GGSNs and CGFs within 3GPP networks. GPRS mobile stations (MSs) are connected to a SGSN without being aware of GTP.

GTP kann mit UDP oder TCP verwendet werden . UDP ist entweder empfohlen oder obligatorisch, außer beim Tunneling von X.25 in Version 0. GTP Version 1 wird ausschließlich mit UDP verwendet.

Alle GTP-Varianten weisen bestimmte Gemeinsamkeiten auf. Die Nachrichtenstruktur ist identisch, wobei dem UDP/TCP-Header ein GTP-Header folgt.

Die GTPv1-Header enthalten die folgenden Felder: ^{[ 1 ]}

Version

Es handelt sich um ein 3-Bit-Feld. Bei GTPv1 hat es den Wert 1.

Protokolltyp (PT)

ein 1-Bit-Wert, der GTP (Wert 1) von GTP' (Wert 0) unterscheidet.

Reserviert

ein 1-Bit-reserviertes Feld (muss 0 sein).

Erweiterungsheader-Flag (E)

ein 1-Bit-Wert, der angibt, ob ein optionales Feld im Erweiterungsheader vorhanden ist.

Sequenznummernflag (S)

ein 1-Bit-Wert, der angibt, ob ein optionales Feld für die Sequenznummer vorhanden ist.

N-PDU-Nummernflag (PN)

ein 1-Bit-Wert, der angibt, ob ein optionales Feld für die N-PDU-Nummer vorhanden ist.

Nachrichtentyp

Ein 8-Bit-Feld, das den Typ der GTP-Nachricht angibt. Verschiedene Nachrichtentypen sind in 3GPP TS 29.060 Abschnitt 7.1 definiert.

Nachrichtenlänge

Ein 16-Bit-Feld, das die Länge der Nutzdaten in Bytes angibt (der Rest des Pakets nach dem obligatorischen 8-Byte-GTP-Header). Enthält die optionalen Felder.

Tunnelendpunktkennung (TEID)

Ein 32-Bit-Feld (4 Oktette), das zum Multiplexen verschiedener Verbindungen im selben GTP-Tunnel verwendet wird.

Sequenznummer

Ein (optionales) 16-Bit-Feld. Dieses Feld ist vorhanden, wenn mindestens eines der Bits E, S oder PN gesetzt ist. Das Feld muss nur interpretiert werden, wenn das S-Bit gesetzt ist.

N-PDU-Nummer

Ein (optionales) 8-Bit-Feld. Dieses Feld ist vorhanden, wenn eines der Bits E, S oder PN gesetzt ist. Das Feld muss nur interpretiert werden, wenn das PN-Bit gesetzt ist.

Nächster Erweiterungskopfzeilentyp

Ein (optionales) 8-Bit-Feld. Dieses Feld ist vorhanden, wenn eines der Bits E, S oder PN gesetzt ist. Das Feld muss nur interpretiert werden, wenn das Bit E gesetzt ist.

Die nächsten Erweiterungsheader lauten wie folgt:

Verlängerungslänge

Ein 8-Bit-Feld. Dieses Feld gibt die Länge dieses Erweiterungsheaders an, einschließlich der Länge, des Inhalts und des nächsten Erweiterungsheaderfelds, in 4-Oktett-Einheiten, sodass die Länge der Erweiterung immer ein Vielfaches von 4 sein muss.

Inhalt

Inhalt des Erweiterungsheaders.

Nächster Erweiterungskopf

Ein 8-Bit-Feld. Es gibt den Typ der nächsten Erweiterung an oder 0, falls keine nächste Erweiterung existiert. Dies ermöglicht die Verkettung mehrerer Header für nächste Erweiterungen.

Es ist auch als eGTP (evolved-GTP) bekannt. GTPv2-C-Header enthalten die folgenden Felder: ^{[ 2 ]}

Es gibt kein GTPv2-U-Protokoll, GTP-U in LTE verwendet auch GTPv1-U.

Version

Es handelt sich um ein 3-Bit-Feld. Für GTPv2 hat es den Wert 2.

Huckepackflagge

Wenn dieses Bit auf 1 gesetzt ist, wird am Ende der aktuellen Nachricht eine weitere GTP-C-Nachricht mit eigenem Header angehängt. Es gibt Einschränkungen hinsichtlich des Nachrichtentyps, der angehängt werden kann, abhängig von der GTP-C-Nachricht der obersten Ebene.

TEID-Flagge

Wenn dieses Bit auf 1 gesetzt ist, befindet sich das TEID-Feld zwischen der Nachrichtenlänge und der Sequenznummer. Alle Nachrichten außer Echo und Echo-Antwort erfordern das Vorhandensein von TEID.

Nachrichtenlänge

Dieses Feld gibt die Länge der Nachricht in Oktetten an, wobei die obligatorischen ersten vier Oktette des GTP-C-Headers nicht mitgezählt werden. Die TEID (falls vorhanden) und die Sequenznummer werden in die Längenberechnung einbezogen.

Neben der gemeinsamen Nachrichtenstruktur gibt es auch einen gemeinsamen Mechanismus zur Überprüfung der Konnektivität zwischen zwei GSNs. Hierfür werden zwei Nachrichten verwendet.

• Echo-Anfrage
• Echoantwort

Bis zu alle 60 Sekunden kann ein GSN eine Echo-Anfrage an jedes andere GSN senden, mit dem es eine aktive Verbindung hat. Antwortet die Gegenseite nicht, wird sie als ausgefallen betrachtet und die aktiven Verbindungen zu ihr werden gelöscht.

Abgesehen von den beiden zuvor erwähnten Nachrichten gibt es keine weiteren Nachrichten, die allen GTP-Varianten gemeinsam sind ^{[ 3 ],} was bedeutet, dass sie größtenteils effektiv drei völlig getrennte Protokolle bilden.

Das GTP-C-Protokoll ist der Steuerungsteil des GTP-Standards. Fordert ein Teilnehmer einen PDP-Kontext an , sendet der SGSN eine GTP-C-Nachricht zur Erstellung eines PDP-Kontexts an den GGSN, die die Details der Anfrage des Teilnehmers enthält. Der GGSN antwortet daraufhin mit einer GTP-C-Nachricht zur Erstellung eines PDP-Kontexts , die entweder Details zum tatsächlich aktivierten PDP-Kontext enthält oder einen Fehler mit dessen Grund meldet. Diese Nachricht wird über UDP auf Port 2123 übertragen.

Das eGTP-C- Protokoll (oder GTPv2-C-Protokoll) ist für die Erstellung, Aufrechterhaltung und Löschung von Tunneln auf mehreren Sx-Schnittstellen zuständig. Es wird für das Pfadmanagement der Steuerungsebene, das Tunnelmanagement und das Mobilitätsmanagement verwendet. Außerdem steuert es die Weiterleitung von Standortverlagerungsnachrichten, den SRNS-Kontext und die Erstellung von Vorwärtstunneln bei LTE-Übergaben.

GTP-U ist im Prinzip ein relativ einfaches IP-basiertes Tunnelprotokoll, das mehrere Tunnel zwischen jedem Endpunktpaar ermöglicht. Bei Verwendung im UMTS-Netz verfügt jeder Teilnehmer über einen oder mehrere Tunnel – einen für jeden aktiven PDP-Kontext – sowie gegebenenfalls über separate Tunnel für spezifische Verbindungen mit unterschiedlichen QoS-Anforderungen.

Die einzelnen Tunnel werden in den GTP-U-Nachrichten durch eine TEID (Tunnel Endpoint Identifier) ​​identifiziert, die eine dynamisch generierte Zufallszahl sein sollte. Ist diese Zufallszahl kryptografisch sicher, bietet sie einen gewissen Schutz vor bestimmten Angriffen. Dennoch schreibt der 3GPP-Standard vor, dass der gesamte GTP-Datenverkehr, einschließlich der Benutzerdaten, über sichere private Netzwerke und nicht direkt über das Internet übertragen werden muss. Dies geschieht über UDP-Port 2152.

Das GTPv1-U- Protokoll dient dem Austausch von Benutzerdaten über GTP-Tunnel zwischen den Sx-Schnittstellen. Ein IP-Paket für ein UE (Benutzerendpunkt) wird in ein GTPv1-U-Paket gekapselt und zwischen dem P-GW und dem eNodeB getunnelt, um es über die S1-U- und S5/S8-Schnittstellen an ein UE zu übertragen.

Das GTP- Protokoll dient der Übertragung von Ladedaten an die Charging Gateway Function. GTP verwendet den TCP/UDP-Port 3386.

GTP ist das primäre Protokoll im GPRS-Kernnetz. Es ermöglicht Endnutzern eines GSM- oder UMTS-Netzes, sich standortunabhängig zu bewegen und dabei die Internetverbindung aufrechtzuerhalten, als ob sie sich an einem festen Standort im GGSN befänden. Dies geschieht durch die Übertragung der Teilnehmerdaten vom aktuellen SGSN des Teilnehmers zum GGSN, der die Teilnehmersitzung verwaltet. Im GPRS-Kernnetz werden drei GTP-Varianten verwendet.

• GTP-U für die Übertragung von Benutzerdaten in separaten Tunneln für jeden PDP-Kontext
• GTP-C aus Kontrollgründen, unter anderem:
  • Einrichtung und Löschung von PDP-Kontexten
  • Überprüfung der GSN-Erreichbarkeit
  • Aktualisierungen; z. B. wenn Abonnenten von einem SGSN zu einem anderen wechseln.
• GTP' für die Übertragung von Ladedaten von GSNs an die Ladefunktion.

GGSNs und SGSNs (gemeinsam als GSNs bezeichnet) empfangen GTP-C-Nachrichten auf UDP-Port 2123 und GTP-U-Nachrichten auf Port 2152. Diese Kommunikation findet innerhalb eines einzelnen Netzwerks statt oder kann im Falle von internationalem Roaming international erfolgen, wahrscheinlich über eine GPRS-Roaming-Vermittlungsstelle (GRX).

Die Charging Gateway Function (CGF) empfängt GTP- Nachrichten von den GSNs über TCP/UDP-Port 3386. Das Kernnetz sendet Abrechnungsinformationen an die CGF, typischerweise einschließlich der Aktivierungszeiten des PDP-Kontexts und der vom Endnutzer übertragenen Datenmenge. Diese netzwerkinterne Kommunikation ist jedoch weniger standardisiert und kann, abhängig vom Hersteller und den Konfigurationsoptionen, proprietäre Codierungen oder sogar ein vollständig proprietäres System verwenden.

GTP-U wird auf der IuPS zwischen dem GPRS-Kernnetz und dem RAN verwendet, das GTP-C-Protokoll hingegen nicht. In diesem Fall dient RANAP als Steuerungsprotokoll und stellt GTP-U-Tunnel zwischen dem SGSN und dem Funknetzcontroller (RNC) her.

GTP kann mit UDP oder TCP verwendet werden . GTP Version 1 wird nur mit UDP verwendet.

Seit 2018 existieren drei Versionen: Version 0, 1 und 2. Version 0 und Version 1 unterscheiden sich strukturell deutlich. In Version 0 ist das Signalisierungsprotokoll (das die Tunnel durch Aktivierung des PDP-Kontexts einrichtet) mit dem Tunnelprotokoll auf einem Port kombiniert. Version 1 und 2 bestehen jeweils aus zwei separaten Protokollen: einem für die Steuerung (GTP-C) und einem für das Tunneln von Benutzerdaten (GTP-U). GTP Version 2 unterscheidet sich von Version 1 lediglich in GTP-C. Dies liegt daran, dass 3GPP in Version 2 Erweiterungen für EPS in GTP-C definiert hat, um die Trägerverarbeitung zu verbessern.

GTP-U wird auch verwendet, um Nutzerdaten vom RNC zum SGSN in UMTS-Netzen zu transportieren. In diesem Fall erfolgt die Signalisierung jedoch mittels RANAP anstelle von GTP-C.

Die ursprüngliche Version von GTP (Version 0) wies erhebliche Unterschiede zu den aktuellen Versionen (Versionen 1, 2) auf:

• Die Tunnelidentifizierung erfolgte nicht zufällig;
• Es wurden Optionen für den Transport von X.25 bereitgestellt ;
• Für alle Funktionen wurde die feste Portnummer 3386 verwendet (nicht nur für das Laden wie bei GTPv1).
• TCP war als Transportoption anstelle von UDP zulässig, die Unterstützung dafür war jedoch optional.
• Abonnementbezogene Bereiche wie beispielsweise die Servicequalität waren stärker eingeschränkt.

Die nicht zufällige TEID in Version 0 stellte ein Sicherheitsrisiko dar, falls ein Angreifer Zugriff auf das Netzwerk eines Roaming-Partners hatte oder auf anderem Wege Pakete an das GPRS-Backbone senden konnte. Version 0 wird in fast allen Netzwerken durch Version 1 ersetzt. Glücklicherweise ermöglicht die Verwendung unterschiedlicher Portnummern jedoch die einfache Sperrung von Version 0 mithilfe einfacher IP-Zugriffslisten.

GTP wurde ursprünglich im Rahmen des ETSI (GSM-Standard 09.60 ^{[ 4 ]} ) standardisiert . Mit der Entwicklung der UMTS-Standards wurde dieser Standard an das 3GPP übertragen , das ihn seit 2005 als 3GPP-Standard 29.060 ^{[ 5 ]} pflegt. GTP verwendet dasselbe Nachrichtenformat, seine speziellen Anwendungsfälle sind jedoch im Standard 32.295 zusammen mit den standardisierten Formaten für die übertragenen Abrechnungsdaten geregelt.

Spätere Versionen von TS 29.060 machen die Interoperabilität von GTPv1/v0 ^{[ 6 ]} für veraltet , sodass es keinen Fallback gibt, falls das GSN die höhere Version nicht unterstützt.

GTPv2 (für Evolved Packet Services) wurde Anfang 2008 als Entwurf veröffentlicht und im Dezember desselben Jahres freigegeben. GTPv2 bietet über den früheren Mechanismus „Version Not Supported“ die Möglichkeit, auf GTPv1 zurückzugreifen, jedoch explizit keine Unterstützung für einen Rückgriff auf GTPv0.

• Proxy Mobile IPv6
• Mobile IP
• PFCP
• RANAP

• GSM-Standard 09.60, ETSI, 1996–98, dieser Standard umfasst die ursprüngliche Version 0 von GTP.
• 3GPP TS 29.060 V6.9.0 (2005-06) , 3rd Generation Partnership Project, 650 Route des Lucioles - Sophia Antipolis, Valbonne - FRANKREICH, 2005–06. Dies ist der primäre Standard, der alle GTP-Varianten für GTP Version 1 definiert.
• 3GPP TS 32.295 V6.1.0 (2005-06) , 3rd Generation Partnership Project, 650 Route des Lucioles - Sophia Antipolis, Valbonne - FRANKREICH, 2005–06. Dieser Standard beschreibt die Verwendung von GTP zum Laden.
• 3GPP TS 29.274 V8.1.0 (2009–03) , Partnerschaftsprojekt der 3. Generation, 650 Route des Lucioles – Sophia Antipolis, Valbonne – FRANKREICH, 2009–03. GTPv2 für weiterentwickeltes GPRS.

• Die 3GPP-Website, Heimat des GTP-Standards
• Kostenlose und quelloffene Implementierung des GPRS-Tunneling-Protokolls Version 2 (GTPv2) oder Evolved GTP (eGTP)