Description
The Payload Protocol Identifier (PPI) is a crucial field used in various 3GPP protocol data units to specify the nature of the encapsulated payload. It acts as a demultiplexing key, allowing a receiving protocol entity to determine the correct upper-layer protocol or processing context for the data it has received. The PPI is not a single, universal identifier but is defined within the context of specific bearer protocols. Its most prominent use is in the GPRS Tunneling Protocol for the user plane (GTP-U), where the PPI field in the GTP-U header indicates the type of payload within the tunnel, such as IPv4, IPv6, or PPP. This tells the Gateway GPRS Support Node (GGSN) or Packet Data Network Gateway (PGW) how to process the packet after decapsulation.
In other contexts, the PPI serves similar purposes but with different enumerated values. For example, in Packet Data Convergence Protocol (PDCP) for LTE and NR, a similar field (though not always called PPI) identifies the type of data unit (e.g., IP packet, signaling message) for header compression and security processing. In Robust Header Compression (RoHC) profiles, an identifier specifies the protocol being compressed. The PPI is typically an 8-bit or 16-bit field located in a fixed position within the protocol header. The receiving entity parses this field first to select the appropriate handler, decoder, or decompressor for the remainder of the packet.
Architecturally, the PPI enables protocol layering and multiplexing. A single lower-layer protocol entity (like a GTP-U tunnel or a PDCP entity) can carry traffic for multiple upper-layer protocols or service data flows simultaneously. The PPI provides the necessary discrimination. Its correct interpretation is vital for end-to-end data integrity. If misidentified, an IPv6 packet could be mistakenly handed to an IPv4 stack, causing failure. Therefore, the values are standardized in the relevant specifications (e.g., 29.060 for GTP, 38.323 for NR PDCP) to ensure interoperability across vendors and network interfaces, such as the S1-U, S5/S8, and N3 interfaces.
Purpose & Motivation
The Payload Protocol Identifier exists to solve the fundamental networking problem of multiplexing and demultiplexing multiple types of traffic over a shared transport mechanism. In mobile networks, user plane tunnels (like GTP-U) carry a vast array of data payloads—web traffic (IPv4/IPv6), voice over IP, IoT data, and even legacy PPP frames. Without an explicit identifier in the tunnel header, the egress gateway would have to attempt deep packet inspection or rely on implicit context, which is unreliable, inefficient, and inflexible. The PPI provides a simple, in-band signal that unequivocally declares the payload type.
It addresses the limitations of static or implicit payload association. Early data networks often assumed a single payload type per connection. The evolution towards multi-service, multi-protocol networks demanded a dynamic and explicit identification mechanism. The PPI enables the network to support new payload types (like IPv6 when transitioning from IPv4) without changing the fundamental tunneling protocol itself; only the list of recognized PPI values needs to be extended. This supports forward compatibility and smooth network evolution.
The motivation for standardizing PPIs across different protocols (GTP, PDCP) is consistency and reduced complexity. Introduced in earlier releases for GTP and significantly leveraged from Release 8 onwards with LTE's all-IP architecture, the PPI concept became central to the flexible bearer model. It is especially critical in 5G's service-based architecture with network slicing, where a single physical infrastructure must seamlessly carry diverse traffic types with different processing requirements. The PPI ensures each packet is routed to the correct virtualized network function or protocol stack for its intended service.
Classification
Release Timeline
Detected Changes Across Releases
from 3GPP Change RequestsSpecific changes extracted from the „Change history“ tables of 3GPP specifications (1 CRs across 1 releases). Complements the general historical overview above with the evidence-based evolution of this function.
In Release 16, the control over the UPF's setting of the Paging Policy Indicator (PPI) was clarified and corrected for specific architectural scenarios. Specifically, it was defined that in a Home-Routed roaming case, the V-SMF is responsible for this control, and in a PDU Session with an I-SMF, the I-SMF is responsible. This correction ensured proper PPI setting control over the N4 interface.
- Correction to PPI setting control over N4 TS 23.501CR1695
Explore further
Broader topics and technologies where PPI plays a role.
Defining Specifications
3GPP specifications that define or reference PPI, with the latest known release. Sourced from the 3GPP document catalog — see methodology.
| Specification | Title | Release |
|---|---|---|
| TS 23.501 vk00 | 5G System Architecture Stage 2 | Rel-20 |
| TS 25.820 v820 | 3G Home NodeB Study Report | Rel-8 |
| TR 26.928 vj00 | Study on eXtended Reality (XR) in 5G | Rel-19 |
| TS 38.415 vj10 | PDU Session User Plane Protocol | Rel-19 |