Fact-checked by Grok 2 weeks ago

Radio Link Control

Radio Link Control (RLC) is a sublayer of Layer 2 in the protocol stack for mobile telecommunications systems, positioned between the (MAC) layer and the (PDCP) layer, where it handles the reliable transfer of upper-layer Protocol Data Units (PDUs) in both control and user planes. It performs key functions such as segmentation and reassembly of Radio Link Control Service Data Units (RLC SDUs), sequence numbering for , duplicate detection, and error correction via (ARQ) in acknowledged modes. RLC operates in three primary modes—Transparent Mode (TM) for unformatted data transfer without headers, Unacknowledged Mode (UM) for efficient but non-reliable delivery, and Acknowledged Mode (AM) for robust bidirectional communication with retransmissions—enabling adaptation to different service requirements like low latency or high reliability. Originally specified for in Release 99 as part of the Radio Network Controller (RNC), RLC has evolved significantly across generations: in ( Release 8 onward), it supports enhanced segmentation and in-sequence delivery for downlink/uplink data bearers, while in New Radio (NR, Release 15+), it accommodates the /distributed unit (CU/DU) split , omitting concatenation to minimize and supporting longer numbers (up to 18 bits in AM). These adaptations ensure RLC's provision of PDUs to the MAC for logical channels, managing PDUs with fixed/variable headers (e.g., 1- or 2-byte headers in NR), and interfacing with (RRC) for configuration via information elements like RLC-Config. Overall, RLC contributes to the air interface's efficiency by balancing throughput, error handling, and resource utilization in cellular networks from to .

Overview

Definition and Purpose

The Radio Link Control (RLC) sublayer is a Layer 2 protocol defined in standards for , , and systems. In and , it operates as an intermediary between the (PDCP) sublayer above and the (MAC) sublayer below to format and manage data packets for transmission over the radio interface. In , RLC interfaces between upper layers and MAC. RLC entities perform these tasks to ensure efficient and reliable data handling in mobile networks, supporting both user plane and control plane communications between user equipment (UE) and the radio access network. The primary purpose of the RLC sublayer is to provide reliable transfer of upper-layer Protocol Data Units (PDUs) by implementing mechanisms for segmentation and reassembly, which adapt variable-sized PDCP PDUs (in and ) or upper-layer PDUs (in ) to the constraints of MAC-layer transport blocks, thereby optimizing radio resource utilization. Additionally, RLC handles to maintain , enabling support for diverse (QoS) requirements such as low latency for ultra-reliable low-latency communications (URLLC) and high throughput for enhanced (eMBB). These functions collectively ensure robust end-to-end data delivery in varying radio conditions without overburdening higher or lower layers. RLC operates on a per-logical-channel basis, with dedicated RLC entities configured independently for each logical channel to handle specific data flows, allowing simultaneous support for multiple radio bearers that map to these channels for concurrent service delivery. This architecture facilitates fine-grained QoS differentiation across bearers, such as signaling radio bearers (SRBs) and data radio bearers (DRBs), while maintaining overall system efficiency.

Position in the Protocol Stack

The Radio Link Control (RLC) sublayer occupies the second position within Layer 2 of the Evolved Universal Terrestrial Radio Access (E-UTRA) protocol stack for Long-Term Evolution (LTE) and the New Radio (NR) protocol stack for 5G, situated directly below the Packet Data Convergence Protocol (PDCP) sublayer and above the Medium Access Control (MAC) sublayer. This placement applies to both the user plane and control plane architectures in LTE (as defined in 3GPP TS 36.322 V19.0.0, Section 4) and 5G NR (3GPP TS 38.322 V18.2.0, Section 4.1), where RLC handles reliable data transfer over the radio interface while interfacing with higher-layer security and compression functions from PDCP and lower-layer multiplexing from MAC. In this architecture, RLC ensures segmentation and delivery of data units across varying radio conditions without delving into physical transmission details managed by Layer 1. RLC interacts with adjacent sublayers through well-defined service access points (SAPs). It receives service data units (SDUs) from PDCP for processing and delivers protocol data units (PDUs) to via logical s, which categorize data flows such as broadcast control (BCCH), dedicated (DTCH), and dedicated control (DCCH) based on their priority and type. Conversely, RLC accepts MAC SDUs—typically transport blocks—from the MAC sublayer for uplink or downlink , enabling the to adapt to dynamic radio resources. These interfaces support both uplink and downlink directions, with MAC providing notifications on transmission opportunities and available PDU sizes to RLC ( TS 36.322 V19.0.0, Section 4.3; TS 38.322 V18.2.0, Section 4.3.2). RLC entities are instantiated on a per-user equipment (UE) and per-logical-channel basis, with distinct transmitter and receiver components to handle directional data flows independently. The transmitter side processes incoming PDCP SDUs by adding appropriate headers and preparing them for MAC delivery, while the receiver side reconstructs SDUs from incoming MAC SDUs for forwarding to PDCP. This configuration allows flexible operation tailored to specific channels, as directed by the (RRC) layer. Conceptually, the data flow proceeds from PDCP SDUs entering the RLC entity, undergoing processing to form RLC PDUs, and then passing to MAC for both downlink (from to UE) and uplink (from UE to ) paths, as illustrated in the RLC overview models (e.g., Figure 4.2.1-1 in both specifications), which depict unidirectional arrows representing SDU-to-PDU transformations on each side of the entity (3GPP TS 36.322 V19.0.0, Section 4.2.1; 3GPP TS 38.322 V18.2.0, Section 4.2.1).

History and Standards

Origins in UMTS

The Radio Link Control (RLC) layer was introduced in the 3GPP Release 99 specifications, finalized around 2000, as a fundamental Layer 2 sublayer above the (MAC) sublayer in the radio interface protocol architecture based on Wideband Code Division Multiple Access (WCDMA). This development addressed the need for efficient data handling in third-generation () mobile networks, where the MAC layer delivers fixed-size transport blocks per transmission time interval (TTI), requiring adaptation of variable-length data from higher layers. Key early functions of RLC in encompassed basic segmentation of service data units (SDUs) into protocol data units (PDUs) using length indicators to preserve boundaries, along with (ARQ) for reliable acknowledged data transfer through selective retransmissions. It also provided support for both circuit-switched services, such as real-time voice, and emerging packet-switched services, enabling seamless integration with the UMTS core network for multimedia applications. These features prioritized error correction and flow control to maintain quality in the variable radio conditions of WCDMA, particularly for voice and low-speed data transmissions typical in early deployments. The RLC protocol in UMTS is formally specified in 3GPP Technical Specification TS 25.322, which outlines its three modes—transparent, unacknowledged, and acknowledged—to suit diverse service requirements while ensuring backward compatibility with second-generation systems. Historically, RLC evolved from its implementation in the General Packet Radio Service (GPRS) enhancement to Global System for Mobile Communications (GSM), adapting to UMTS's higher data rates (up to 384 kbps initially) and circuit-oriented architecture by enhancing segmentation and reliability mechanisms for the more bandwidth-intensive WCDMA air interface.

Evolution in LTE

The Radio Link Control (RLC) protocol was introduced for Long-Term Evolution (LTE) in 3GPP Release 8, finalized in 2008, as part of the Evolved Universal Terrestrial Radio Access Network (E-UTRAN) architecture. This adaptation supported the shift from the Code Division Multiple Access (CDMA) used in Universal Mobile Telecommunications System (UMTS) to Orthogonal Frequency Division Multiple Access (OFDMA) in the downlink and Single Carrier FDMA in the uplink, enabling higher spectral efficiency and data rates. Hybrid Automatic Repeat Request (HARQ) functionality was integrated at the Medium Access Control (MAC) sublayer to handle fast retransmissions, reducing the burden on RLC while maintaining reliable data transfer over the air interface. Key enhancements in RLC included the addition of re-segmentation in Acknowledged (AM), allowing previously transmitted RLC Units (PDUs) to be broken into smaller segments during HARQ retransmissions if they exceeded the available transport block size at the layer. reporting was refined for ARQ operations, where the receiving side generates STATUS PDUs to acknowledge or negatively acknowledge specific PDUs, triggering selective retransmissions from the transmitter. The ARQ mechanism supported a transmitter size of 512, utilizing a 10-bit sequence number to manage outstanding PDUs and prevent while ensuring efficient error recovery. The RLC protocol is formally specified in Technical Specification (TS) 36.322, which outlines its role in the user plane and for E-UTRAN. It was optimized for IP-based, all-packet switched networks, facilitating low-latency services such as (VoIP) and multimedia streaming by prioritizing segmentation, reassembly, and ARQ tailored to variable packet sizes and quality-of-service requirements. A notable enhancement was the introduction of the RLC Service Data Unit (SDU) discard procedure, which allows the transmitter to discard specific SDUs upon indication from upper layers like the Packet Data Convergence Protocol (PDCP), preventing indefinite buffering of delayed or obsolete data in scenarios like real-time applications. This mechanism, applicable in both Unacknowledged Mode (UM) and AM, integrates with PDCP discard timers to maintain end-to-end efficiency without requiring explicit RLC timers.

Advancements in 5G NR

The Radio Link Control (RLC) protocol in 5G New Radio (NR) was defined in 3GPP Release 15, finalized in 2018, and specified in TS 38.322, enabling operations across a broader range of frequencies including millimeter-wave bands and supporting beamforming through integration with the underlying NR physical layer. This design accommodates the demands of ultra-reliable low-latency communication (URLLC) and massive machine-type communications (mMTC) by optimizing data transfer for diverse scenarios, such as industrial automation and dense IoT deployments. Key advancements in NR RLC include refined polling and status reporting mechanisms in acknowledged mode (AM), where transmission triggers a status report based on configurable thresholds like pollPDU (number of PDUs transmitted without polling) or pollByte (bytes transmitted without polling), reducing unnecessary feedback overhead compared to baselines. In unacknowledged mode (UM), support for out-of-order delivery to the (PDCP) layer enhances latency performance for URLLC applications, allowing SDUs to be forwarded as they arrive within a reassembly window, with timer-based detection of missing PDUs to prevent indefinite delays. Additionally, tighter integration with PDCP facilitates dual connectivity scenarios, such as non-standalone NR deployments, by enabling split bearers where RLC entities on multiple nodes handle segmented data streams, improving reliability through coordinated retransmissions. In AM, NR RLC supports sequence numbers (SNs) with lengths configurable to 12 or 18 bits, providing greater capacity for high-throughput while maintaining compatibility with varying buffer sizes. Enhancements for sidelink communications in (V2X) applications, introduced in Release 16, extend RLC operations to direct device-to-device , incorporating ARQ mechanisms tailored for low-latency vehicular scenarios with configurable SN lengths and polling to ensure robust packet delivery over sidelink channels. As of 2025, Release 18 incorporates RLC adaptations for reduced capability () devices and non-terrestrial networks (NTN), addressing integration challenges in satellite-based systems by extending timers (e.g., t-Reassembly and t-PollRetransmit) to handle delays up to several seconds and supporting larger SN spaces to mitigate buffer overflows in high-orbit scenarios, thereby closing gaps in earlier releases for global coverage.

Modes of Operation

Transparent Mode (TM)

Transparent Mode (TM) is the simplest operating mode of the Radio Link Control (RLC) protocol, configured for direct transfer of upper-layer protocol data units (PDUs) without segmentation, concatenation, reassembly, or addition of any RLC headers. In this mode, the RLC entity functions as a transparent conduit, receiving service data units (SDUs) from the (PDCP) layer and submitting them unmodified to the (MAC) layer for transmission. This configuration ensures minimal processing overhead, with TM PDUs consisting solely of the original data field. TM is primarily employed for logical channels requiring low-latency, headerless transmission where error correction and reliability are handled by other layers, such as the physical layer or higher protocols. Key use cases include broadcasting system information via the Broadcast Control Channel (BCCH), paging notifications on the Paging Control Channel (PCCH), and initial access signaling on the Common Control Channel (CCCH) in both LTE and 5G New Radio (NR). It is specifically designated for Signaling Radio Bearer 0 (SRB0) to transport Radio Resource Control (RRC) messages during random access procedures in LTE (3GPP TS 36.322) and 5G NR (3GPP TS 38.322). Additionally, TM supports sidelink broadcast control channels like the Sidelink BCCH (SBCCH) for sidelink scenarios in LTE and 5G NR. At the transmitter side, a TM RLC receives PDCP PDUs as RLC SDUs and immediately forwards them to the layer without any alterations, numbering, or buffering for retransmission. The receiver side operates similarly, delivering incoming TM PDUs directly to the PDCP layer upon reception, with no reordering, duplicate detection, or error recovery mechanisms provided by the RLC. Consequently, there is no RLC feedback or status reporting in TM, and the mapping to logical channels occurs in fixed sizes matching the original SDU lengths, preserving the as received from upper layers. This mode contrasts with Unacknowledged Mode (UM) and Acknowledged Mode (AM) by omitting sequencing and feedback capabilities, prioritizing efficiency for scenarios like control signaling and where upper-layer reliability suffices.

Unacknowledged Mode (UM)

The Unacknowledged Mode (UM) in the Radio Link Control (RLC) protocol enables unidirectional data transfer service, incorporating sequence numbering to facilitate reordering of received protocol data units (PDUs) and detection of duplicates, while omitting any acknowledgment or (ARQ) mechanisms. This mode ensures efficient handling of data without the overhead of feedback, prioritizing timeliness over complete reliability. In UM, the RLC entity operates with distinct transmitting and receiving components that function independently, allowing for streamlined processing on each direction. UM is particularly suited for delay-sensitive applications, such as (VoIP) and multimedia streaming, where retransmissions could introduce unacceptable latency, and minor packet losses do not severely impact the service quality. For instance, it supports dedicated traffic channels (DTCH) for user data in both downlink and uplink directions, as well as broadcast and channels like MCCH and MTCH in , and extends to sidelink communications in for groupcast and broadcast scenarios. The sequence number length in UM is configurable via (RRC) signaling: 5 bits or 10 bits in , providing a modulus of 32 or 1024 respectively, and 6 bits or 12 bits in , yielding a of 64 or 4096 to accommodate varying throughput needs. Sequence numbers are assigned and incremented for each transmitted UMD PDU, enabling the receiver to track order and identify gaps. At the receiving end, the UM RLC entity buffers incoming PDUs and performs reassembly of service data units (SDUs) by detecting sequence number gaps that indicate missing s; if a complete SDU cannot be reconstructed, it is discarded to prevent indefinite buffering. A reassembly (t-Reassembly in or t-Reordering in ) is started upon detection of such gaps, and upon its expiry, any affected SDUs are discarded, triggering delivery of subsequent in-sequence data to the upper layer. In , UM explicitly supports out-of-order SDU delivery within a configurable reassembly window (UM_Window_Size, set to 32 for 6-bit SN or 2048 for 12-bit SN), allowing higher-layer protocols to handle reordering if needed, which enhances efficiency for high-speed links. The transmitting side may discard SDUs based on a configured if they cannot be transmitted promptly, further emphasizing UM's focus on forward progress over recovery. Segmentation of SDUs into PDUs occurs as needed to fit lower-layer capacities, with headers including the sequence number and segment indicators for reassembly.

Acknowledged Mode (AM)

The Acknowledged Mode (AM) in the Radio Link Control (RLC) layer functions as a single bidirectional entity that integrates both a transmitting side and a receiving side to provide reliable transfer services. This mode employs (ARQ) mechanisms, where the receiving side generates status reports to acknowledge correctly received or indicate gaps in the sequence, thereby triggering retransmissions of erroneous or lost Protocol Data Units (PDUs) by the transmitting side. To initiate these status reports, the transmitting side uses configurable polling procedures, such as triggering a poll upon transmission of the last or after a specified number of PDUs or bytes. AM is designed for scenarios demanding high reliability over the radio link, where occasional retransmission delays are acceptable, making it ideal for non-real-time applications such as browsing and file downloads. In and architectures, AM is commonly configured for Data Radio Bearers (DRBs) associated with Dedicated Traffic Channels (DTCH), as well as Dedicated Channels (DCCH) for signaling. This configuration ensures error-free delivery for upper-layer protocols that prioritize over low . A key aspect of AM is its configurable transmission window size, which limits the number of unacknowledged PDUs to prevent and manage sequence numbering; this is set to a maximum of 512 in using 10-bit sequence numbers and up to 2048 (for 12-bit SN) or 131072 (for 18-bit SN) in , where the SN length is configurable to 12 or 18 bits. To resolve potential desynchronization between peer RLC entities, AM supports a reset procedure that discards all pending Service Data Units (SDUs) and PDUs, resets relevant state variables and timers, and re-establishes the connection upon detection of issues like repeated failures. In terms of operational behavior, the receiving side issues negative acknowledgments (NACKs) within status PDUs to pinpoint missing PDUs via sequence number indicators, enabling the transmitting side to perform targeted retransmissions without resending acknowledged . Ciphering for is applied at the (PDCP) layer above the RLC in both and , occurring after RLC processing for bearer configurations that require encryption. The ARQ process in AM, as outlined in core functions, relies on these status reports and polls to achieve the desired reliability.

Core Functions

Segmentation and Reassembly

In the Radio Link Control (RLC) layer of and , segmentation is the process by which the transmitting RLC entity divides RLC SDUs received from the upper PDCP layer (as PDCP PDUs) into smaller RLC PDUs to accommodate the variable transport block sizes provided by the (MAC) layer. This adaptation ensures efficient utilization of radio resources, as RLC SDUs may exceed the maximum size of a MAC (PDU). Segmentation occurs exclusively in Unacknowledged Mode (UM) and Acknowledged Mode (AM) of RLC operation. The segmentation procedure begins when the RLC entity receives an RLC SDU and is notified by the layer of an available transmission with a specified size. If the RLC SDU surpasses this size (after accounting for RLC headers), in the entity performs of multiple RLC SDUs or segmentation of a single RLC SDU into one or more RLC PDUs, whereas in only segmentation of a single RLC SDU is performed, without . Each resulting RLC PDU is prefixed with a header containing a Sequence Number () for and ordering, along with indicators and segmentation to delineate boundaries and types (e.g., first, last, middle, or full SDU). The of each is calculated as the minimum of the remaining RLC SDU and the available space in the PDU, expressed as \text{[Segment length](/page/Length)} = \min(\text{remaining RLC SDU length}, \text{available MAC space}). This process repeats until the entire RLC SDU is segmented or the is filled. In , lengths are 5 or 10 bits for UM and 10 or 16 bits for AM depending on configuration, while supports configurable lengths of 6/12 bits for UM and 12/18 bits for AM to handle higher data rates. Reassembly at the receiving RLC entity involves buffering incoming RLC PDUs (in the form of UM (UMD) PDUs or AM () PDUs) in a reception and reconstructing the original RLC SDUs. The uses the in each PDU header to detect and order belonging to the same RLC SDU, discarding duplicates if necessary. Once all of an RLC SDU—identified by matching , segment offsets, and indicators—are received and contiguous, the full SDU is reassembled and delivered to the PDCP layer in ascending order (or out-of-order if configured). If gaps in sequence are detected, the awaits missing within a timer window before potentially discarding incomplete SDUs in UM or triggering in AM. This mechanism ensures reliable reconstruction despite variable arrival due to radio variations. In AM mode specific to both and , an additional re-segmentation capability enhances efficiency for retransmissions triggered by partial (HARQ) failures at the MAC layer. When a previously transmitted AMD PDU (or segment thereof) requires retransmission but no longer fits the new MAC PDU size, the RLC entity re-segments it into smaller units, each retaining the original SN but with updated segmentation fields. There is no limit to the number of re-segmentation iterations, allowing flexible adaptation to changing channel conditions without discarding the entire PDU. This feature, absent in UM and Transparent Mode (TM), minimizes overhead in error-prone environments.

Automatic Repeat reQuest (ARQ)

In the Acknowledged Mode (AM) of the Radio Link Control (RLC) layer, (ARQ) implements a selective repeat mechanism to ensure reliable transfer of upper-layer Protocol Data Units (PDUs) over the radio interface. This approach retransmits only those PDUs or segments affected by errors, minimizing unnecessary overhead and preserving compared to go-back-N alternatives. The mechanism operates within a sliding window framework, where sequence numbers (SNs) track the order and status of transmitted data. The ARQ process relies on feedback via STATUS PDUs, which the receiver generates to report reception outcomes. Each STATUS PDU includes an ACK_SN field indicating the SN of the next expected PDU (all prior PDUs up to this SN are deemed successfully received) and one or more NACK_SN fields for missing PDUs, accompanied by segment offsets (SOstart and SOend) if partial segments are received. For efficiency, consecutive NACKs can be compressed into a range using an additional SO field, forming a bitmap-like that compactly identifies gaps in SNs without listing every acknowledged PDU individually. The transmitter uses this to selectively retransmit only the NACKed PDUs or segments, potentially re-segmenting them to fit current channel conditions. To elicit feedback, the transmitter sets the Polling (P) bit in the header of an Acknowledged Mode Data () PDU, prompting the receiver to transmit a PDU. Polling triggers are configurable, such as after a fixed number of PDUs or bytes sent. If no STATUS PDU arrives, the transmitter restarts the t-PollRetransmit and may retransmit the poll or data upon expiry. On the receiver side, the t-StatusProhibit enforces a minimum between STATUS PDUs to prevent excessive signaling overhead. These timers are configurable per RLC entity, allowing adaptation to varying radio conditions. The receiver may also trigger a STATUS PDU autonomously upon expiry of the t-Reassembly if gaps persist. The ARQ window size governs the maximum number of unacknowledged AMD PDUs the transmitter can send, calculated as \text{Window Size} = 2^{(\text{SN length} - 1)}, which is half the SN modulus to avoid ambiguity in ordering. In LTE, SN lengths of 10 bits or 16 bits yield window sizes of 512 or 32,768, respectively. In 5G NR, AM mode supports 12-bit or 18-bit SNs, resulting in window sizes of 2,048 or 131,072. Larger windows enable higher peak throughput by permitting more outstanding PDUs but increase buffer demands and potential reordering delays at the receiver. In error-prone channels, ARQ retransmissions enhance reliability but can degrade effective throughput by up to 20% relative to unacknowledged modes, as the additional round trips and overhead compound with higher-layer retransmissions. For NR's Ultra-Reliable Low-Latency Communications (URLLC), ARQ is enhanced with configurable shorter SN lengths—minimum 12 bits for AM—enabling smaller windows to minimize reassembly and buffer occupancy while supporting stringent reliability targets. This adaptation reduces in time-critical applications without compromising the selective repeat .

Duplicate Detection and Reordering

In the Radio Link Control (RLC) protocol, duplicate detection and reordering mechanisms ensure reliable data transfer by managing out-of-order Protocol Data Units (PDUs) and eliminating redundant receptions, primarily in Unacknowledged Mode (UM) and Acknowledged Mode (AM). These functions operate on incoming PDUs from the lower (MAC) layer, using Sequence Numbers (SNs) to maintain sequence integrity before delivery to the (PDCP) layer as Service Data Units (SDUs). Reordering buffers received PDUs that arrive out of sequence due to varying transmission paths or retransmissions, assembling them into in-sequence SDUs for PDCP delivery. Upon PDU reception, the RLC entity compares the SN against state variables defining the receiving —such as VR(UR) and VR(UH) in UM mode, or RX_Next and RX_Next_Highest in —to determine if the SN falls within the active window. If within the window and not a duplicate, the PDU is buffered; otherwise, it is discarded. A configurable reordering (e.g., t-Reordering in / or t-Reassembly in ) starts when gaps in the sequence are detected and triggers delivery of all buffered SDUs up to the highest consecutive SN upon expiry, ensuring timely forwarding even if some PDUs are delayed. This timer value is set by higher-layer signaling, balancing latency and reliability. Duplicate detection prevents processing of redundant PDUs, which could arise from retransmissions or loop avoidance in multi-path scenarios, by discarding any PDU whose SN matches one already processed within the receiving window. In UM and AM modes, the receiver checks if the SN has been previously acknowledged or buffered— for instance, in LTE AM, discarding occurs if byte segments corresponding to the SN were already received—thus avoiding unnecessary resource consumption and potential infinite loops. This logic integrates with SN comparison: a PDU is accepted for buffering or immediate delivery only if its SN is within the window, greater than or equal to the next expected SN, and not previously handled. In 5G NR, enhancements allow partial SDU delivery to PDCP as soon as all segments of an individual SDU are available, reducing latency for applications like URLLC without waiting for full sequence completion.

Protocol Mechanisms

Service Data Units (SDUs) and Protocol Data Units (PDUs)

In the Radio Link Control (RLC) layer of New Radio (NR), a (SDU) refers to the data unit received from the upper (PDCP) layer, known as an RLC SDU, which is byte-aligned and of variable size. Upon processing, the RLC delivers a reassembled RLC SDU to the PDCP layer as its output SDU. A (PDU) in the RLC layer is the formatted data unit submitted to the lower (MAC) layer, termed an RLC PDU, which may encapsulate one or more RLC SDUs or segments thereof. Conversely, the RLC receives PDUs from the MAC layer via logical channels, treating them as incoming RLC PDUs for processing. In Acknowledged (AM) and Unacknowledged (UM), RLC PDUs incorporate headers to support operations like segmentation, while Transparent (TM) PDUs do not. RLC SDUs and PDUs exhibit variable lengths to accommodate flexible data handling, with sizes aligned to MAC layer capabilities for efficient transmission. In LTE, RLC PDU sizes are variable, aligned to MAC transport block limits, which can exceed 6000 bytes in certain configurations. In NR, the maximum data field size in an RLC PDU corresponds to the PDCP PDU size, which can reach up to 9000 bytes or more depending on configuration. The RLC performs key transformations between SDUs and PDUs: upon transmission, a single RLC SDU may be segmented into multiple RLC PDUs if it exceeds the available transmission opportunity size, with headers added to enable reassembly. At the receiver, reassembly reconstructs the original RLC SDU from the received RLC PDUs, ensuring complete data delivery to the PDCP layer.

Header Structure

The Radio Link Control (RLC) layer employs distinct header formats tailored to its operational modes, ensuring efficient transmission of service data units (SDUs) across the radio interface in cellular networks such as and . These headers provide essential metadata for segmentation, sequencing, and control functions, with structures defined in technical specifications. In general, RLC headers consist of a fixed part containing core fields like sequence numbers (SN) and segmentation indicators, optionally followed by a variable extension part in earlier implementations for handling multiple segments. In Transparent Mode (TM), no RLC header is present, as the mode performs no segmentation, reassembly, or sequencing; the protocol data unit (PDU) comprises only the raw SDU data, byte-aligned for direct forwarding to the Medium Access Control (MAC) layer. For Unacknowledged Mode (UM) and Acknowledged Mode (AM) in LTE, the data PDU headers begin with a fixed part of 1 or 2 octets, incorporating framing information (FI), extension bits (E), and SN, followed by an optional variable part with length indicators (LI) for concatenated or segmented SDUs. The FI field (2 bits) specifies the boundaries of the first and last segments within the PDU—values of 00 indicate a full SDU, 01 a first byte of an SDU, 10 the last byte, and 11 both first and last. Extension bits (E, 1 bit each) signal whether additional LI fields follow, enabling support for multiple segments per PDU; each LI (11 or 15 bits, configurable) denotes the length in bytes of the preceding data field element. The SN provides ordering, with lengths of 5 or 10 bits in UM (configurable via RRC) and 10 bits in AM. A byte-level breakdown for a basic UM header with 5-bit SN appears as:
Octet 1: FI (bits 1-2) | E (bit 3) | SN (bits 4-8)
[Optional: Octet n: E (bit 1) | LI (bits 2-12) for each extension]
In AM, the fixed part extends to include a data/control indicator (D/C, 1 bit set to 1 for data), a reserved field (RF, 1 bit), and a polling bit (P, 1 bit to request status reports), followed by FI, E, and SN, with the variable part mirroring UM. In , header structures are simplified by relocating concatenation to the layer, eliminating the variable extension part and multiple LIs; instead, each PDU carries at most one SDU or segment, with segmentation handled via segment offset (SO). UM headers replace with segmentation information (SI, 2 bits: 00 for full SDU, 01 first segment, 10 last segment, 11 middle segment) and include a reserved bit (R, set to 0); SN lengths are optionally 6 or 12 bits (RRC-configured). SO (16 bits) appears only for non-first segments, indicating the byte offset from the SDU start (0-based). A representative UM header with 6-bit SN and no SO is:
Octet 1: SI (bits 1-2) | SN (bits 3-8)
[Optional: Octets 2-3: SO (16 bits) for non-first segments]
For 12-bit SN without SO, the header spans two octets: Octet 1: SI (bits 1-2) | SN (bits 3-8); Octet 2: SN (bits 1-6) | R (bits 7-8). With SO, additional two octets follow for SO (16 bits). AM data headers prepend D/C (1 bit, 1 for data), P (1 bit), and SI (2 bits) to the SN (optionally 12 or 18 bits), with R bits for alignment and optional SO; the fixed part spans 2-3 octets without extensions. For AM control PDUs (status PDUs), a separate format includes D/C (0), control PDU type (CPT, 4 bits), acknowledged SN (ACK_SN, matching SN length), and a bitmap-like structure of negative acknowledgments (NACKs) via extension bits (E1/E2/E3, 1 bit each) indicating presence of NACK_SN (SN of missing PDU) and SOstart/SOend for segment-level NACKs. These mode-specific headers integrate with PDUs to enable mode-appropriate processing, such as sequencing in UM/AM without the full procedural overhead of TM.

Reset and Re-establishment Procedures

In the Acknowledged Mode (AM) of the Radio Link Control (RLC) protocol, the reset procedure serves to synchronize the transmitting and receiving sides following detection of unrecoverable errors, ensuring both entities reset their states and buffers without data loss where possible. This procedure is triggered either by an upper layer request or when the transmitting AM RLC entity has performed retransmissions of an RLC Data PDU up to the configured maximum count (RETX_COUNT) without receiving an acknowledgment. Upon trigger, the transmitting side initiates the procedure by forming and submitting a RESET Protocol Data Unit (PDU) to the lower layer for transmission, where the Reset Sequence Number (ResetSN) is set to the transmitting state variable VT(S); it then discards all RLC Service Data Units (SDUs), RLC SDU segments, and RLC PDUs from its transmission buffer, resets the acknowledgment state variable VT(A) and VT(S) to 0, stops any running poll retransmission timer (t-PollRetransmit), and starts the reset timer (t-Reset). If t-Reset expires before receiving a RESET ACK PDU, the transmitter retransmits the RESET PDU up to a maximum number of attempts; upon successful reception of the RESET ACK, it stops t-Reset, completing the reset. On the receiving side, upon detection of a PDU, the AM RLC entity verifies that the received ResetSN equals its receiving VR(R); if valid, it forms and submits a ACK PDU to the lower layer with the same ResetSN, discards all RLC SDUs, RLC SDU segments, and RLC PDUs from its reception , resets VR(R), VR(MR), and VR(X) to 0, stops all running timers, and ignores any subsequent PDUs with the same ResetSN to prevent loops. This exchange ensures both sides flush their buffers and synchronize sequence numbering, minimizing disruptions while the receiver acknowledges the reset to confirm alignment. The procedure applies exclusively to AM mode and uses timer-based operation, with t-Reset configurable to values such as 10-200 ms depending on deployment, to balance reliability and . The re-establishment procedure, applicable across Transparent Mode (TM), Unacknowledged Mode (UM), and AM, is invoked by upper layers such as the Radio Resource Control (RRC) layer during events like handovers, radio link failure recovery, or reconfiguration, to reset the RLC entity and restore operational state while attempting to deliver any outstanding data. For the transmitting side in all modes, the procedure discards all RLC SDUs, RLC SDU segments, and RLC PDUs in the transmission buffer. On the receiving side, it prioritizes reassembly: in TM, all data is discarded immediately; in UM, RLC SDUs are reassembled from Unacknowledged Mode Data (UMD) PDUs with Sequence Numbers (SN) less than the highest received state variable VR(UH), delivered to the upper layer in ascending order, with remaining PDUs discarded; in AM, RLC SDUs are similarly reassembled from Acknowledged Mode Data (AMD) PDUs with SN less than VR(MR), delivered sequentially, and any unassembled segments or PDUs discarded. Following these actions, all timers (e.g., t-Reordering) are stopped and reset, and state variables are initialized to their starting values (e.g., VR(R) = 0 in AM), enabling the RLC entity to resume with clean buffers and synchronized counters. This design, specified for both LTE and 5G NR, emphasizes minimizing data loss by delivering reassemblable SDUs before full reset, and is confined to scenarios requiring entity reconfiguration without ongoing PDU exchanges like the AM reset. In , the re-establishment procedure subsumes needs previously handled by a distinct in , with upper layers requesting it to discard all RLC SDUs, segments, and PDUs, stop and timers (e.g., t-Reassembly, t-PollRetransmit), and initialize variables (e.g., TX_Next = 0, RX_Next_Reass = 0) across modes, ensuring rapid from failures like without dedicated control PDUs for . This timer-driven approach (with durations like 10-200 ms for related ARQ timers) applies primarily in AM for error but supports all modes, promoting through buffer clearance and variable resets to avoid residual errors.

Comparisons and Enhancements

RLC in LTE versus 5G NR

The Radio Link Control (RLC) protocol in 5G New Radio (NR) builds upon the LTE foundation with enhancements aimed at supporting diverse service requirements, including ultra-reliable low-latency communication (URLLC). A primary evolution is in sequence number (SN) sizing: 5G NR employs 12 or 18 bits for acknowledged mode (AM) PDUs and 6 or 12 bits for unacknowledged mode (UM) PDUs, enabling a larger transmission window (up to 131072 for AM) to accommodate higher throughput scenarios, whereas LTE uses 10 bits for AM and 5 bits for UM, limiting the window to 512. This expansion in 5G NR reduces the risk of window exhaustion in high-data-rate environments without frequent resets. In UM operation, RLC facilitates of service data units (SDUs) to the upper layers immediately upon reassembly, managed via a configurable reassembly window (UM_Window_Size of 32 for 6-bit SN or 2048 for 12-bit SN), which minimizes delays from awaiting lost PDUs. LTE UM, by contrast, enforces in-sequence delivery by default via the t-Reordering timer, potentially introducing buffering delays unsuitable for latency-sensitive traffic. For AM efficiency, incorporates adaptive polling mechanisms triggered by PDU counts (pollPDU threshold) or byte volumes (pollByte threshold), alongside SN-based thresholds like POLL_SN (the highest SN submitted at poll time), allowing finer control over status report generation to balance reliability and overhead. These build on LTE's similar but coarser pollPDU and pollByte parameters, which lack the extended SN granularity for dynamic adjustment. Additionally, LTE's reordering relies on a t-Reordering with coarser granularity (typically 5-100 ms steps), whereas 's t-Reassembly offers finer flexibility, including 0 ms settings, to align with URLLC's sub-millisecond needs without compromising detection. Architecturally, RLC resides in the gNB distributed unit (DU), integrating seamlessly with the (CU)-DU via the F1 , where PDCP and higher layers are centralized in the CU for resource pooling and ; this enables efficient scaling in cloud-native deployments. , lacking a native CU-DU , relies on monolithic implementations, complicating distributed processing. Furthermore, while supports sidelink via UM RLC for device-to-device (e.g., ), it does not provide native integration comparable to NR's enhanced PC5 sidelink RLC for V2X, which includes mode-specific optimizations. In AM, 5G NR's optimized status reporting—leveraging re-segmentation of PDUs and priority handling for control messages—contributes to latency reductions over equivalents, particularly in retransmission scenarios, by streamlining feedback and reducing buffer sojourn times.

Integration with Upper and Lower Layers

The Radio Link Control (RLC) layer interfaces with the (PDCP) layer above it, ensuring reliable and ordered delivery of service data units (SDUs). In acknowledged mode (AM), the receiving RLC entity reassembles PDCP PDUs into complete SDUs and delivers them to the PDCP layer in sequence once all bytes are correctly received, using the RX_Next to maintain order and discard out-of-order or duplicate data. In unacknowledged mode (UM), SDUs are delivered to PDCP as soon as they are available after reassembly, without sequencing guarantees. Ciphering and Robust Header Compression (ROHC) are performed by the PDCP layer following SDU delivery from RLC in the receiver path, enabling secure and efficient header processing post-reassembly; this configuration applies in standard bearer setups, while split bearers may involve multiple RLC entities feeding into a single PDCP. Additionally, PDCP notifies the RLC layer of SDU discards via a discard or explicit indication, preventing transmission of obsolete data and avoiding sequence number gaps in AM mode if the SDU has not yet been submitted to the lower layers. At the lower interface, RLC interacts with the (MAC) layer by mapping its protocol data units (PDUs) to specific logical channels, such as the Dedicated Control Channel (DCCH) for signaling and the Dedicated Traffic Channel (DTCH) for user data in AM and UM modes, enabling prioritized scheduling and resource allocation. The MAC layer's (HARQ) feedback mechanism influences RLC operations, as failed HARQ deliveries prompt RLC to trigger retransmissions via status PDUs, potentially requiring re-segmentation of SDUs to fit available transport block sizes and adapt to varying channel conditions. In New Radio (NR), RLC supports the Service Data Adaptation Protocol (SDAP) by processing data within Data Radio Bearers (DRBs) that carry QoS flows mapped by SDAP, ensuring segmentation, reassembly, and error correction align with QoS requirements like and reliability for multiplexed flows. Enhancements for reliability include PDCP duplication, where a single PDCP entity associates with multiple RLC entities (up to eight in UM), allowing duplicated SDUs to be transmitted across parallel RLC paths for aggregation and improved robustness against failures. In dual connectivity scenarios, such as Multi-RAT Dual Connectivity (MR-DC), RLC aids split bearer handling by configuring separate RLC entities for the Master (MCG) and Secondary (SCG), enabling PDCP to route or duplicate data across legs while RLC manages per-leg reordering, ARQ, and re-establishment during node changes or security updates to maintain bearer continuity.

References

  1. [1]
    Radio Link Control - an overview | ScienceDirect Topics
    The RLC Layer is responsible for transfer of upper layer PDUs, concatenation, segmentation and reassembly of RLC SDUs. The RLC also performs error corrections ...
  2. [2]
    Specification # 25.322 - 3GPP
    Jul 4, 2017 · Radio Link Control (RLC) protocol specification. Status: Under change control. Type: Technical specification (TS). Initial planned Release ...
  3. [3]
    5G System Overview - 3GPP
    Aug 8, 2022 · 3GPP defines not only the air interface but also all the protocols and network interfaces that enable the entire mobile system: call and session ...
  4. [4]
    None
    ### Summary of RLC Sublayer from ETSI TS 138 322 V17.2.0
  5. [5]
    None
    Below is a merged summary of the RLC Layer Configuration and Operation based on ETSI TS 138 300 V17.6.0, consolidating all provided segments into a comprehensive response. To retain all details efficiently, I will use a structured format with tables where appropriate, followed by a narrative summary for additional context. The response avoids any "thinking tokens" and focuses solely on presenting the information.
  6. [6]
    [PDF] ETSI TS 125 322 V3.1.2 (2000-01)
    Upon reception of an CRLC-CONFIG-Req from higher layer the RLC entity is terminated and the null state is entered. (3G TS 25.322 version 3.1.2 Release 1999).Missing: origins | Show results with:origins
  7. [7]
    UMTS Protocols and Protocol Testing - Tektronix
    The most important evolutionary step of GSM towards UMTS is GPRS. GPRS ... Radio Link Control (RLC) [3G TS 25.322] is responsible for acknowledged or ...
  8. [8]
    Specification # 36.322 - 3GPP
    Aug 27, 2019 · Reference: 36.322. Title: Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Link Control (RLC) protocol specification.
  9. [9]
    [PDF] ETSI TS 136 300 V16.8.0 (2022-05)
    This Technical Specification (TS) has been produced by ETSI 3rd Generation Partnership Project (3GPP). The present document may refer to technical ...
  10. [10]
    [PDF] ETSI TS 136 322 V8.8.0 (2010-07)
    The following functions are supported by the RLC sub layer: - transfer of upper layer PDUs;. - error correction through ARQ (only for AM data transfer);. Page ...
  11. [11]
    [PDF] TS 136 322 - V15.1.0 - LTE - ETSI
    Radio Link Control (RLC) protocol specification. (3GPP TS 36.322 version 15.1.0 Release 15). TECHNICAL SPECIFICATION. Page 2. ETSI. ETSI TS 136 322 V15.1.0 ( ...
  12. [12]
    [PDF] TS 136 322 - V8.2.0 - LTE - ETSI
    When indicated from upper layer (i.e. PDCP) to discard a particular RLC SDU, the transmitting side of an AM RLC entity or the transmitting UM RLC entity shall ...Missing: evolutions | Show results with:evolutions
  13. [13]
    Specification # 38.322 - 3GPP
    Mar 22, 2017 · 38.322. Title: NR; Radio Link Control (RLC) protocol specification. Status: Under change control. Type: Technical specification (TS). Initial ...
  14. [14]
    [PDF] ETSI TS 138 322 V15.3.0 (2018-09)
    3GPP TS 38.322 version 15.3.0 Release 15. 1. Scope. The present document specifies the NR Radio Link Control (RLC) protocol for the UE – NR radio interface. 2.
  15. [15]
    5G/NR RLC - ShareTechnote
    NR RLC has three different mode : TM(Transparent Mode), UM(Unacknowledge Mode) and AM(Acknowledge mode). The details of each of these mode will be described ...
  16. [16]
    5G NR RLC Acknowledged Mode - Medium
    Oct 4, 2019 · Here we will take a deep dive into the RLC AM procedures. The procedures are explained with flow charts that are based on the 3GPP specification 38.322 V15.5.0.Missing: length | Show results with:length
  17. [17]
    5G NR RLC PDU - Devopedia
    Mar 20, 2021 · 3GPP publishes Release 15 "early drop". RLC specification TS 38.322 is updated to version 15.0.0. This version includes header fields SI , ...
  18. [18]
    [PDF] V2X in 3GPP Standardization: NR Sidelink in Rel-16 and Beyond
    Apr 22, 2021 · The main part of this work belongs to the 3GPP Rel-16, which is the first 3GPP release for NR-V2X, and the work/study items of the future Rel-17 ...
  19. [19]
    Non-Terrestrial Networks (NTN) - 3GPP
    May 14, 2024 · The WG RAN2 led Release 18 WI "NR NTN (Non-Terrestrial Networks) enhancements" (NR_NTN_enh) had the goal to enhance NTN related features ...
  20. [20]
    [PDF] 3GPP Release 18 Overview: A World of 5G-Advanced - ATIS
    Feb 2, 2023 · WI: NR NTN (Non-Terrestrial Networks) enhancements. Coverage enhancements: repetition for PUCCH msg4, support of DMRS bundling, protocol ...
  21. [21]
    [PDF] ETSI TS 138 322 V17.3.0 (2023-07)
    The transmitting side of an AM RLC entity supports retransmission of RLC SDUs or RLC SDU segments (ARQ):. - if the RLC SDU or RLC SDU segment to be ...
  22. [22]
    [PDF] ETSI TS 136 322 V18.0.0 (2024-05)
    Radio Link Control (RLC) protocol specification. (3GPP TS 36.322 version 18.0.0 Release 18). TECHNICAL SPECIFICATION. Page 2. ETSI. ETSI TS 136 322 V18.0.0 ( ...
  23. [23]
    [PDF] ETSI TS 138 322 V18.2.0 (2025-01)
    [5]. 3GPP TS 38.331: "NR RRC Protocol specification". [6]. 3GPP TS 23.287: "Architecture enhancements for 5G System (5GS) to support Vehicle-to-. Everything ( ...
  24. [24]
    [PDF] Radio Link Control and Logical Channel Prioritization in 5G NR
    May 10, 2019 · [2] Radio Link Control (RLC) Protocol Specification (TS 38.322 V15.5.0), April 2019. [3] Medium Access Control (MAC) Protocol Specification (TS ...
  25. [25]
    [PDF] ETSI TS 138 322 V18.0.0 (2024-05)
    An UM RLC entity can be configured to submit/receive RLC PDUs through the following logical channels: Page 11. ETSI. ETSI TS 138 322 V18.0.0 (2024-05). 10. 3GPP ...Missing: NTN | Show results with:NTN
  26. [26]
    [PDF] Performance Analysis of Transport Protocols and RLC Modes in 5G ...
    The RLC is completely transparent in TM mode, meaning it is essentially ... [3] 3GPP, “TS 38.322 v17.4.0,” Radio Link Control (RLC) Protocol Spec ...
  27. [27]
    [PDF] ETSI TS 125 322 V18.0.0 (2024-05)
    When configured, duplicate avoidance and reordering is the first receive function that is applied to the input UMD PDU streams in the receiving UM RLC entity.
  28. [28]
    [PDF] ETSI TS 138 322 V16.1.0 (2020-07)
    ETSI TS 138 322 V16.1.0 (2020-07). 5G;. NR;. Radio Link Control (RLC) protocol specification. (3GPP TS 38.322 version 16.1.0 Release 16). TECHNICAL ...
  29. [29]
    [DOC] 36322-f20.docx - 3GPP
    The transmitting side of an AM RLC entity supports retransmission of RLC data PDUs (ARQ):. - if the RLC data PDU to be retransmitted does not fit within the ...
  30. [30]
    [PDF] TS 138 323 - V16.6.0 - 5G; NR - ETSI
    The maximum supported size of a PDCP Control PDU is. 9000 bytes. 4.3.2 ... - submit the PDCP PDU to either the primary RLC entity or the split secondary RLC ...<|control11|><|separator|>
  31. [31]
    [PDF] ETSI TS 136 322 V16.0.0 (2020-07)
    When forming a new AMD PDU segment, the transmitting side of an AM RLC entity shall: - only map the Data field of the original AMD PDU to the Data field of the ...
  32. [32]
    [PDF] TS 136 322 - V12.3.0 - LTE - ETSI
    If t-Reordering is running, t-Reordering shall not be started additionally, i.e. only one t-Reordering per RLC entity is running at a given time. c) t ...
  33. [33]
    5G-NR RLC Timers, Constants & Configurable Parameters - LinkedIn
    Jan 22, 2023 · Started when the STATUS PDU is sent. Expiry of t-Reassembly triggers a status report but STATUS PDU is sent only when t-StatusProhibit expires.
  34. [34]
    [PDF] TS 138 401 - V15.2.0 - 5G; NG-RAN - ETSI
    gNB Distributed Unit (gNB-DU): a logical node hosting RLC, MAC and PHY layers of the gNB or en-gNB, and its operation is partly controlled by gNB-CU. One gNB-DU ...<|separator|>
  35. [35]
    [PDF] Preventing RLC Buffer Sojourn Delays in 5G - Eurecom
    The results reveal current 3GPP deficits in its QoS model to address the bufferbloat and the contribution of the segmentation/reassembly procedure to the total ...<|control11|><|separator|>
  36. [36]
    [PDF] ETSI TS 138 322 V18.1.0 (2024-08)
    When retransmitting an RLC SDU or an RLC SDU segment, the transmitting side of an AM RLC entity shall: - if needed, segment the RLC SDU or the RLC SDU segment; ...Missing: URLLC massive IoT
  37. [37]
    None
    Summary of each segment:
  38. [38]
    None
    Below is a merged summary of the RLC role in QoS Flow Mapping with SDAP and Dual Connectivity Split Bearers, consolidating all information from the provided segments into a dense and comprehensive response. To maximize detail retention, I’ve organized key information into tables where appropriate (in CSV-like format for clarity), while maintaining a narrative structure for overarching concepts. All unique details, including section references and URLs, are preserved.
  39. [39]
    None
    Below is a merged summary of the role of RLC (Radio Link Control) in Multi-Radio Dual Connectivity (MR-DC), focusing on split bearer handling and re-establishment. The information is consolidated into a dense, structured format, including a table in CSV format to capture detailed aspects efficiently. All key points from the provided segments are retained, with references to useful URLs at the end.