Protocol Type

Description

Protocol Type (PT) is a one-octet field located in the header of a GTP' (GPRS Tunnelling Protocol prime) message. GTP' is a variant of GTP used specifically on the Ga and Gz reference points between network elements like the GGSN, SGSN, or P-GW and the Charging Data Function (CDF) or Charging Gateway Function (CGF). Its sole purpose is to transport Charging Data Records (CDRs) or event-based charging information. The PT field is a critical discriminator within this transport mechanism. It indicates the nature of the protocol encapsulated in the 'Data' field of the GTP' message, allowing the receiving charging entity to parse the record correctly.

Technically, the PT field occupies bits 5 to 8 of the first octet in the GTP' header (following the Version, P, and E bits). Its value is defined in 3GPP TS 29.060 and related charging specifications. Common values include: 0 (Reserved), 1 (GTP'), 2 (GTP), 16 (TPKT, used for OSI TP0 transport), and 17 (UDP). The most frequently used value in charging scenarios is 1, indicating that the payload itself is a GTP' PDU (Protocol Data Unit) – meaning the message contains CDR data formatted according to GTP' charging procedures. Other values might be used in specific legacy interworking scenarios or for test purposes. The receiving CGF or billing system examines this field first to determine the appropriate decoder or handler for the incoming data packet.

The role of the PT field is architectural in ensuring the extensibility and correct operation of the offline charging data transport layer. Since the Ga/Gz interface may need to carry different types of data units over time (e.g., different versions of CDR formats or even other protocols for interworking), a static payload format is insufficient. The PT field provides a simple, low-overhead tagging mechanism. This is analogous to the 'Protocol' field in an IP header, which indicates whether the payload is TCP, UDP, or ICMP. In the charging data flow, after a network element generates a CDR, it is encapsulated in a GTP' message with the appropriate PT value and sent to the CGF. The CGF uses the PT field to direct the record to the correct processing logic before forwarding it to the billing domain. This clear separation of transport (GTP') and payload type enables robust and future-proof charging architecture.

Purpose & Motivation

The Protocol Type field was introduced to solve a specific problem in the transport of charging data: unambiguous payload identification. Early in the standardization of GPRS charging, it was recognized that the interface between the network generating usage records (GGSN/SGSN) and the billing system would need to carry structured data. GTP was already used for user plane tunneling (GTP-U) and control signaling (GTP-C), so a derivative, GTP', was created for charging. However, it was foreseen that the payload on this interface might not always be a GTP' formatted CDR; it could potentially be a raw CDR in another format or be encapsulated by an intermediate transport protocol for network traversal.

The PT field provides the necessary flexibility and forward compatibility. It allows a single GTP' transport mechanism to carry multiple types of payloads without requiring a change to the basic GTP' header structure or the establishment of separate physical interfaces for different payload types. This simplifies network design and operation for operators. Its creation was motivated by the need for a reliable, standardized, and extensible charging data transport protocol that could evolve alongside the core network itself, accommodating new services and charging models without overhauling the transport layer. It addresses the limitation of having a fixed, implicit payload type, which would have made the system brittle and difficult to upgrade.

Key Features

• One-octet field in the GTP' message header
• Defines the protocol of the encapsulated payload data
• Key values: 1 for GTP' (charging data), 2 for GTP, 16 for TPKT
• Enables the receiving system to select the correct parser/decoder
• Provides extensibility for future payload types
• Essential for correct processing of Charging Data Records (CDRs)

Evolution Across Releases

Defining Specifications