RLC Transparent Mode

Description

T-RLC, or RLC Transparent Mode, is one of the three operational modes of the Radio Link Control (RLC) sublayer within the 3GPP protocol stack, alongside Acknowledged Mode (AM) and Unacknowledged Mode (UM). It is defined primarily for circuit-switched (CS) voice services in UMTS and later for certain bearers in LTE. In this mode, the RLC sublayer is essentially bypassed for data processing; it does not add any RLC protocol headers, nor does it perform segmentation, reassembly, concatenation, or error correction via Automatic Repeat Request (ARQ). The RLC entity in transparent mode acts as a pass-through conduit, forwarding Service Data Units (SDUs) received from the upper layer (e.g., the PDCP layer or directly from CS voice codecs) directly to the lower MAC layer as Protocol Data Units (PDUs) of identical size. The primary architectural role of T-RLC is to minimize processing delay and protocol overhead for real-time traffic where timeliness is more critical than absolute data integrity, relying on physical layer coding and potential MAC-layer HARQ for error robustness.

The operation of T-RLC is tightly coupled with the specific bearer configuration. In UMTS, it was the standard mode for the Signalling Radio Bearer (SRB) for certain control messages and for the Conversational CS voice bearer. The RLC entity is configured during radio bearer setup via RRC signalling. When data arrives from the upper layer, the T-RLC entity does not buffer or modify it. It may, however, be involved in primitive interactions for flow control, but no RLC-specific sequence numbers or status reports are generated. This simplicity means there is no RLC-level retransmission mechanism; any necessary error recovery must be handled by other layers or is deemed acceptable for the service.

In the broader network architecture, T-RLC represents a design choice optimizing for minimal latency. For services like Voice over LTE (VoLTE), while the user plane typically uses RLC Unacknowledged Mode (UM) for the voice bearer, the control plane may utilize T-RLC for specific SRBs. Its existence highlights the layered approach in 3GPP, where different service requirements dictate different protocol configurations. The absence of RLC header overhead (typically 1-2 bytes) also contributes to spectral efficiency for small, frequent packets characteristic of voice. Understanding T-RLC is crucial for engineers designing low-latency services and analyzing protocol traces, as its presence indicates a bearer optimized for delay over reliability.

Purpose & Motivation

T-RLC was created to support real-time, delay-sensitive services, primarily circuit-switched voice, in 2G/3G UMTS networks and certain control signalling bearers. The core problem it addresses is the excessive latency and protocol overhead introduced by the full-featured RLC Acknowledged Mode, which provides reliable data transfer through segmentation and ARQ retransmissions but at the cost of variable and potentially high delay. For human speech, such delays and jitter are perceptually detrimental, making a simpler, near-instantaneous forwarding mechanism necessary.

Historically, in GSM, voice traffic was handled by specific channel coding without a complex link-layer protocol like RLC. With the introduction of UMTS and its unified packet-switched protocol architecture, a method was needed to integrate voice into this framework without sacrificing its real-time characteristics. T-RLC provided this by essentially disabling the RLC layer's processing for specific bearers, leveraging the inherent error resilience of the dedicated physical channel and voice codec's tolerance to occasional frame loss. This approach balanced the need for a common protocol stack with the stringent Quality of Service (QoS) requirements of conversational services.

In later releases like LTE, while packet-switched VoLTE predominantly uses RLC UM (which adds a small header for sequencing but no ARQ), the principle of T-RLC persists for specific applications where even that header overhead and processing delay must be avoided. It represents a key example of 3GPP's service-aware protocol configuration, where the network tailors the data link layer behavior based on the fundamental traffic requirements.

Key Features

• Zero RLC protocol header overhead
• No segmentation or concatenation of SDUs
• No Automatic Repeat Request (ARQ) error correction
• Minimal processing latency
• Used for delay-sensitive Circuit-Switched bearers
• Configured via RRC during radio bearer establishment

Evolution Across Releases

Defining Specifications