UMTS - GPRS Tunneling Protocol

Die Generierung des GPRS-Tunneling-Protokolls (GTP) war praktisch unmöglich, ist aber auch nicht wünschenswert, um es für das neue System bereitzustellen, aber andererseits ist es durchaus verständlich, dass die Verbesserungen auch erforderlich sind, um interagieren zu können mit der Welt der alten PS reibungslos und Support-Funktionen für das neueste System benötigt.

GPRS Tunneling Protocol (GTP)

Das GTP-Protokoll dient zum Tunneln und Einkapseln von Dateneinheiten und Steuernachrichten in GPRS. Seit seinem Entwurf Ende der neunziger Jahre wurde es in großem Umfang eingesetzt, und es wurden solide Erfahrungen gesammelt.

Das GTP for Evolved 3GPP-System ist in zwei Varianten erhältlich: Steuerung und Benutzerebene. GTP-C verwaltet die Steuerebenensignalisierung, und es ist zusätzlich zum Datenübertragungsprotokoll für die Reinheit des Benutzers GTP-U erforderlich; es heißt Benutzerebene. Aktuelle Versionen, die für EPS geeignet sind, sind GTPv1 US und GTPv2-C.

Die Besonderheit von GTP besteht darin, dass es die Trennung des Verkehrs innerhalb seines primären GTP-Tunnelhalters unterstützt, oder mit anderen Worten, die Fähigkeit, sie zusammenzufassen und Träger zu behandeln. Die Enden von GTP-Tunneln werden durch TEIDs (Tunnel Endpoint Identifiers) identifiziert. Sie werden von Peer-Entitäten der lokalen Ebene für den Uplink und den Downlink zugewiesen und quer zwischen ihnen gemeldet. TEIDs werden mit unterschiedlicher Granularität verwendet, und zwar anhand einer spezifischen Beispiel-PDN-Verbindung auf S5 und S8 und EU auf S3 / S4 / S10 / S11-Schnittstellen.

Steuerebene des GPRS-Tunnelprotokolls

GTPv2-C wird an den EPC-Signalisierungsschnittstellen verwendet (einschließlich SGSNs von mindestens Rel. 8). Zum Beispiel -

S3 (zwischen SGSN und MME),
S4 (zwischen SGSN und Serving GW),
S5 und S8 (zwischen Serving GW und PDN GW),
S10 (zwischen zwei MMEs) und
S11 (zwischen MME und Serving GW).

Entsprechend einer typischen GTPv2-C-Protokolldateneinheit, wie in der obigen Abbildung gezeigt, werden dem spezifischen Teil GTP IP- und UDP-Header vorangestellt. Sie bestehen aus einem Header GTPv2-C und einem Teil, der Informationen enthält. Die Anzahl der GTPv2-C-Variablen ist variabel. Länge und Format, abhängig vom Typ der Nachricht. Da das Echo und die Benachrichtigung einer Protokollversion nicht unterstützt werden, sind keine TEID-Informationen vorhanden. Die Version ist in dieser Version des Protokolls offensichtlich fest auf 2 gesetzt.

GTP hatte einen komplexen Legacy-Erweiterungs-Header-Mechanismus. Es wird in den meisten GTPv2-C nicht verwendet. Der Nachrichtentyp wird im zweiten Byte definiert (sodass maximal 256 Nachrichten für zukünftige Erweiterungen definiert werden können). Die folgende Tabelle bietet einen Überblick über die aktuell definierten Nachrichten GTPv2-C. Die Länge der Nachricht wird in Byte 3 und 4 codiert (gemessen in Byte und enthält nicht die ersten vier Bytes selbst).

TEID ist die ID des Tunnelendpunkts, ein einzelner Wert auf der gegenüberliegenden / empfangenden Seite; Es ermöglicht das Multiplexen und De-Multiplexen von Tunneln an einem Ende, wobei in den sehr häufigen Fällen über einen GTP-Tunnel unterschieden werden muss.

Nachrichtentyp	Botschaft	Zusätzliche Erklärung
0	Reserviert	Darf niemals verwendet werden (absichtlich vom Protokoll ausgeschlossen, um explizite Einstellungen zu erzwingen)
1/2	Echoanforderung / Antwort	Wird verwendet, um zu prüfen, ob eine GTP-Version vom sendenden Knoten unterstützt wird.
3	Version nicht unterstützt Anzeige	Enthält die neueste GTP-Version, die den sendenden Knoten unterstützt.
4/5	Direktübertragungsanforderung / -antwort	Wird zum Tunneln der Signalisierungsnachricht auf der S101-Schnittstelle für eine optimierte Übergabe zwischen HRPD-Zugriff nicht und MME verwendet
6/7	Benachrichtigungsanforderung / Antwort	Wird für die Tunnelbenachrichtigung auf S101 zwischen HRPD-Zugriffsknoten und MME verwendet
25/26	SRVCC PS zu CS Anfrage	Wird verwendet, um die SRVCC-Initiierung zwischen SGSN / MME und MSC-Server auszulösen und zu bestätigen
27/28	SRVCC PS to CS vollständige Benachrichtigung	Wird verwendet, um den Abschluss des SRVCC zwischen dem MSC-Server und SGSN / MME anzuzeigen und zu bestätigen
32/33	Sitzungsanforderung erstellen	Wird verwendet, um die Konnektivität zwischen zwei Knoten herzustellen
34/35	Trägeranforderung ändern	Wird zum Ändern der Eigenschaften eines einzelnen oder mehrerer Träger verwendet, einschließlich Trägerkontextinformationen
36/37	Sitzungsanforderung löschen	Reißt die GTP-Kontrollsitzung ab
38/39	Benachrichtigungsanforderung ändern	Wird zum Melden von Standortinformationen verwendet
66/67	Trägerbefehls- / Fehleranzeige löschen	Weisen Sie die Knoten an, den Träger zu löschen und zu bestätigen
68/69	Trägerressourcenbefehl / Fehleranzeige	Wird zum Zuweisen oder Ändern von Ressourcen verwendet
73	Beenden Sie die Paging-Anzeige	Von SGW an die MME oder SGSN gesendet
95/96	Erstellen Sie eine Trägeranforderung / -antwort	Weisen Sie die Knoten an, Träger zu installieren, und bestätigen Sie dies zurück
97/98	Inhaberanfrage aktualisieren	Wird verwendet, um die Knoten der Steuerebene von der Benutzerebene über Trägeränderungen zu informieren

Verbessertes GTPv1-U

GTP-U wurde nur geringfügig, aber effektiv verbessert, und daher wurde es nicht als notwendig erachtet, die Anzahl der Protokollversionen zu erhöhen. Daher erwarten wir immer noch GTPv1-U, aber zumindest ist es das neueste Rel. 8.

Der Protokollstapel ist im Wesentlichen der gleiche wie für GTPv2-C, wobei nur der Name der Schichten und die Protokolle entsprechend ersetzt werden. Der Erweiterungskopfmechanismus bleibt an Ort und Stelle; Bei Bedarf können zwei Elemente eingefügt werden.

UDP-Quellport der auslösenden Nachricht (zwei Oktette);
PDCP PDU-Nummer - bezogen auf die charakteristische Übertragung ohne Verlust; In diesem Fall müssen Datenpakete im EPC nummeriert werden (zwei Oktette).

Die Verbesserung ist die Fähigkeit, einen "Endmarkt" in der Benutzerebene zu übertragen. Es wird in der Inter-eNodeB-Übergabeprozedur verwendet und gibt den Hinweis, dass der Pfad unmittelbar nach dem Datenpaket aktiviert wird. Beispielsweise ist die Funktion für Pre-Rel.8 nicht erforderlich, da GTP-U nicht im Funkzugriff endete Knoten (dh nicht in der BS oder NodeB) existieren nur wenige Nachrichten. GTPv1-U, und sie sind in der obigen Tabelle aufgeführt.

Es ist klar, dass tatsächlich eine sehr begrenzte Art der Signalisierung über GTPv1-U (Echomechanismen und Endmarkierung) möglich ist. Die einzige Nachricht, dass die Übertragung von realen Benutzerdaten vom Typ 255 ist, ist die sogenannte G-PDU-Nachricht; Die einzige Information, die nach dem Header übertragen wird, ist das Originaldatenpaket eines Benutzers oder eines externen PDN-Geräts.

Nicht alle Instanzen von GTP-U-Tunneln sind in der Referenzarchitektur aufgeführt (die darauf abzielte, die Assoziationen zu erfassen, die nicht mehr zwischen Netzwerkknoten lebten). temporäre Tunnel sind möglich -

Zwischen zwei Serving GWs, anwendbar für die Übertragung basierend auf S1, für den Fall, dass der Service GW verschoben wird;
Entspricht zwischen zwei SGSNs dem vorherigen Fall, jedoch im alten PS-Netzwerk;
Zwischen zwei RNCs, die für die Verlagerung des RNC in das 3G-PS-Netzwerk gelten (keine Beziehung zum EPC, wird hier nur der Vollständigkeit halber erwähnt).