Node Address byte

Description

The Node Address byte (NAD) is a protocol field defined in early 3GPP specifications, notably within the context of the Radio Link Control (RLC) and other layer 2/3 protocols for UMTS and GSM evolution. It serves as a local identifier, typically one octet in length, used to distinguish between different logical connections or service access points between two communicating network entities. In architectural terms, the NAD is part of the protocol data unit (PDU) header, allowing a single physical or transport channel to carry multiple logical channels or data flows destined for different higher-layer processes or applications within the same node.

Operationally, the NAD works by being assigned during connection establishment or session setup. For instance, in some RLC configurations for dedicated channels, the NAD byte can identify the specific RLC entity or service data unit (SDU) type being transmitted, enabling the receiver to correctly demultiplex incoming data to the appropriate upper-layer protocol (e.g., call control, mobility management, or user plane data). The value range of 0-255 allows for sufficient multiplexing capacity for most node-internal endpoints. The NAD is often used in conjunction with other identifiers like the Data Link Connection Identifier (DLCI) or Service Access Point Identifier (SAPI) to create a complete addressing scheme for layer 2 protocols.

Its role is particularly important in legacy circuit-switched domains and early packet-switched control plane signaling, where efficient use of limited bandwidth and structured message routing were critical. By including the NAD in the PDU, the protocol ensures that messages are delivered to the correct internal handler without requiring separate physical connections for each logical channel, thus conserving resources and simplifying network architecture. However, with the evolution towards all-IP networks and more streamlined protocols in LTE and NR, the explicit use of a dedicated NAD byte has been largely superseded by more sophisticated multiplexing mechanisms in the MAC and PDCP layers.

Purpose & Motivation

The Node Address byte was created to address the need for efficient multiplexing of multiple logical channels over a single physical or transport connection in early digital cellular systems like GSM and UMTS. Prior to its standardization, proprietary or less flexible addressing schemes could lead to interoperability issues and inefficient resource utilization when handling simultaneous services (e.g., voice, signaling, and packet data) on the same radio link.

It solves the problem of directing protocol data units to the correct internal processing entity within a network node (e.g., a base station or mobile station) without requiring separate physical resources for each logical stream. This was especially important in the era of circuit-switched dominated networks, where signaling and user plane data needed to be reliably separated and managed on limited-capacity links. The NAD provided a simple, standardized way to achieve this demultiplexing, ensuring that control messages for call setup, handover, and supplementary services could coexist with user voice frames on the same connection.

Historically, its introduction in Release 4 aligned with the enhancement of GSM and the initial rollout of UMTS, supporting the increasing complexity of services and the transition towards more packet-oriented communications. While its prominence has diminished in later 4G and 5G systems due to the adoption of IP-based protocols and more integrated layer 2 designs, the NAD remains a relevant concept for understanding legacy system operation and backward compatibility in multi-RAT networks.

Key Features

• One-octet field for local node addressing
• Enables multiplexing of multiple logical channels over a single transport
• Used in RLC and other layer 2/3 protocol headers
• Supports demultiplexing to correct upper-layer entities
• Facilitates efficient resource usage in legacy systems
• Part of early 3GPP circuit-switched and packet-control protocols

Evolution Across Releases

Defining Specifications