PPI

Payload Protocol Identifier

Protocol →
Introduced in Rel-8

PPI is a field in protocol headers that identifies the type of data payload being carried to enable correct interpretation and processing by the receiving entity.

Category
Protocol
Introduced
Rel-8
Where
Core Network › 5G Core
Specifications
4 specs
PPI Description Purpose Related Classification Detected Changes Specifications

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

Part ofGTP-U
Related approachesMULTIPLEXING

Release Timeline

Detected Changes Across Releases

from 3GPP Change Requests

Specific 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.

Rel-16 1 change

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.

SpecificationTitleRelease
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
Patrick Zandl

About the author: Patrick Zandl (b. 1974)

Telecommunications specialist, technology journalist (founder of the Mobil server), and developer who has been running since 2025 — the largest Czech-language resource on AI-assisted programming. Formerly Chief Wizard Architect at Prusa3D and head of development for Turris at CZ.NIC; currently a consultant and instructor on AI implementation in companies.