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
Detected Changes Across Releases
from 3GPP Change RequestsSpecific changes extracted from the „Change history“ tables of 3GPP specifications (66 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 PPI (Payload Protocol Identifier) function was not newly introduced; the provided Change Request titles and grounding context do not describe any new PPI features. The listed changes focus on other identifier types and procedures, such as the Subscription Permanent Identifier (SUPI), 5GS temporary identifiers, and corrections for protocol stacks and interworking.
- Use of identifiers for mobility between GERAN/UTRAN and 5GS TS 23.501CR0017
- Fixes for CP protocol stack TS 23.501CR0083
- Partitioning of Identifier space to ensure success of Context retrieval for EPS Interworking TS 23.501CR0090
- Subscription Permanent Identifier TS 23.501CR0189
- Changed length and mapping of 5GS Temporary Identifiers TS 23.501CR0206
- Correction on Control Plane protocol stacks TS 23.501CR0240
+ 10 more changes
In Release 16, the PPI (Payload Protocol Identifier) function was enhanced with a specific correction to its setting control over the N4 interface, as indicated by the CR title. This provided a more precise mechanism for managing the PPI value used within GTP-U tunnels for user plane packet identification. Additionally, the release introduced QoS monitoring procedures based on GTP-U paths, including packet delay reporting for N3/N9 interfaces, which rely on the proper identification of payload protocols.
- Protocol stack for W-5GAN support TS 23.501CR0961
- QoS monitoring based on GTP-U paths TS 23.501CR1414
- Clarification for the related CAG identifier TS 23.501CR1371
- Clarification on reordering requirement with GTP-U redundancy TS 23.501CR1490
- Correction to protocol stacks for RTT measurements TS 23.501CR1652
- Correction to PPI setting control over N4 TS 23.501CR1695
+ 12 more changes
In Release 17, the PPI function was enhanced to support new transport protocols and configurations, specifically for the TSCTSF functionality as clarified in the release. This included updates to enable GTP-U path monitoring triggered by PCC rules and corrections to protocol stacks for non-3GPP access, such as the PMF protocol stack. These changes ensured the PPI could accurately identify payload protocols across a broader set of access types and transport scenarios.
- Adding PDU session limitation and protocol stacks for trusted WLAN access for N5CW device TS 23.501CR2991
- Corrections on the AF related identifier TS 23.501CR3064
- KI#3, clarification on the TSCTSF functionality and configuration for transport protocols TS 23.501CR3160
- Updates on PCC rule triggered GTP-U path monitoring TS 23.501CR2889
- Correction on PMF protocol stack for non-3GPP access TS 23.501CR3302
- Correction to UE identifier sent to AMF by UE TS 23.501CR2801
In Release 18, the PPI function saw clarifications and corrections to its protocol description, including fixes for incorrect options like combining SRTP with RTP Payload Format. Updates also provided clarifications on its applicability in Packet Detection Rules for End of Data Block identification in the downlink and for protocol descriptions for both uplink and downlink traffic.
- PIN identifiers TS 23.501CR4287
- Clarifications for GTP-U Path Monitoring TS 23.501CR4057
- Corrections on Protocol Description TS 23.501CR4844
- Correction and clarification of the Protocol Description definition TS 23.501CR5008
- Protocol Descriptions for UL and DL traffic TS 23.501CR5228
- Clarifications on applicability of Protocol Description in PDR for EoDB identification in DL TS 23.501CR5295
+ 3 more changes
In Release 19, the enhancements for the Payload Protocol Identifier (PPI) function focused on enabling QoS differentiation for traffic from non-3GPP devices connecting behind a UE or 5G-RG. This was achieved by introducing support for including multiple Non-3GPP Device Identifiers in session management signaling. The updates also provided clarifications and corrections on the associated session management procedures and security parameters for handling these identifiers.
- Control Plane and User Plane Protocol stacks involving the MWAB node TS 23.501CR5561
- Support of Regenerative Payload with NG-RAN Node Onboard Satellite TS 23.501CR5622
- General description of relaying media related information over N6 using an encapsulation protocol TS 23.501CR5711
- UDR enhancement supporting Device Identifier of non-3GPP Devices connecting behind a UE/5G-RG TS 23.501CR5547
- Definition of identifiers of N3GPP device behind UE/5G-RG TS 23.501CR5749
- AMF selection for regenerative payload TS 23.501CR5908
+ 11 more changes
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 |