If you’re using an GSM / GPRS, UMTS, LTE or NR network, there’s a good chance all your data to and from the terminal is encapsulated in GTP.
GTP encapsulates user’s data into a GTP PDU / packet that can be redirected easily. This means as users of the network roam around from one part of the network to another, the destination IP of the GTP tunnel just needs to be updated, but the user’s IP address doesn’t change for the duration of their session as the user’s data is in the GTP payload.
One thing that’s a bit confusing is the TIED – Tunnel Endpoint Identifier.
Each tunnel has a sender TIED and transmitter TIED pair, as setup in the Create Session Request / Create Session Response, but in our GTP packet we only see one TIED.
There’s not much to a GTP-U header; at 8 bytes in all it’s pretty lightweight. Flags, message type and length are all pretty self explanatory. There’s an optional sequence number, the TIED value and the payload itself.
So the TIED identifies the tunnel, but it’s worth keeping in mind that the TIED only identifies a data flow from one Network Element to another, for example eNB to S-GW would have one TIED, while S-GW to P-GW would have another TIED.
Each tunnel has two TIEDs, a sending TIED and a receiving TIED. For some reason (Minimise overhead on backhaul maybe?) only the sender TIED is included in the GTP header;
This means a packet that’s coming from a mobile / UE will have one TIED, while a packet that’s going to the same mobile / UE will have a different TIED.
Mapping out TIEDs is typically done by looking at the Create Session Request / Responses, the Create Session Request will have one TIED, while the Create Session Response will have a different TIED, thus giving you your TIED pair.