2022 Mobile Core and IMS · intermediate

GTP-C and GTP-U Finally Separated Control from Subscriber Traffic

GTP made more sense once I stopped treating it as one protocol and separated tunnel-control signalling from the packets that actually carry user traffic.

Lab Note. Reconstructed in 2026 as a technical lab note from the 2022 mobile-core and IMS study period. The archive date indicates the period covered; the current site publication date is shown separately.

GTP was one of those protocol names I understood only at diagram level until I captured both control and user traffic. The important distinction is between GTP-C, which manages tunnel and bearer state, and GTP-U, which carries the subscriber's user-plane packets. Once I treated those as separate jobs, EPC packet flow became much easier to follow.

During session establishment, control-plane nodes exchange information that creates the forwarding state needed by the gateways. Tunnel Endpoint Identifiers are part of that state. A TEID is not a subscriber IP address and it is not a port number; it identifies a GTP tunnel context on a particular interface. The same subscriber can therefore have ordinary IP addressing at one layer while GTP adds another addressing context around the packet inside the mobile network.

The user-plane capture made the encapsulation concrete. An IP packet generated by the UE can appear inside a GTP-U packet between the access and gateway functions. The outer IP header belongs to the transport network carrying the tunnel. The inner packet belongs to the subscriber session. Looking at only the outer addresses can therefore hide which subscriber packet is actually being forwarded.

This also changed how I diagnosed no-data problems. If attach and bearer creation succeeded but the subscriber could not reach the data network, I stopped assuming the entire core had failed. I checked whether GTP-C had created the expected state, whether GTP-U packets were arriving at the user-plane function, whether the TEIDs matched the installed session, and whether the inner packet had a valid route beyond the packet gateway.

Packet capture placement matters here. A capture near the UE-facing side of the user plane shows encapsulated traffic. A capture after decapsulation may show ordinary IP packets. Seeing one and not the other narrows the failure domain. That is much more useful than testing only from the UE and concluding that mobile data is down.

The broader lesson was familiar from SIP and RTP: signalling that creates a session and traffic that uses the session are different things. A successful control-plane exchange does not prove that user traffic is flowing. GTP simply applies that separation at mobile-core scale, with tunnels and bearer state connecting the two planes.

Quick navigationEsc