Payload Protocol Identifier

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.

Key Features

• Demultiplexing key within protocol headers to identify payload type (e.g., IPv4, IPv6, PPP).
• Enables a single protocol entity to carry multiple types of upper-layer data simultaneously.
• Standardized values ensure interoperability across vendor equipment and network interfaces.
• Critical for correct payload processing after decapsulation in tunnels like GTP-U.
• Supports evolution to new protocols by allowing extension of identifier values.
• Used in key protocols including GTP-U (control and user plane), PDCP, and RoHC.

Evolution Across Releases

Defining Specifications