GPRS-tunnelprotokoll
| Internetprotokollsvit |
|---|
| Applikationslager |
| Transportlager |
| Internetlager |
| Länklager |
GPRS Tunneling Protocol ( GTP ) är en grupp av IP -baserade kommunikationsprotokoll som används för att bära allmänna paketradiotjänster (GPRS) inom GSM- , UMTS- , LTE- och 5G NR -radionätverk. I 3GPP-arkitekturer specificeras GTP- och Proxy Mobile IPv6- baserade gränssnitt på olika gränssnittspunkter.
GTP kan delas upp i separata protokoll, GTP-C, GTP-U och GTP' .
GTP-C används inom GPRS-kärnnätverket för signalering mellan gateway GPRS-stödnoder (GGSN) och betjänande GPRS-stödnoder (SGSN). Detta tillåter SGSN att aktivera en session för en användares vägnar ( PDP-kontextaktivering ), att avaktivera samma session, att justera tjänstekvalitetsparametrar eller att uppdatera en session för en abonnent som just har anlänt från ett annat SGSN.
GTP-U används för att överföra användardata inom GPRS-kärnnätet och mellan radioaccessnätet och kärnnätet. Användardata som transporteras kan vara paket i vilket IPv4- , IPv6- eller PPP- format som helst.
GTP' ( GTP prime ) använder samma meddelandestruktur som GTP-C och GTP-U, men har en oberoende funktion. Den kan användas för att överföra laddningsdata från laddningsdatafunktionen (CDF) i GSM- eller UMTS-nätverket till laddningsgatewayfunktionen (CGF). I de flesta fall bör detta innebära från många enskilda nätverkselement såsom GGSN:erna till en centraliserad dator som levererar laddningsdata mer bekvämt till nätoperatörens faktureringscenter.
Olika GTP-varianter implementeras av RNC, SGSN, GGSN och CGF inom 3GPP-nätverk. GPRS-mobilstationer (MS) är anslutna till ett SGSN utan att vara medvetna om GTP.
GTP kan användas med UDP eller TCP . UDP är antingen rekommenderat eller obligatoriskt, förutom för tunnling X.25 i version 0. GTP version 1 används endast på UDP.
Allmänna funktioner
Alla varianter av GTP har vissa gemensamma egenskaper. Strukturen på meddelandena är densamma, med en GTP-rubrik efter UDP/TCP-rubriken.
Rubrik
GTP version 1
GTPv1-rubriker innehåller följande fält:
| + | 0-2 | 3 | 4 | 5 | 6 | 7 | 8-15 | 16-23 | 24-31 | |||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0 | Version | Protokolltyp | Reserverad | Förlängningshuvudflagga | Sekvensnummerflagga | N-PDU-nummerflagga | Meddelandetyp | Meddelandets längd | ||||||||||||||||||||||||
| 32 | TEID | |||||||||||||||||||||||||||||||
| 64 | Sekvensnummer | N-PDU-nummer | Nästa typ av tilläggshuvud | |||||||||||||||||||||||||||||
- Version
- Det är ett 3-bitarsfält. För GTPv1 har detta värdet 1.
- Protocol Type (PT)
- ett 1-bitars värde som skiljer GTP (värde 1) från GTP' (värde 0).
- Reserverat
- ett 1-bitars reserverat fält (måste vara 0).
- Extension header flag (E)
- ett 1-bitars värde som anger om det finns ett tilläggshuvud valfritt fält.
- Sekvensnummerflagga (S)
- ett 1-bitars värde som anger om det finns ett valfritt sekvensnummerfält.
- N-PDU-nummerflagga (PN)
- ett 1-bitars värde som anger om det finns ett valfritt N-PDU-nummer.
- Meddelande Skriv
- ett 8-bitarsfält som anger typen av GTP-meddelande. Olika typer av meddelanden definieras i 3GPP TS 29.060 avsnitt 7.1
- Meddelandelängd
- ett 16-bitars fält som indikerar längden på nyttolasten i byte (resten av paketet efter den obligatoriska 8-byte GTP-huvudet). Inkluderar de valfria fälten.
- Tunnel endpoint identifier (TEID)
- Ett 32-bitars(4-oktett) fält som används för att multiplexera olika anslutningar i samma GTP-tunnel.
- Sekvensnummer
- ett (valfritt) 16-bitarsfält. Detta fält finns om någon av E-, S- eller PN-bitarna är på. Fältet måste endast tolkas om S-biten är på.
- N-PDU-nummer
- ett (valfritt) 8-bitarsfält. Detta fält finns om någon av E-, S- eller PN-bitarna är på. Fältet måste endast tolkas om PN-biten är på.
- Nästa tilläggshuvud skriv
- ett (valfritt) 8-bitarsfält. Detta fält finns om någon av E-, S- eller PN-bitarna är på. Fältet måste endast tolkas om E-biten är på.
Nästa tilläggsrubriker är följande:
| + | Bits 0-7 | 8-23 | 24-31 | |||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0 | Förlängningslängd | Innehåll | ||||||||||||||||||||||||||||||
| ... | ... | |||||||||||||||||||||||||||||||
| ... | Innehåll | Nästa tilläggshuvud | ||||||||||||||||||||||||||||||
- Förlängningslängd
- ett 8-bitars fält. Det här fältet anger längden på detta tilläggshuvud, inklusive längden, innehållet och nästa tilläggshuvudfält, i 4-oktettenheter, så längden på tillägget måste alltid vara en multipel av 4. Innehållsförlängningsrubrikens
- innehåll
- .
- Nästa tilläggshuvud
- ett 8-bitarsfält. Den anger typen av nästa tillägg, eller 0 om det inte finns någon nästa tillägg. Detta tillåter kedja av flera nästa förlängningshuvud.
GTP version 2
Det är också känt som evolved-GTP eller eGTP. GTPv2-C-rubriker innehåller följande fält:
| + | Bit 0-2 | 3 | 4 | 5-7 | 8-15 | 16-23 | 24-31 | |||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0 | Version | Piggybacking flagga (P) | TEID-flagga (T) | Reserv | Meddelandetyp | Meddelandets längd | ||||||||||||||||||||||||||
| 32 | TEID (endast närvarande om T=1) | |||||||||||||||||||||||||||||||
| 64 (32 om TEID inte finns) | Sekvensnummer | Reserv | ||||||||||||||||||||||||||||||
Det finns inget GTPv2-U-protokoll, GTP-U i LTE använder också GTPv1-U.
- Version
- Det är ett 3-bitarsfält. För GTPv2 har detta värdet 2.
- Piggybacking-flagga
- Om denna bit är satt till 1 så ska ett annat GTP-C-meddelande med sin egen rubrik finnas i slutet av det aktuella meddelandet. Det finns begränsningar för vilken typ av meddelande som kan piggybackas beroende på vad GTP-C-meddelandet på toppnivå är.
- TEID-flagga
- Om denna bit är satt till 1 kommer TEID-fältet att finnas mellan meddelandelängden och sekvensnumret. Alla meddelanden utom Echo och Echo Reply kräver att TEID är närvarande.
- Meddelandelängd
- Detta fält ska ange meddelandets längd i oktetter exklusive det obligatoriska för GTP-C-huvudet (de första 4 oktetter). TEID (om det finns) och sekvensnumret ska inkluderas i längdräkningen.
Anslutningsmekanismer
Förutom den gemensamma meddelandestrukturen finns det också en gemensam mekanism för att verifiera anslutning från ett GSN till ett annat GSN. Detta använder två meddelanden.
- ekoförfrågan
- eko svar
Så ofta som var 60:e sekund kan en GSN skicka en ekoförfrågan till varannan GSN som den har en aktiv anslutning till. Om den andra änden inte svarar kan den behandlas som nere och de aktiva anslutningarna till den kommer att raderas.
Bortsett från de två meddelanden som tidigare nämnts, finns det inga andra meddelanden som är gemensamma för alla GTP-varianter, vilket innebär att de för det mesta utgör tre helt separata protokoll.
GTP-C - GTP-kontroll
GTP-C-protokollet är kontrolldelen av GTP-standarden. När en abonnent begär en PDP-kontext , kommer SGSN att skicka ett skapa PDP-kontextbegäran GTP-C-meddelande till GGSN som ger detaljer om abonnentens begäran. GGSN kommer sedan att svara med ett skapa PDP-kontextsvar GTP-C-meddelande som antingen kommer att ge detaljer om PDP-kontexten som faktiskt är aktiverad eller kommer att indikera ett fel och ge en orsak till detta misslyckande. Detta är ett UDP-meddelande på port 2123.
eGTP -C (eller GTPv2-C)-protokollet är ansvarigt för att skapa, underhålla och ta bort tunnlar på flera Sx-gränssnitt. Den används för styrplanets vägledning, tunnelhantering och mobilitetshantering. Den kontrollerar också vidarebefordran av omplaceringsmeddelanden; SRNS-kontext och skapa framåtriktade tunnlar under inter LTE-överlämningar.
GTP-U - GTP-användardatatunnling
GTP-U är i själva verket ett relativt enkelt IP-baserat tunnlingsprotokoll som tillåter många tunnlar mellan varje uppsättning slutpunkter. När den används i UMTS kommer varje abonnent att ha en eller flera tunnlar, en för varje PDP-kontext som de har aktiv, såväl som eventuellt separata tunnlar för specifika anslutningar med olika krav på tjänstekvalitet.
De separata tunnlarna identifieras av en TEID (Tunnel Endpoint Identifier) i GTP-U-meddelandena, som bör vara ett dynamiskt allokerat slumptal. Om detta slumpmässiga nummer är av kryptografisk kvalitet, kommer det att ge ett mått av säkerhet mot vissa attacker. Trots det är kravet för 3GPP-standarden att all GTP-trafik, inklusive användardata, ska skickas inom säkra privata nätverk, inte direkt anslutna till Internet. Detta händer på UDP-port 2152.
GTPv1 -U- protokollet används för att utbyta användardata över GTP-tunnlar över Sx-gränssnitten. Ett IP-paket för en UE (användarändpunkt) är inkapslat i ett GTPv1-U-paket och tunnlas mellan P-GW och eNodeB för överföring med avseende på en UE över S1-U och S5/S8-gränssnitt.
GTP' - laddningsöverföring
GTP' - protokollet används för att överföra laddningsdata till Charging Gateway-funktionen. GTP' använder TCP/UDP-port 3386.
Inom GPRS-kärnnätet
GTP är det primära protokollet som används i GPRS-kärnnätet. Det är protokollet som tillåter slutanvändare av ett GSM- eller UMTS-nätverk att flytta från plats till plats samtidigt som de fortsätter att ansluta till Internet som från en plats vid GGSN. Den gör detta genom att överföra abonnentens data från abonnentens nuvarande SGSN till GGSN som hanterar abonnentens session. Tre former av GTP används av GPRS-kärnnätet.
- GTP-U för överföring av användardata i separerade tunnlar för varje PDP-kontext
- GTP-C av kontrollskäl, inklusive:
- installation och radering av PDP-kontexter
- verifiering av GSN-tillgänglighet
- uppdateringar; t.ex. när abonnenter flyttar från ett SGSN till ett annat.
- GTP' för överföring av laddningsdata från GSN:er till laddningsfunktionen.
GGSN och SGSN (gemensamt kända som GSN) lyssnar efter GTP-C-meddelanden på UDP-port 2123 och efter GTP-U-meddelanden på port 2152. Denna kommunikation sker inom ett enda nätverk eller kan, i fallet med internationell roaming, ske internationellt, förmodligen över en GPRS-roamingväxel (GRX).
Charging Gateway Function (CGF) lyssnar på GTP- meddelanden som skickas från GSN:erna på TCP/UDP-porten 3386. Kärnnätverket skickar laddningsinformation till CGF, typiskt inklusive PDP-kontextaktiveringstider och mängden data som slutanvändaren har överfört . Denna kommunikation som sker inom ett nätverk är dock mindre standardiserad och kan, beroende på leverantören och konfigurationsalternativ, använda proprietär kodning eller till och med ett helt proprietärt system.
Använd på IuPS-gränssnittet
GTP-U används på IuPS mellan GPRS-kärnnätet och RAN, men GTP-C-protokollet används inte. I detta fall används RANAP som ett kontrollprotokoll och upprättar GTP-U-tunnlar mellan SGSN och radionätverkskontrollern (RNC).
Protokollstapel
| Application Protocols |
| IP (användare) |
| GTP |
| UDP |
| IP |
| Layer 2 (t.ex. WAN eller Ethernet) |
|
GTP-U protokollstack |
GTP kan användas med UDP eller TCP . GTP version 1 används endast på UDP.
Från och med 2018 finns det tre versioner definierade, version 0, 1 och 2. Version 0 och version 1 skiljer sig avsevärt i struktur. I version 0 kombineras signaleringsprotokollet (protokollet som sätter upp tunnlarna genom att aktivera PDP-kontexten) med tunnlingsprotokollet på en port. Versioner 1 och 2 är vardera två protokoll, ett för kontroll (kallas GTP-C) och ett för användardatatunnling (kallat GTP-U). GTP version 2 skiljer sig från version 1 endast i GTP-C. Detta beror på att 3GPP definierar förbättringar av GTP-C för EPS i version 2 för att förbättra bärarhanteringen.
GTP-U används också för att transportera användardata från RNC till SGSN i UMTS-nätverk. Men i detta fall görs signalering med RANAP istället för GTP-C.
Historiska GTP-versioner
Den ursprungliga versionen av GTP (version 0) hade avsevärda skillnader från de nuvarande versionerna (version 1,2):
- tunnelidentifieringen var icke-slumpmässig;
- alternativ gavs för att transportera X.25 ;
- det fasta portnumret 3386 användes för alla funktioner (inte bara laddning som i GTPv1);
- TCP var tillåtet som ett transportalternativ istället för UDP, men stöd för detta var valfritt;
- prenumerationsrelaterade områden som servicekvalitet var mer begränsade.
Det icke-slumpmässiga TEID i version 0 representerade ett säkerhetsproblem om en angripare hade tillgång till någon roamingpartners nätverk, eller kunde hitta något annat sätt att fjärrsända paket till GPRS-stamnätet. Version 0 går ur bruk och ersätts av version 1 i nästan alla nätverk. Lyckligtvis tillåter dock användningen av olika portnummer enkel blockering av version 0 genom enkla IP-åtkomstlistor.
GTP-standardisering
GTP standardiserades ursprungligen inom ETSI (GSM-standard 09.60). Med skapandet av UMTS-standarderna flyttades detta över till 3GPP som från och med 2005 upprätthåller det som 3GPP-standard 29.060. GTP' använder samma meddelandeformat, men dess speciella användningsområden täcks av standard 32.295 tillsammans med de standardiserade formaten för laddningsdata som den överför.
Senare versioner av TS 29.060 fasar ut GTPv1/v0-samverkan så att det inte finns någon reserv i händelse av att GSN inte stöder den högre versionen.
GTPv2 (för utvecklade pakettjänster) gick i utkast i början av 2008 och släpptes i december samma år. GTPv2 erbjuder reserv till GTPv1 via den tidigare "Version Not Supported"-mekanismen men erbjuder uttryckligen inget stöd för reserv till GTPv0.
Se även
Anteckningar
- GSM-standard 09.60, ETSI, 1996–98, denna standard täcker den ursprungliga versionen 0 av GTP.
- 3GPP TS 29.060 V6.9.0 (2005-06) , 3rd Generation Partnership Project, 650 Route des Lucioles - Sophia Antipolis, Valbonne - FRANKRIKE, 2005–06. Detta är den primära standarden som definierar alla GTP-varianter för GTP version 1.
- 3GPP TS 32.295 V6.1.0 (2005-06) , 3rd Generation Partnership Project, 650 Route des Lucioles - Sophia Antipolis, Valbonne - FRANKRIKE, 2005–06. Denna standard omfattar användning av GTP för laddning.
- 3GPP TS 29.274 V8.1.0 (2009-03) , 3rd Generation Partnership Project, 650 Route des Lucioles - Sophia Antipolis, Valbonne - FRANKRIKE, 2009–03. GTPv2 för utvecklad GPRS.