GTP-U (User-Plane Transport) in 5G NR

Introduction

GTP-U (GPRS Tunnelling Protocol, user-plane part) is the protocol that actually moves your data across the 5G user plane. It is not a radio protocol and not a core-network signalling protocol — it is a transport-level tunnel that sits on top of plain UDP/IP and carries a UE's traffic between two user-plane nodes as if there were a private pipe between them. Whenever you open a web page over 5G, every packet in both directions spends part of its life encapsulated inside GTP-U.

In the UE/network lifecycle GTP-U comes into play the moment a PDU session is established. The control plane (NGAP on N2, session management via the SMF) negotiates the tunnel endpoints and their identities; from then on, user data flows through GTP-U tunnels between the gNB and the UPF on N3, inside a split gNB on F1-U, and briefly between gNBs on Xn-U during handover. The tunnel lives as long as the session (or the bearer) does.

It matters because GTP-U is where 5G's promises about reachability and quality of service become bytes on a wire. The tunnel identity (TEID) is what guarantees a packet lands in the right session at the right node; the QoS marking (QFI) is what guarantees that packet gets the treatment it was provisioned for, even though the routers in between are completely QoS-agnostic. Understand GTP-U and you understand how the user plane keeps its promises across an ordinary IP backhaul.

Why GTP-U is needed

The concrete problem GTP-U solves is that a UE's packet cannot simply be routed across the operator's backhaul on its own. The backhaul is a general-purpose IP network whose routers are addressed to the transport nodes, not to individual UEs; they have no notion of PDU sessions, radio bearers, or 5G QoS flows. If you handed them the UE's raw IP packet they would not know which session it belonged to, which QoS it deserved, or even that it was mobile-subscriber traffic at all.

GTP-U fixes this with encapsulation. The tunnel endpoint wraps the UE's packet in a new outer packet addressed to the peer endpoint's transport IP, and into the wrapper it writes the two things the transport cannot preserve on its own: a TEID so the receiver knows exactly which tunnel context (session, UE, direction) the packet belongs to, and, on N3, a QFI so the receiver knows which QoS flow to give it. Everything the RAN and core need travels inside the wrapper, so the transport can stay simple and QoS-agnostic while 5G still delivers differentiated, per-session treatment end to end.

What GTP-U Is and Why It Exists

GTP-U — the GPRS Tunnelling Protocol, user-plane part — is a tunnelling protocol that runs between two user-plane endpoints and carries user data packets between them. The name is a leftover from GPRS/EPC, but the 5G core and NR RAN reuse the same protocol almost unchanged, adding one new extension header for QoS. In 5G you find GTP-U on three interfaces: N3 between the gNB and the UPF, F1-U between the DU and the CU-UP inside a split gNB, and Xn-U for data forwarding between gNBs during handover.

The core idea is encapsulation. The UE's real packet — whatever it is, an HTTPS request, a video frame, a DNS query — becomes the payload of a brand-new packet. That new packet's destination is not the UE and not the far-end server; it is the transport address of the tunnel's other end (the UPF's N3 address in the uplink, the gNB's N3 address in the downlink). The routers in between forward it like any other UDP datagram. Only at the tunnel endpoints is the outer wrapper removed and the inner packet recovered. This is why the transport network can be a plain, QoS-agnostic IP fabric and still deliver 5G's differentiated treatment: everything the RAN and core need to know travels inside the GTP-U header, not in the routers.

Encapsulation over UDP/IP

Before looking at individual header fields, it helps to see the full stack of headers wrapped around one user packet on N3. Reading from the outside in: an outer IP header (transport addresses of the two tunnel endpoints), a UDP header with destination port 2152, the GTP-U header carrying the TEID, an optional PDU Session Container extension header carrying the QFI, and finally the original UE packet as payload.

Two consequences fall out of this picture. First, the transport MTU has to allow for the added overhead — roughly 8 bytes of GTP-U, 4 or more for the extension header, 8 for UDP and 20/40 for outer IP — which is why operators size N3/F1-U links with jumbo frames or configure fragmentation carefully. Second, because the inner packet is opaque payload, the transport cannot read or act on the UE's own DSCP; any differentiation the transport applies must be driven from the outer header, typically by the endpoint copying a DSCP derived from the QFI onto the outer IP header.

The GTP-U Header

Every GTP-U packet begins with a mandatory 8-byte header, optionally followed by a sequence number, an N-PDU number, and one or more extension headers. The fields that matter day to day:

The TEID is the heart of the protocol. It is not a globally unique identifier and it carries no structure the receiver has to parse — it is simply an index the receiver handed out at setup so that, when a packet arrives, a single lookup on the TEID resolves the full context: which PDU session, which UE, which peer, and what to do next. Because the receiver picks it, the two ends of a tunnel almost always use different TEID values, and the same session's uplink and downlink use different values again. When a packet arrives for a TEID the receiver has never allocated (or has since released), the receiver cannot process it — and that condition is exactly what triggers an Error Indication, described below.

The extension header mechanism is a small chained list. When the E flag is set, the mandatory header is followed by a Next Extension Header Type byte; each extension header ends with its own Next Extension Header Type, and a value of 0 terminates the chain. This chaining is how 3GPP added the 5G QoS container without changing the base header format — older nodes that don't understand a given extension header type are told, by a two-bit comprehension-required flag in the type value, whether they may skip it or must discard the packet.

Message Types and Path Management

Although GTP-U's main job is carrying data (the G-PDU), it also carries a handful of control messages that manage the tunnels and the path itself, so no separate signalling protocol is needed on the user plane.

The G-PDU is the workhorse: Message Type = 255, and its payload is the UE's original packet. The receiver reads the TEID, finds the tunnel context, strips the GTP-U/UDP/IP encapsulation, reads the QFI from the extension header, and hands the inner packet on. Everything else in the table is control plumbing.

• Echo Request / Echo Response — a keepalive between two GTP-U peers. A node periodically sends an Echo Request to each peer it has tunnels with; if a series go unanswered, the path is declared down and the affected tunnels are torn down. The Echo Response carries a Recovery IE holding a restart counter: if a peer reboots and comes back with a higher counter, the receiver learns that all contexts on that peer were lost and cleans up its stale tunnels. This is the primary path management mechanism.
• Error Indication — sent when a G-PDU arrives with a TEID that has no matching context at the receiver, typically because the bearer or session was released while the sender kept transmitting. It carries the offending TEID (in the Tunnel Endpoint Identifier Data I IE) and the receiver's address, so the sender can immediately stop transmitting on that dead tunnel rather than waiting for a timeout.
• End Marker — sent on the old downlink path at a path switch (for example, when a handover moves a UE from a source gNB to a target gNB, or when the UPF's N3 tunnel is redirected). It is the last thing sent on the old tunnel and tells the receiver "no more data will come this way," so the receiver knows in-order forwarding on the old path is complete and can switch cleanly to the new path without either losing packets or waiting indefinitely for more.

The PDU Session Container — Carrying QoS (TS 38.415)

The transport network is a plain IP backhaul; it does not understand 5G QoS flows. To keep QoS end to end, 5G defines a GTP-U extension header called the PDU Session Container, also known as the NR RAN Container, specified in TS 38.415. It is inserted into the GTP-U header on N3 (and used analogously on Xn-U during forwarding) and carries the per-packet QoS information the RAN and core need.

The QFI is the single most important field here. In 5G's QoS model, traffic is grouped into QoS flows, each identified by a QFI, and it is the finest granularity of QoS that the 5G system enforces end to end. On the downlink, the UPF classifies each incoming packet against its service-data-flow filters, decides which QoS flow it belongs to, and writes that flow's QFI into the PDU Session Container. On the uplink, the UE marks packets with the QFI (per its QoS rules) and the gNB copies it into the container toward the UPF, so the core can verify and police the flow.

The RQI supports reflective QoS: rather than signalling an uplink QoS rule to the UE explicitly, the network sets the RQI on downlink packets of a flow, and the UE infers "send my matching uplink traffic on this same flow." It is a bandwidth-saving shortcut for flows whose uplink treatment can mirror the downlink.

Where GTP-U Is Used: N3, F1-U, Xn-U

The same protocol appears on three different interfaces in the 5G user plane, each with its own pair of endpoints and its own reason for tunnelling. What changes is who owns the TEIDs and what, if anything, rides on top of GTP-U.

On N3 the tunnel exists per PDU session and the QoS granularity is the QFI. Inside a split gNB, F1-U tunnels exist per DRB, and on top of GTP-U runs the NR User Plane Protocol (TS 38.425), which adds downlink data-delivery status and flow-control feedback so the CU-UP knows how fast the DU can drain its buffers. Xn-U is transient: it appears only during a handover, carrying data the source gNB had already received for the UE but not yet delivered, forwarded to the target so nothing is lost across the move — and it is on this interface that the End Marker earns its keep.

A Downlink Packet, End to End

Putting the pieces together, here is what happens to a single downlink packet arriving from the data network, classified by the UPF and delivered to the UE by the gNB. It shows exactly where the QFI is set and where it is consumed.

Step by step: a packet arrives at the UPF from the data network. The UPF runs it through the packet detection / service-data-flow filters installed for that PDU session, which resolve the packet to one QoS flow. The UPF writes that flow's QFI into a PDU Session Container extension header, prepends the GTP-U header with the downlink TEID the gNB assigned at setup, wraps it in UDP:2152 and outer IP addressed to the gNB, and sends it across N3. The gNB receives it, uses the TEID to find the PDU-session context, reads the QFI, and consults its QFI-to-DRB mapping to decide which Data Radio Bearer carries this flow over the air. From there PDCP/RLC/MAC take over and the packet is scheduled to the UE. The uplink is the mirror image: the UE tags packets with a QFI per its QoS rules, the gNB relays them over N3 with the uplink TEID the UPF assigned, and the UPF polices each flow against its rules.

Summary

GTP-U is the user-plane tunnel that lets 5G data cross a QoS-agnostic IP backhaul without losing its session identity or its quality of service. It wraps each UE packet in outer IP + UDP:2152 + an 8-byte GTP-U header, and the fields that do the real work are the 32-bit receiver-assigned TEID (which tunnel context this packet belongs to) and, on N3, the QFI carried in the PDU Session Container extension header (TS 38.415) that names the QoS flow. Data rides as a G-PDU (type 255); a small set of control messages — Echo, Error Indication, End Marker — handle path keepalive, stale-tunnel cleanup, and clean path switches.

The same wrapper appears on three interfaces — N3 (gNB↔UPF, per session), F1-U (DU↔CU-UP, per DRB, with NR-UP flow control on top per TS 38.425), and Xn-U (gNB↔gNB, handover forwarding) — differing only in endpoints, granularity, and what layers above. Remember the two mappings that make QoS real: the UPF owns QFI↔service-data-flow and the gNB owns QFI↔DRB, and GTP-U simply carries the QFI intact between them.

Quick Q&A