GTP-U & GTP-C (S1-U, S5/S8, S11) in LTE 4G

Introduction

GTP is the tunnelling protocol that carries a subscriber's traffic across the Evolved Packet Core, and the signalling that manages those tunnels. It exists in two independent flavours: GTP-U (TS 29.281) on the user plane, which encapsulates and moves the actual data packets, and GTP-C / GTPv2-C (TS 29.274) on the control plane, which creates, modifies and deletes the tunnels and the session/bearer state behind them. Both run over UDP, but on different ports and with different message sets.

GTP is active across the whole EPS data lifecycle. When a UE attaches, GTP-C builds the tunnels (allocating TEIDs and agreeing QoS) so a default bearer exists; while the UE is connected, GTP-U carries every uplink and downlink packet between eNB, S-GW and P-GW; when the UE moves, GTP-C re-points the tunnels and GTP-U's End Marker keeps the switchover in order; when the UE detaches, GTP-C tears the tunnels down and frees the identifiers. Nothing in the EPC user plane happens without it.

It matters because the EPC deliberately does not route on the UE's own IP address. Instead it addresses traffic by tunnel, using a 32-bit TEID in each packet's header. Understanding GTP — the header fields, the TEID, and the control-plane messages that wire it all together — is what turns "the core" from a diagram of boxes into a concrete set of named, per-bearer pipes.

Why GTP is needed

Concretely, the core cannot route on the UE's own IP address — that address belongs to the external packet data network (the SGi side), not to the transport between core nodes, and the same UE address may even be reused across many bearers and PDN connections. GTP solves three problems at once. It separates identity from transport: the TEID restores the per-bearer identity that outer IP routing throws away. It enables mobility: when the UE moves, only the tunnel endpoint is re-pointed — the UE keeps its IP. And it keeps flows separate: because each bearer is its own tunnel, QoS and charging rules apply to exactly the right traffic, not to a blurred aggregate.

Why Tunnel At All

In the Evolved Packet Core (EPC), a UE's IP packets have to travel eNB → S-GW → P-GW and back, across transport nodes that may sit anywhere in the operator's network. The core cannot route on the UE's own IP address — that address belongs to the external packet data network (the SGi side), not to the transport between core nodes, and the same UE address may even be reused across many bearers and PDN connections. So instead the EPC tunnels: it takes the UE's packet, wraps it in an outer UDP/IP header plus a small GTP-U header, and ships that between two node addresses. The inner packet becomes opaque payload that the transport network happily forwards on its own routing.

Because the two planes are fully separate protocols — different specs, different UDP ports, different message sets — it is worth pinning down how they differ before looking at either in detail. They share only the tunnelling idea and, on S5/S8, the interface name.

GTP-U — The User Plane (TS 29.281)

GTP-U is the workhorse that carries user IP packets across the EPC. Each user packet is encapsulated as a stack: an outer IP header (source and destination = the two node addresses) → UDP (destination port 2152) → a GTP-U header → then the original user packet as payload. The most important field in that GTP-U header is the TEID, a 32-bit value the receiving endpoint uses to look up the exact EPS bearer the packet belongs to.

Inside the GTP-U header

The GTP-U header is a fixed 8 octets, optionally followed by a 4-octet optional block. It begins with a flags octet: 3-bit Version = 1, a PT (Protocol Type) bit = 1 for GTP (0 would mean the older GTP’), one spare bit, then the E (extension-header present), S (sequence number present) and PN (N-PDU number present) flags. Next comes the Message Type (1 octet), a 16-bit Length (the number of octets after the mandatory 8-byte header, so it includes the optional block and payload), and the 32-bit TEID. If any of E, S or PN is set, the 4-octet optional block is present: a 16-bit Sequence Number, an 8-bit N-PDU Number, and an 8-bit Next Extension Header Type.

Beyond ordinary data transport, GTP-U defines a small set of its own messages — the ones you must recognise are below.

GTP-U runs on three key EPS interfaces:

• S1-U — between the eNB and the S-GW. This is the radio-facing user-plane tunnel, one segment per bearer per direction.
• S5/S8 — between the S-GW and the P-GW (S5 when both are in the same PLMN, S8 in roaming across PLMNs). This is the core-facing user-plane tunnel.
• X2-U — between two eNBs, used to forward buffered and in-flight downlink data from the source to the target eNB during handover so packets aren't lost while the UE moves.

GTP-C v2 — The Control Plane (TS 29.274)

Before any user packet can flow, someone has to build the tunnels — allocate the TEIDs, agree the QoS, and tell each node the peer's address. That's the job of GTP-C (GTPv2-C). It also runs over UDP, but on port 2123, and it manages sessions and bearers over their whole lifetime: setup, modification (when the UE moves, or a dedicated bearer is added), and teardown.

Inside the GTP-C v2 header and its IEs

GTP-C is a transaction protocol: every Request has a matching Response, correlated by a Sequence Number, and guarded by a retransmission timer (the T3 timer with N3 retries) so a lost message is re-sent rather than silently dropping a session. Its header carries a version (2), the P (piggyback) and T (TEID present) flags, the Message Type, a 16-bit Length, the 32-bit TEID (present for all messages except the initial Create Session Request and Echo, where the receiver's control-plane TEID is not yet known and the field is omitted), a 24-bit Sequence Number, and a spare octet.

Every parameter in a GTP-C message is a typed Information Element (IE) in TLV form: an 8-bit Type, a 16-bit Length, an Instance nibble (which lets several IEs of the same type appear and be told apart — e.g. multiple F-TEIDs or Bearer Contexts in one message), then the value. IEs can be grouped: a Bearer Context IE, for instance, nests an EPS Bearer ID (EBI), the bearer-level F-TEIDs, and the bearer QoS inside it. The central IE to know is the F-TEID (Fully-Qualified TEID): it bundles the TEID, the endpoint IPv4/IPv6 address, and an Interface Type code (e.g. S1-U eNB, S1-U S-GW, S5/S8 S-GW GTP-U, S5/S8 P-GW GTP-U, S11 MME) — so a single IE tells the peer where to send, which tunnel to stamp, and on which interface.

The core session-management messages are:

GTP-C runs on:

• S11 — between the MME and the S-GW. The MME never touches user data; it drives the S-GW over S11 to build tunnels on the UE's behalf.
• S5/S8 — the control-plane side, between the S-GW and P-GW, alongside the user-plane GTP-U on the same interface name.
• S10 — between two MMEs, used to transfer UE context (Forward Relocation Request/Response) during MME relocation in inter-MME mobility.

How a Bearer Maps to Tunnels — End to End

The single most useful thing to internalise is the chain of identifiers that stitch one EPS bearer together across the whole path. On the radio it is a DRB (Data Radio Bearer); on S1-U it is a pair of TEIDs; on S5/S8 it is another pair. These are separate tunnels — the packet is de-encapsulated and re-encapsulated at each node — but they are all bound to the same EPS bearer (identified end to end by its EPS Bearer ID), and control-plane signalling is what glued them together.

Follow a downlink packet to see the chain in action — a video frame arriving from the internet for your phone. It reaches the P-GW on the SGi interface (the boundary to the external network), and the P-GW must get it to the right eNB, which will send it over the air. 1. The P-GW matches the packet to the UE's EPS bearer via its packet filters (the downlink TFT) and encapsulates it in GTP-U, stamping the downlink TEID the S-GW gave it and addressing the outer IP to the S-GW. 2. It travels over S5/S8. 3. The S-GW reads that TEID, looks up the bearer, strips the wrapper and re-encapsulates with the eNB's downlink TEID, sending it over S1-U. 4. The eNB reads that TEID, maps it to the matching DRB, strips the GTP-U/UDP/IP wrapping, and schedules the inner packet over the air. Uplink is the mirror image, keyed by the uplink TEIDs.

The crucial observation is in the diagram below: the inner user IP packet is byte-for-byte identical on every segment. Only the outer IP/UDP/GTP-U wrapper — and specifically the TEID — is rewritten at each node.

End Marker — Path Switch at Handover

Handover is where GTP-U's tidiness earns its keep. When a UE moves from a source eNB to a target eNB, the S1-U downlink tunnel has to be re-pointed from the old eNB to the new one. But packets are already in flight, and in-order delivery matters. The End Marker message (GTP-U type 254) is how the network draws a clean line between the old path and the new one.

In an X2-based handover, the source eNB starts forwarding buffered and freshly arriving downlink data to the target eNB over the X2-U tunnel, so nothing is lost while the UE completes the radio switch. Meanwhile the target eNB signals the MME, which sends a Modify Bearer Request over S11 so the S-GW updates the S1-U downlink TEID/address to the target eNB — this is the path switch. At the moment the S-GW switches the downlink path, it sends one or more End Marker packets down the old S1-U tunnel (to the source eNB). The source eNB forwards those End Markers to the target over X2-U as the last thing on the forwarding tunnel.

The same principle applies to S1-based handover and to S-GW relocation: the source-side node emits an End Marker on the old GTP-U path so the target knows it is drained. Because it is an ordinary GTP-U message on the same tunnel as the data, it arrives strictly after all preceding data — that ordering guarantee is the whole point. An Error Indication is the ungraceful counterpart: if a packet shows up for a TEID the receiver has already released, it replies with one to make the sender stop.

Interface, Variant and Endpoints — At a Glance

The same interface name can carry both variants (S5/S8 carries user data and control), so it helps to see them side by side. Note that the S1-MME interface between eNB and MME is not GTP at all — it uses S1AP over SCTP — a common point of confusion, since it sits right next to the GTP interfaces.

Summary

GTP is how the EPC carries and manages user traffic without routing on the UE's IP. Two separate protocols share only the tunnelling idea: GTP-U (TS 29.281, UDP 2152) encapsulates each user packet with a TEID and moves it on S1-U, S5/S8 and X2-U; GTP-C / GTPv2-C (TS 29.274, UDP 2123) builds, modifies and tears down those tunnels on S11, S5/S8 and S10, carrying its parameters as typed IEs and wiring the user plane together with F-TEIDs.

The TEID is the one idea to keep: a 32-bit name, local to the receiving node, that maps an arriving packet to exactly one EPS bearer. One bearer is realised as a chain of distinct tunnels — radio DRB, S1-U pair, S5/S8 pair — each re-encapsulated at every node, with only the outer wrapper (and its TEID) rewritten per hop while the inner user packet stays identical. Handover keeps this orderly with the End Marker, and Error Indication is the ungraceful signal for a stale tunnel.

In 5G the user-plane half survives almost intact — GTP-U with a QFI-carrying extension header on N3/N9 — while the control-plane half is replaced by PFCP and the service-based interfaces. Learn the LTE TEID and F-TEID model and the 5G user plane is largely familiar.

Quick Q&A