5G RLC Protocol

Quick facts

RLC Topics

Overview and Protocol Stack | RLC Architecture | Procedures | ARQ Procedures | Transparent Mode | Unacknowledged Mode | Acknowledged Mode | PDU Formats and Parameters | Variables, Constants, and Timers | Troubleshooting and Trace Analysis

Contents

1. Overview
2. Position in the stack
3. RLC transmission modes
4. RLC architecture overview
5. Core services and functions
6. Procedures overview
7. ARQ procedures overview
8. RLC PDU formats and parameters
9. Variables, constants, and timers
10. RRC-side configuration of RLC
11. How to read RLC in traces
12. Related pages
13. References
14. FAQ

RLC topic map

Use this page as the top-level RLC reference. Start with stack position and transmission mode, then move through architecture, procedure families, ARQ behavior, PDU formats, variables, timers, and trace-analysis branches in the same broad order used by TS 38.322. When the question starts from bearer setup rather than live trace behavior, pair this page with RRC and radio bearers.

Overview

RLC is the sublayer that turns upper-layer PDUs into radio-transfer units suited to the active bearer mode and the transmission opportunities provided by MAC. It is where segmentation and reassembly become visible, where sequence numbers are applied, and where reliable delivery is enforced for AM bearers.

In practical analysis, RLC is the layer you inspect when the symptom sounds like this: data stalled even though MAC kept scheduling, reassembly did not complete, missing sequence numbers caused STATUS traffic, or a bearer behaved differently because it was configured for UM instead of AM.

Position in the stack

In NR, RLC sits below PDCP and above MAC for both SRBs and DRBs. It does not schedule radio resources itself and does not perform physical retransmission. Instead, it prepares or interprets the protocol units that MAC can send when radio resources are available.

Note: Read RLC and MAC together whenever the symptom is latency growth, bursty delivery, stalled reassembly, or repeated STATUS PDUs. RLC exposes the delivery consequence, while MAC and PHY usually explain why the transport opportunities or radio outcomes created that consequence.

RLC transmission modes

The first RLC question is always mode selection. NR uses three transmission modes, and each one implies a very different trace pattern, buffering model, and reliability expectation. If the bearer role is still unclear, check the radio bearer view before judging the mode behavior.

RLC architecture overview

RLC architecture is a major part of TS 38.322 because it defines the protocol model before any individual procedure is interpreted. The architecture view explains the relationship between transmitting and receiving RLC entities, the logical-channel and bearer context attached to those entities, and the boundaries toward PDCP and MAC.

This topic matters because mode choice, bearer mapping, window behavior, and later procedure interpretation all depend on the architecture first. If the entity type or bearer context is misunderstood, later conclusions about data transfer, discard, retransmission, or recovery are usually wrong. This is especially important across the F1 split, where lower-layer execution may sit away from the control-plane decision point.

Core services and functions

The main RLC functions are mode-dependent, but the protocol family is organized around a consistent set of jobs: move upper-layer data across the radio bearer, adapt it to available transport opportunities, and recover or discard data when the configured mode requires it. When the setup itself is in question, correlate this view with RRC Setup and later RRC messages.

Procedures overview

RLC procedures define how a configured entity behaves over time. This includes entity handling, data transfer, reassembly, SDU discard, re-establishment, release-related clearing, and protocol error handling. Read this section when the question is about behavior and transition logic rather than only static structure or field meaning.

In traces, many RLC faults appear first as procedure behavior. A bearer may look correct in architecture terms but still fail because reassembly did not complete, discard rules removed buffered data, or re-establishment cleared state after a higher-layer event. The procedure view makes those transitions easier to identify, especially when combined with variables and timers.

ARQ procedures overview

ARQ procedures are a dedicated part of the RLC procedure model in AM. They cover how the transmitter polls for receiver status, how the receiver builds STATUS PDUs, how missing sequence ranges are reported, and how retransmission continues until acknowledgment or retransmission-limit conditions are reached.

This topic matters because ARQ is where reliable RLC delivery becomes operationally visible. It is also the part of the protocol most often exposed in traces when lower-layer HARQ is no longer enough to hide persistent loss, reordering, or transport instability. That is the point where PHY, MAC, and RLC troubleshooting need to be read together.

Note: When a trace shows heavy AM STATUS exchange, check the PHY and MAC view before blaming only RLC. RLC ARQ is often the symptom that remains visible after the lower layers could not complete delivery cleanly.

RLC PDU formats and parameters

TS 38.322 organizes the protocol around both PDU formats and their associated parameters. TM uses TMD PDUs, UM uses UMD PDUs, and AM uses AMD PDUs plus STATUS PDUs for feedback. Reading the format correctly is necessary before timer, window, retransmission, or mode interpretation makes sense. The format view becomes much more useful once it is paired with ARQ procedures and control values.

The main parameters tied to these formats include sequence-number length, segmentation indicators, segment offset, polling control, ACK or NACK interpretation, and the mode-specific rules that determine whether a field is even valid in the current bearer. These are the fields that usually decide whether a decode is meaningful in a trace.

Variables, constants, and timers

TS 38.322 defines RLC through variables, constants, and timers as much as through message structure. Sequence- number size affects the windows, mode-specific variables track progression through those windows, constants define operational bounds, and timers decide how long the entity waits before declaring a reassembly or polling-related event.

Release note: This hub follows a Release 18 baseline. Release evolution adds wider NR feature context such as sidelink, relay, IAB, and multicast or broadcast extensions, but the first reading path here stays on the core terrestrial RLC model used in mainstream NR bearer behavior.

RRC-side configuration of RLC

RLC behavior is not interpreted correctly unless the RRC configuration is known. RRC defines the bearer, the RLC mode, the relevant SN size, and the timer or polling thresholds that shape AM and UM behavior. In daily analysis, the real question is often not whether RLC retransmitted, but whether it was configured to do so with the values the trace is showing. That usually starts in RRC message content and often first appears during RRC Setup.

How to read RLC in traces

Good RLC troubleshooting starts by identifying the mode, confirming the configured timers, and then separating three different failure patterns: missing radio delivery below RLC, normal loss-tolerant UM behavior, and AM retransmission loops that still cannot complete delivery. When the service symptom stretches beyond the radio bearer itself, correlate the trace with the wider procedure, such as 5G Initial Registration.

Note: For RLC, the most common diagnosis mistake is to interpret AM symptoms without first checking whether the bearer was actually configured for AM. The second most common mistake is to blame RLC when the real root cause is repeated HARQ failure or unstable MAC scheduling below it.

References

• 3GPP TS 38.322 V18.0.0, NR Radio Link Control (RLC) protocol specification
• 3GPP TS 38.300 V19.2.0, NR and NG-RAN overall description
• 3GPP TS 38.331 V18.5.1, NR Radio Resource Control (RRC) protocol specification

FAQ

Where does RLC sit in the 5G NR stack?

RLC sits between PDCP and MAC in Layer 2 for both control-plane and user-plane radio bearers.

Which bearers use TM, UM, and AM in NR?

SRB0 and paging or broadcast related transport use TM, other SRBs use AM, and DRBs use either UM or AM depending on the service requirements.

What should I open first for RLC retransmission problems?

Start with the AM view and the timer or configuration page, then correlate it with MAC and PHY if repeated retransmissions do not resolve.

Why can RLC delay delivery even when packets are still arriving?

Because missing segments, window limits, or timer-controlled reassembly waiting can stop upper-layer delivery until the missing data arrives or recovery rules fire.

Why is RRC important for RLC analysis?

Because RRC defines the RLC mode, sequence-number size, and key timer and polling parameters that determine how the entity behaves in the trace.

Related pages