Description
The G-PDU is a specific packet format defined within the GPRS Tunnelling Protocol (GTP) suite, standardized in 3GPP TS 29.281 for the GTP-U protocol and referenced in TS 29.274 for the control plane. It represents the encapsulated payload of user plane data that is tunneled between GTP-U endpoints, such as between an eNodeB/gNB and a Serving Gateway (SGW), or between gateways (SGW and PGW) in the Evolved Packet Core (EPC). The encapsulation process involves taking the original user data packet (e.g., an IP packet from a UE) and adding a GTP-U header and, typically, a UDP/IP transport layer header. The GTP-U header includes critical fields like a Tunnel Endpoint Identifier (TEID), which uniquely identifies the GTP tunnel for a specific user's bearer, sequence numbers for loss detection, and message type indicators. This structure allows multiple user data flows to be multiplexed over the same transport network connection, separated logically by their TEIDs.
In the network architecture, G-PDUs are the workhorse of the user plane, carrying the actual subscriber data. When a UE establishes a PDN connection or a PDU Session, one or more EPS bearers or QoS Flows are set up, each associated with a specific GTP tunnel identified by a TEID pair. As data packets arrive from the UE at the base station, they are encapsulated into G-PDUs and forwarded to the appropriate gateway based on the TEID. The receiving GTP-U endpoint decapsulates the G-PDU by stripping off the GTP-U header and forwards the original payload to its next destination, either within the core network or to an external packet data network. This tunneling mechanism is transparent to the user data and provides a consistent method for data transport that is independent of the underlying radio access technology (e.g., LTE, NR, or even non-3GPP access).
The role of the G-PDU extends beyond simple tunneling. It supports path management procedures like Echo Requests/Responses to verify peer aliveness. The inclusion of sequence numbers in the header (optional for some interfaces) enables in-order delivery and loss detection mechanisms, which are particularly important for inter-node interfaces where packet reordering might occur. In 5G systems, while the core network protocol between the (R)AN and the UPF is still GTP-U (N3 interface) or potentially other protocols, the fundamental concept of a tunneled user plane data unit persists. The G-PDU format ensures backward compatibility and interworking between 4G and 5G network elements, forming a stable backbone for mobile broadband and other services.
Purpose & Motivation
The G-PDU was created to provide a standardized, efficient, and scalable method for transporting user plane data across the packet-switched core network in 3GPP systems. Prior to its formal definition within GTP, early GPRS systems required a mechanism to separate and route individual user data streams through network nodes that serve millions of subscribers. The G-PDU, as part of GTP, solves the problem of user data multiplexing and mobility management by introducing a tunneling paradigm. It allows the core network to establish logical pipes (tunnels) for user data that are separate from the control signaling, enabling independent scaling and management of the data plane.
Its creation was motivated by the shift towards all-IP networks in 3GPP, starting with GPRS and evolving through UMTS to EPS and 5GS. The G-PDU provides the necessary abstraction layer between the user's IP packets and the transport network (IP network) connecting core network nodes. This abstraction is crucial for supporting subscriber mobility; as a user moves, the GTP tunnels can be re-routed (e.g., during handover or path switch procedures) without affecting the user's IP session. The TEID in the G-PDU header acts as a local routing label, allowing nodes to forward packets without inspecting the inner IP payload, which improves processing efficiency and supports various traffic types, including IPv4, IPv6, and Ethernet frames.
Furthermore, the G-PDU standardizes the interface between different vendors' equipment, ensuring interoperability in multi-vendor networks. By defining a common packet format, it allows an SGW from vendor A to exchange user data seamlessly with a PGW from vendor B. This was a key enabler for the competitive ecosystem in mobile core networks. The continued evolution and use of the G-PDU format across releases, including in 5G, underscore its effectiveness in solving the fundamental problem of agile, tunnel-based user plane transport in mobile networks.
Classification
Detected Changes Across Releases
from 3GPP Change RequestsSpecific changes extracted from the „Change history“ tables of 3GPP specifications (20 CRs across 5 releases). Complements the general historical overview above with the evidence-based evolution of this function.
Studied in Rel-8, normative work from Rel-15.
In Release 15, the G-PDU function was enhanced with a new GTP-U Extension Header for the PDU Session Container to support 5GS, and procedures were introduced for handling GTP-U Extension Headers. Additionally, the requirement for non-predictable GTP TEID assignment was explicitly extended to the PGW GTP-U on S5/S8/S2a/S2b interfaces to improve security. The release also clarified GTP-U tunnel endpoint descriptions and the ability to receive packets from multiple remote GTP-U endpoints.
- Unpredictability of GTP TEID for PGW GTP-C TS 29.274CR1883
- Interface Type of an AMF F-TEID and new cause code TS 29.274CR1947
- GTP-U Extension Header Handling TS 29.281CR0083
- New GTP-U extension header for 5GS TS 29.281CR0086
- New GTP-U Extension Header for the PDU Session Container TS 29.281CR0089
- Unpredictability of GTP TEID for PGW GTP-U TS 29.281CR0088
+ 3 more changes
In Release 16, the G-PDU function was updated by implementing the conclusions of TR 29.892 for GTP-U. This release also introduced the N19 user plane interface to support 5G VN group communication.
In Release 17, the G-PDU function was enhanced to support new interface types and signaling capabilities. This included the introduction of GTP-U tunneling for the N19mb interface and the ability to send a G-PDU message without a T-PDU for specific control signaling. Furthermore, mechanisms were added for detecting the restart of a GTP-U entity and for supporting User Plane Integrity Protection during interworking from 5GS to EPS.
- Support of User Plane Integrity Protection for Interworking from 5GS to EPS TS 29.274CR2033
- GTP-U tunneling for N3mb and N19mb TS 29.281CR0115
- Detecting of the restart of a GTP-U entity TS 29.281CR0116
- New Interface Type N19mb in F-TEID TS 29.274CR2061
- A G-PDU message without a T-PDU TS 29.281CR0119
- Support of Notify Start Pause of Charging via User Plane TS 29.274CR2010
In Release 18, the G-PDU function was enhanced by introducing a new GTP-U Extension Header specifically for the PDU Set Information Container. Additionally, the Update Bearer Response procedure was updated to include the PGW-C TEID during a PGW-triggered PDN connection restoration.
In Release 19, the G-PDU function was updated by fixing the GTP-U Tunnel Status Information and Recovery Time Stamp Information Elements. This correction ensures the proper handling of these specific IEs within the GTP user plane message structure, which carries the original tunnelled packet (T-PDU). The change maintains the definition of a G-PDU as consisting of a GTP-U header and a T-PDU.
- Fixing the GTP-U Tunnel Status Information and Recovery Time Stamp IEs TS 29.281CR0134
Explore further
Broader topics and technologies where G-PDU plays a role.
Defining Specifications
3GPP specifications that define or reference G-PDU, with the latest known release. Sourced from the 3GPP document catalog — see methodology.
| Specification | Title | Release |
|---|---|---|
| TS 29.274 vj50 | GTPv2-C Control Plane Protocol Specification | Rel-19 |
| TS 29.281 vj20 | GTPv1-U Protocol Specification | Rel-19 |