3GPP TS 29.281
General Packet Radio System (GPRS) Tunnelling Protocol User Plane (GTPv1-U)
V18.6.0 (2024-09) — Release 18 Protocol Specification 1. Scope
▶Specifies the GTP-U protocol for user plane tunnelling between GTP-U entities such as gNBs, UPFs, SGWs, PGWs, ePDGs, and TWAGs. GTP-U carries user IP packets (G-PDUs) encapsulated within GTP tunnels identified by Tunnel Endpoint Identifiers (TEIDs).
Key Point: GTP-U is the actual data plane tunnel — every user packet traversing N3 (gNB↔UPF), N9 (UPF↔UPF), S1-U, S5/S8, and X2/Xn carries this header. This is the protocol that TS 33.513 (UPF SCAS) tests for filtering and validation.
Transport: GTP-U runs over UDP port 2152 by default. The UDP/IP layer provides the transport; GTP-U adds tunnel identification and optional extension headers on top.
2. References
▶| Reference | Title | Relevance |
|---|---|---|
| TS 29.274 | GTPv2-C (Control Plane) | Establishes tunnels that GTP-U carries data for |
| TS 29.244 | PFCP (Sx/N4) | Controls UPF forwarding rules for GTP-U tunnels |
| RFC 768 | User Datagram Protocol | Transport layer for GTP-U |
| TS 33.210 | NDS/IP | IPsec protection of GTP-U interfaces |
| TS 23.501 | 5GS Architecture | Defines N3/N9 interface where GTP-U runs |
| TS 38.415 | PDU Session User Plane Protocol | Defines PDU Session Container extension header |
4. GTP-U Overview
▶4.1 Protocol Stack
▶
┌─────────────────────────────────────────────────────────────────────┐
│ User IP Packet (G-PDU) │
├─────────────────────────────────────────────────────────────────────┤
│ GTP-U Header (8+ bytes) │
│ ┌──────┬──────┬───────┬──────┬───────────────────────────────────┐ │
│ │Flags │ Type │Length │ TEID │ Seq# / N-PDU# / Ext Hdr (opt) │ │
│ │1 byte│1 byte│2 bytes│4 byte│ variable │ │
│ └──────┴──────┴───────┴──────┴───────────────────────────────────┘ │
├─────────────────────────────────────────────────────────────────────┤
│ UDP (port 2152) │
├─────────────────────────────────────────────────────────────────────┤
│ IP (v4 or v6) │
├─────────────────────────────────────────────────────────────────────┤
│ L2 (Ethernet / VLAN) │
└─────────────────────────────────────────────────────────────────────┘
5G Deployment:
UE ─── (air) ──► gNB ════════ N3 (GTP-U) ════════► UPF ──── N6 ──► DN
│
N9 (GTP-U)
│
UPF (I-UPF/PSA)
═══ = GTP-U tunnel (UDP 2152)
─── = native IP
Interfaces carrying GTP-U:
| Interface | Endpoints | Generation | Security Reference |
|---|---|---|---|
| N3 | gNB ↔ UPF | 5G | TS 33.513, TS 33.512 |
| N9 | UPF ↔ UPF (inter) | 5G | TS 33.513 |
| Xn-U | gNB ↔ gNB | 5G | TS 33.512 |
| S1-U | eNB ↔ SGW | 4G | TS 33.401 |
| S5/S8 | SGW ↔ PGW | 4G | TS 33.210 |
| S2a/S2b | ePDG/TWAG ↔ PGW | 4G WiFi | TS 33.402 |
4.2 Tunnel Management Concepts
▶A GTP-U tunnel is a unidirectional point-to-point tunnel defined by a pair of (TEID, IP address) at each endpoint. For bidirectional user data, two tunnels (one per direction) are established.
- TEID: 32-bit Tunnel Endpoint Identifier — locally unique at receiving endpoint
- Path: An ordered pair of (source IP, dest IP) — one path may carry multiple tunnels
- Tunnel lifecycle: Created by signaling (GTPv2-C or PFCP), maintained by path management, destroyed on release
Security Note: TEID values are allocated by signaling, but GTP-U itself performs no authentication. Any packet with a valid TEID reaching UDP 2152 will be accepted unless external filtering (IPsec, firewall rules) is applied. This is the core issue tested by TS 33.513 TC_UPF_GTP_FILTER.
5. GTP-U Header Format
▶5.1 Mandatory Header Fields
▶
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver|P|R|E|S|PN| Message Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TEID (Tunnel Endpoint Identifier) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number | N-PDU Number |Next Ext Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field | Bits | Description |
|---|---|---|
| Version | 3 | Must be 1 (GTPv1) |
| PT (Protocol Type) | 1 | 1 = GTP (user data); 0 = GTP' (charging) |
| R (Reserved) | 1 | Must be 0 |
| E (Extension Header) | 1 | 1 = Extension header follows |
| S (Sequence Number) | 1 | 1 = Sequence number field present |
| PN (N-PDU Number) | 1 | 1 = N-PDU number field present |
| Message Type | 8 | See §6 — 0xFF = G-PDU (user data) |
| Length | 16 | Payload length (excludes mandatory 8-byte header) |
| TEID | 32 | Tunnel Endpoint Identifier — identifies the tunnel at the receiving side |
TEID = 0: Reserved for path management messages (Echo Request/Response). Data packets with TEID=0 are invalid and should be dropped — this is a key validation check in TS 33.513 testing.
5.2 Extension Headers
▶When the E flag is set, a chain of extension headers follows the mandatory header. Each extension header contains a "Next Extension Header Type" field enabling chaining.
| Type Value | Extension Header | Usage |
|---|---|---|
0x00 | No more extension headers | Chain terminator |
0x01 | Reserved (Control Plane Only) | — |
0x02 | Reserved (Control Plane Only) | — |
0x20 | Service Class Indicator | QoS marking in UTRAN |
0x40 | UDP Port | Source port of triggering packet for NAT traversal |
0x81 | RAN Container | Inter-RAT info (LTE ↔ NR handover) |
0x82 | Long PDCP PDU Number | 18-bit PDCP SN for high-throughput bearers |
0x83 | Xw RAN Container | WT (WiFi termination) info |
0x84 | NR RAN Container | NR-specific info (DL/UL user data report) |
0x85 | PDU Session Container | 5G critical: carries QFI, reflective QoS, PPP/RQI — see §9.1 |
0x86 | PDCP PDU Number | SN for lossless PDCP in handover |
Extension Header Type 0x85 (PDU Session Container) is the single most important extension header for 5G. It carries QoS Flow Identifier (QFI) and enables per-flow treatment at the UPF. Defined in detail in TS 38.415.
6. Message Types
▶| Type | Value | Direction | TEID |
|---|---|---|---|
| Echo Request | 1 | Both | 0 (always) |
| Echo Response | 2 | Both | 0 (always) |
| Error Indication | 26 | Receiver → Sender | 0 |
| Supported Extension Headers Notification | 31 | Both | 0 |
| End Marker | 254 | Source → Target | Tunnel TEID |
| G-PDU | 255 (0xFF) | Both | Tunnel TEID |
6.1 Echo Request / Response
▶Path management messages sent with TEID = 0. Echo Request probes GTP-U path liveness; the Echo Response must include a Recovery IE to detect path restarts.
- Sent periodically (configurable interval, typically 60s)
- No response → path failure → all tunnels on path are considered failed
- Recovery IE counter change → peer has restarted → tunnels must be re-established via signaling
Security: Echo messages are unauthenticated. An attacker sending spoofed Echo Requests/Responses can trigger false path failures or mask actual failures. IPsec on the GTP-U path mitigates this.
6.2 Error Indication
▶Sent when a GTP-U entity receives a G-PDU for a non-existent TEID. Contains:
- The TEID from the offending G-PDU
- The peer address that sent the G-PDU
Upon receiving an Error Indication, the originating entity should trigger signaling (GTPv2-C or PFCP) to release or re-establish the tunnel.
Security: Spoofed Error Indications can trick a node into tearing down valid tunnels — a denial-of-service vector. Rate-limiting Error Indication processing and correlating with signaling state mitigates this.
6.3 End Marker
▶Sent during handover to signal the last packet on the old path. The source node sends an End Marker on the old tunnel after switching to the new tunnel. This enables the target node to flush remaining packets and deliver them in order.
- Carries the TEID of the old tunnel
- Must be forwarded through intermediate UPFs
- Critical for lossless handover procedures
6.4 G-PDU (Type 255)
▶The primary message type — carries the actual user data. The T-PDU (user IP packet) is encapsulated as the GTP-U payload.
Outer IP Header → UDP (2152) → GTP-U Header (Type=0xFF, TEID) → [Ext Hdrs] → Inner IP Packet
Example N3 downlink packet:
┌──────────────────────────────────────────────────────────────────┐
│ Outer IPv4: src=UPF_IP dst=gNB_IP │
│ UDP: src=2152 dst=2152 │
│ GTP-U: Ver=1 PT=1 E=1 Type=0xFF TEID=0x12345678 Len=... │
│ ExtHdr: Type=0x85 (PDU Session Container) QFI=9 │
│ ┌──────────────────────────────────────────────────────────────┐│
│ │ Inner IPv4: src=DN_server dst=UE_IP ││
│ │ TCP: src=443 dst=54321 [TLS Application Data] ││
│ └──────────────────────────────────────────────────────────────┘│
└──────────────────────────────────────────────────────────────────┘
GTP-in-GTP: If the inner packet is itself a GTP-U packet (e.g., from a rogue UE), a UPF must detect and drop it to prevent tunnel-in-tunnel attacks. This is the GTP-in-GTP check tested in TS 33.513 TC_UPF_GTP_FILTER.
7. TEID Management
▶TEID values are 32-bit unsigned integers allocated by the receiving entity and communicated to the sender via signaling:
- 5G (N3/N9): TEID allocated by UPF, communicated to gNB via PFCP → SMF → AMF → gNB (N2)
- 4G (S1-U/S5): TEID allocated in GTPv2-C Create Session Response / Create Bearer Response
- TEID = 0: Reserved for path management (Echo/Error) — never used for G-PDUs
| Property | Requirement |
|---|---|
| Uniqueness | Locally unique at the receiving node; globally unique per (TEID, IP) pair |
| Allocation | Implementation-specific — sequential, random, or hash-based |
| Lifetime | Valid from tunnel creation until explicit release or path failure |
| Reuse | Should avoid immediate reuse to prevent late-arriving packets being misdelivered |
TR 33.926 §5.3.6.15 TEID spoofing enables GTP traffic injection ▶
TEID Prediction Attack: If TEIDs are allocated sequentially, an attacker who learns one TEID can predict others and inject packets into neighboring tunnels. Randomized TEID allocation is a recommended mitigation.
8. Path Management
▶GTP-U path management detects failures and restarts of GTP-U peers. It operates independently of signaling.
| Mechanism | Message | Trigger | Action on Failure |
|---|---|---|---|
| Path Liveness | Echo Request / Response | Periodic timer (T3-RESPONSE) or packet loss | Mark path as failed; notify signaling layer |
| Peer Restart | Recovery IE in Echo Response | Recovery counter mismatch | Delete all tunnels on path; re-establish via signaling |
| Unknown TEID | Error Indication | G-PDU for non-existent TEID | Notify signaling; release/re-establish affected bearer |
Timer values: T3-RESPONSE default = 1 second, N3-REQUESTS = 5 retries. Missing all retries → path failure.
9. 5G-Specific Extensions
▶9.1 PDU Session Container (ExtHdr 0x85)
▶Defined in TS 38.415, this extension header is mandatory on N3 and N9 in 5G. It carries:
PDU Session Container (DL):
┌────────────────────────────────────────┐
│ PDU Type: 0 (DL) │
│ QFI (6 bits): QoS Flow Identifier │
│ RQI (1 bit): Reflective QoS Indication │
│ PPP (1 bit): Paging Policy Indicator │
│ PPI (3 bits): Paging Policy Index │
│ Padding │
└────────────────────────────────────────┘
PDU Session Container (UL):
┌────────────────────────────────────────┐
│ PDU Type: 1 (UL) │
│ QFI (6 bits): QoS Flow Identifier │
│ DL Sending Time Stamp (opt) │
│ DL QFI Sequence Number (opt) │
│ DL Delay Result (opt) │
│ UL QFI Sequence Number (opt) │
└────────────────────────────────────────┘
| Field | Bits | Description |
|---|---|---|
| PDU Type | 4 | 0=DL PDU Session Info, 1=UL PDU Session Info |
| QFI | 6 | QoS Flow Identifier (0-63); maps to 5QI in PCF policy |
| RQI | 1 | Reflective QoS Indication — tells UE to create derived QoS rule |
| PPP | 1 | Paging Policy Presence — indicates PPI field is present |
9.2 QoS Flow Identifier (QFI)
▶In 5G, QoS is managed at the flow level (not bearer level as in 4G). The QFI in the PDU Session Container maps each packet to a QoS flow:
- QFI range: 0–63 (6 bits)
- QFI → 5QI mapping defined by SMF via PFCP rules
- UPF applies per-QFI treatment: rate limiting, priority, scheduling
- gNB maps QFI to DRB (Data Radio Bearer) for air interface QoS
Security: QFI manipulation in uplink could allow a UE to obtain higher QoS than authorized. The UPF must validate uplink QFI values against the PDU session's authorized QoS flows (from PFCP rules).
10. Security Considerations
▶ GTP-U has no built-in security. The protocol provides no authentication, integrity, or confidentiality protection. Security must be provided by external mechanisms.
TR 33.926 §5.3.6.15 GTP traffic isolation failure ▶
TR 33.926 §5.3.3.5 IP source address spoofing ▶
TR 33.926 §5.3.2 Passive eavesdropping on GTP-U tunnels ▶
TR 33.926 §5.3.4 Denial of service via GTP-U flooding ▶
Known Attack Vectors
| Attack | Technique | Impact | Mitigation |
|---|---|---|---|
| TEID Hijacking | Predict or sniff TEID, inject packets with that TEID | Traffic injection into victim session | Randomize TEIDs, IPsec, source IP filtering |
| GTP-in-GTP | Send GTP-U packet as inner T-PDU from UE | Tunnel escape, access to other subscribers | Deep packet inspection at UPF (drop inner GTP) |
| Echo Spoofing | Send spoofed Echo Response with wrong Recovery IE | False restart detection → all tunnels torn down | IPsec, rate-limit Echo processing |
| Error Indication Spoofing | Send spoofed Error Indication for valid TEID | Tunnel teardown → subscriber service disruption | IPsec, correlate with signaling state |
| QFI Manipulation | UE sends UL packets with unauthorized QFI value | Obtain premium QoS without authorization | UPF QFI validation against PFCP rules |
| Bandwidth Flooding | Massive G-PDU volume on N3 from compromised gNB | UPF overload, subscriber impact | Rate limiting per tunnel, traffic policing, overload controls |
Required Security Measures
| Measure | Spec Reference | Applicability |
|---|---|---|
| IPsec ESP (tunnel mode) on N3 | TS 33.210, TS 33.501 §9.3 | Mandatory when gNB not physically secured |
| IPsec ESP on N9 | TS 33.501 §9.9 | Mandatory for inter-PLMN; recommended intra |
| GTP-U filtering at UPF | TS 33.513, TS 33.117 §4.2.6 | Mandatory — TEID validation, source IP, GTP-in-GTP |
| TEID randomization | TS 33.117 | Recommended — prevent TEID prediction |
| UP integrity protection (NIA) | TS 33.501 §6.6 | Optional per PDU session; mandatory capable |
| UP confidentiality (NEA) | TS 33.501 §6.6 | Optional per PDU session |