INF

INFormation field

Protocol
Introduced in Rel-4
The INF is a variable-length field within certain 3GPP protocol data units used to carry essential control or user information. Its structure and interpretation are defined by the specific protocol and message type, making it a fundamental, flexible container for payload in signaling and data transmission.

Description

The INFormation (INF) field is a generic, variable-length container field used within the data structures of various 3GPP protocol specifications, as referenced in the vocabulary specification TS 21.905. It is not a protocol itself but a fundamental building block within protocol message definitions. The INF field is designed to carry the actual substantive information required for a particular protocol exchange. The content, encoding, and semantics of the INF field are entirely defined by the context in which it is used—specifically, by the protocol layer and the particular message type (Protocol Discriminator and Message Type) that encapsulates it.

Technically, a protocol data unit (PDU) containing an INF field typically has a structured header followed by the INF field. The header includes fixed elements like transaction identifiers, protocol discriminators, and message types. The INF field then constitutes the remainder of the PDU. Its internal structure is often composed of a series of Information Elements (IEs), each with its own identifier, length, and value. For example, in a Radio Resource Control (RRC) connection setup message, the INF field would contain IEs specifying the radio parameters, channel configurations, and UE identities. The network and the UE decode the INF field based on their shared knowledge of the protocol specification for that specific message.

From an architectural perspective, the use of an INF field promotes protocol efficiency and extensibility. By having a variable-length field, protocols avoid wasting bandwidth with fixed-length messages that are often only partially filled. More importantly, it allows for backward-compatible evolution. New IEs can be added to the INF field of a message in a later protocol release. Receivers compliant with the older release can ignore the new, unknown IEs (if the protocol rules allow it) and still process the parts they understand, as long as the fundamental message structure with the INF container remains stable. This pattern is ubiquitous across 3GPP's layer 3 signaling protocols, including RRC, Non-Access Stratum (NAS), and certain core network application protocols.

Purpose & Motivation

The purpose of the INFormation field is to provide a standardized, flexible mechanism for encapsulating the variable and evolving payload of control plane messages in telecommunications protocols. Early communication protocols sometimes used fixed-format messages, which became inefficient and rigid as services grew more complex. Any new parameter required a new message type or a breaking change to the message format. The INF field concept addresses this by separating the message identity (in the header) from the message content (in the INF field).

This design solves the problem of protocol longevity and multi-vendor interoperability. It allows the core structure of a protocol—how messages are initiated, acknowledged, and distinguished—to remain simple and stable, while the detailed information needed for rich feature sets can grow and change within the INF container. For 3GPP, which manages standards used by hundreds of equipment providers globally, this is critical. It enables a smooth introduction of new features (e.g., new QoS parameters, security algorithms, or mobility procedures) without requiring a complete overhaul of the underlying protocol state machines.

The motivation for its formal definition in a vocabulary specification like TS 21.905 is to ensure consistent terminology and understanding across all the myriad 3GPP technical specifications. When a protocol engineer reads 'INF field' in a specification, they immediately understand it refers to this variable-length, message-specific payload section. This conceptual reuse reduces ambiguity and accelerates the development and testing of compliant equipment, from mobile phones to network infrastructure.

Key Features

  • Variable-length field acting as a container for protocol message payload
  • Content and structure are defined by the specific protocol and message type
  • Typically contains a sequence of Information Elements (IEs) with tag-length-value encoding
  • Enables efficient use of bandwidth by avoiding fixed-length message padding
  • Provides inherent extensibility for adding new parameters in future protocol releases
  • A foundational construct used across multiple 3GPP control plane protocols (e.g., RRC, NAS)

Evolution Across Releases

Rel-4 Initial

Formally defined as a term in the 3GPP vocabulary (TS 21.905). Its initial conceptualization provided the generic model for variable-length information carrying in protocol design, establishing the pattern of separating fixed message headers from variable message contents, which was already prevalent in protocols like RRC and NAS from earlier releases.

Defining Specifications

SpecificationTitle
TS 21.905 3GPP TS 21.905