Skip to content

RLC

Summary
  • RLC (Radio Link Control) sits below PDCP and above MAC — the layer that turns PDCP's arbitrarily-sized SDUs into pieces that actually fit whatever Transport Block size MAC has scheduled for this TTI.
  • It operates in one of three modes per bearer, each trading off reliability against overhead and latency: TM (Transparent Mode), UM (Unacknowledged Mode), and AM (Acknowledged Mode).
  • Only AM does retransmission — that's RLC's own ARQ (Automatic Repeat reQuest), independent of and complementary to HARQ down at the MAC/PHY level.

Think of RLC as:

"The layer that packs and unpacks boxes to fit whatever truck MAC has waiting this millisecond — and, if you paid for tracked shipping (AM), the layer that notices a box went missing and sends a replacement."

If you are confused...

RLC picks up right where PDCP leaves off. PDCP hands RLC an SDU of whatever size it happens to be; RLC's job is entirely about fitting that into the radio, not about security or compression — those stay up at PDCP. And you've actually already seen RLC's mode assignments without knowing it: every row in the RRC message catalog with "TM" or "AM" in its Configuration column was telling you which RLC mode carries that message. MAC isn't covered on this site yet.

RLC in the Protocol Stack

Overview Model of the RLC Sub Layer

Figure 1. Overview Model of the RLC Sub Layer1 2

PDCP delivers SDUs of whatever size the application produced. MAC, on the other hand, works in Transport Block sizes that are decided dynamically, every TTI, based on current radio conditions. RLC exists specifically to bridge that mismatch — segmenting large SDUs to fit, and reassembling them at the other end.

Segmentation is MAC-size driven, not SDU-size driven

RLC doesn't segment based on the SDU's own size — it segments based on whatever space MAC has actually granted it right now. This is why RLC behavior visibly changes with radio conditions: in poor conditions, MAC allocates smaller Transport Blocks, so you'll see more aggressive segmentation even for the same SDU size.

RLC Modes at a Glance

Mode
 Entity Type ARQ (Retransmission) Typical Use
TM — Transparent Mode Unidirectional (Tx or Rx) No Broadcast/paging channels, and SRB0 (CCCH) before any dedicated config exists
UM — Unacknowledged Mode Unidirectional (Tx or Rx) No DRBs where retransmission delay would hurt more than occasional loss (e.g., VoNR)
AM — Acknowledged Mode Bidirectional Yes SRB1/SRB2 always, and most DRBs needing reliable delivery

Table 1. RLC Modes Summary

If you know networking protocols...

Each RLC mode maps loosely onto a familiar transport-layer analogy — loosely, because RLC is a Layer 2, single-hop protocol between the UE and one gNB, not an end-to-end Layer 4 protocol like TCP/UDP. Take it for the intuition, not the spec:

RLC Mode Closest Networking Analogy Why
TM Below UDP — a raw pipe No header at all, not even a sequence number. There's nothing to strip on the way out, because nothing was ever added on the way in.
UM UDP, or more precisely RTP-over-UDP Sequence numbers for loss/reorder detection, but no ACK and no retransmission — fire and forget. This is exactly why UM is what carries VoNR: RTP already tolerates loss better than it tolerates the delay a retransmission would add.
AM TCP — specifically TCP with Selective ACK (SACK) The STATUS PDU's ACK_SN plus an explicit list of NACK_SNs is structurally the same idea as TCP SACK blocks: don't just say "I got up to N," say exactly which pieces are missing so only those get resent.

Table 2. RLC Mode Networking Analogy

TM: Transparent Mode

Model of two transparent mode peer entities

Figure 2. Model of two transparent mode peer entities2

A TM entity is unidirectional — an RLC entity is configured as either a transmitting TM entity or a receiving TM entity, never both at once. It does essentially nothing to the data passing through it.

TM really means minimal processing

A TM RLC entity does essentially nothing to the data — no header, no segmentation, no sequence numbering. It exists purely because RLC is the layer conventionally responsible for handing data to MAC, even when nothing RLC-specific needs to happen to it.

Functions that actually run in TM: transfer of upper-layer PDUs, and RLC re-establishment. That's it — no sequence numbering, no segmentation, no reassembly, no ARQ.

PDU Type Header Fields Notes
TMD PDU None The SDU is transmitted as-is — the entire PDU is the Data field

Table 3. RLC Transparent Mode (TM) PDU Structure

TMD PDU

Figure 3. TMD PDU2

Where you'll find it: broadcast/paging channels (BCCH over PCH, PCCH), and SRB0 (CCCH) — because before an RRCSetup completes, there's no dedicated RLC configuration and no security context, so there's nothing for RLC to do besides pass the message through.

UM: Unacknowledged Mode

Model of two unacknowledged mode peer entities

Figure 4. Model of two unacknowledged mode peer entities2

Like TM, a UM entity is unidirectional — configured as either transmitting or receiving. Unlike TM, it does real work: it adds its own sequence number (independent of the PDCP SN), segments SDUs to fit the MAC grant, and reassembles them at the receiver — but it never asks for a retransmission, no matter what goes missing.

Functions that actually run in UM: transfer of upper-layer PDUs, sequence numbering, segmentation, reassembly, SDU discard, and RLC re-establishment. No ARQ, no re-segmentation, no duplicate detection, no protocol error detection — those are AM-only.

PDU Type Header Fields Notes
UMD PDU SN (6 or 12-bit), SI, SO (if segmented) SN length is configurable via RRC

Table 4. RLC Unacknowledged Mode (UM) PDU Structure

Where you'll find it: DRBs where the cost of waiting for a retransmission outweighs the cost of occasionally losing a piece of data — the canonical example is VoNR voice, carried as RTP over UM, since a late voice packet is often worse than a dropped one.

UMD PDU byte layout, by SN length and segmentation

A UMD PDU carrying a complete, unsegmented SDU doesn't need a Segment Offset (SO) field at all:

UMD PDU containing a complete RLC SDU

Figure 5. UMD PDU containing a complete RLC SDU2

Once an SDU is segmented, the layout depends on the configured SN length (6-bit or 12-bit) and whether this particular PDU carries the first segment (no SO needed) or a later one (SO required):

UMD PDU with 6 bit SN (No SO)

Figure 6. UMD PDU with 6-bit SN, no SO2

UMD PDU with 6 bit SN and with SO

Figure 7. UMD PDU with 6-bit SN, with SO2

UMD PDU with 12 bit SN (No SO)

Figure 8. UMD PDU with 12-bit SN, no SO2

UMD PDU with 12 bit SN and with SO

Figure 9. UMD PDU with 12-bit SN, with SO2

AM: Acknowledged Mode

Model of an acknowledged mode entity

Figure 10. Model of an acknowledged mode entity2

Unlike TM and UM, a single AM entity is bidirectional — it has both a transmitting side and a receiving side, because delivering reliably requires talking back to your peer. AM runs every function RLC has to offer: sequence numbering, segmentation and re-segmentation, reassembly, duplicate detection, protocol error detection, SDU discard, RLC re-establishment, and — the feature that defines it — error correction through ARQ.

PDU Type Header Fields Notes
AMD PDU D/C, P (poll bit), SI, SN (12 or 18-bit), SO (if segmented) A complete, unsegmented SDU is still sent as an AMD PDU (with SI = "complete") — AM has no separate "full SDU" format the way UM effectively does
STATUS PDU D/C, CPT, ACK_SN, NACK_SN(s), SOstart/SOend, E1/E2/E3 A Control PDU — this is how the receiver reports what it did and didn't get

Table 5. RLC Acknowledged Mode (AM) PDU Structure

Where you'll find it: SRB1/SRB2 always (RRC and NAS signalling needs guaranteed delivery), and most DRBs that need reliable delivery over low latency.

AMD & STATUS PDU byte layout, by SN length and segmentation

Like UMD PDUs, an AMD PDU only needs a Segment Offset (SO) field once the SDU has actually been segmented — otherwise the layout differs by whether the bearer is configured for a 12-bit or 18-bit SN:

AMD PDU with 12 bit SN (No SO)

Figure 11. AMD PDU with 12-bit SN, no SO2

AMD PDU with 12 bit SN with SO

Figure 12. AMD PDU with 12-bit SN, with SO2

AMD PDU with 18 bit SN (No SO)

Figure 13. AMD PDU with 18-bit SN, no SO2

AMD PDU with 18 bit SN with SO

Figure 14. AMD PDU with 18-bit SN, with SO2

STATUS PDUs follow the same SN-length split, since ACK_SN/NACK_SN need to be wide enough to reference any AMD PDU's SN:

STATUS PDU with 12 bit SN

Figure 15. STATUS PDU with 12-bit SN2

STATUS PDU with 18 bit SN

Figure 16. STATUS PDU with 18-bit SN2

ARQ & Timers

AM's reliability comes from polling + STATUS PDUs + retransmission:

  1. The transmitter periodically sets the Poll bit (P) on an AMD PDU — triggered by pollPDU/pollByte thresholds, or the retransmission timer — asking the receiver to report back.
  2. The receiver responds with a STATUS PDU, listing which SNs it has (ACK_SN) and which it's missing (NACK_SN, with SOstart/SOend for partial-segment losses).
  3. The transmitter retransmits whatever was NACKed — potentially re-segmenting it into smaller pieces if conditions have gotten worse since the original transmission.
Timer / Threshold           Purpose
t-PollRetransmit Re-triggers polling if no STATUS PDU arrives in time
t-Reassembly Bounds how long the receiver waits for a missing segment before giving up on that SDU
t-StatusProhibit Minimum gap enforced between consecutive STATUS PDU transmissions, to avoid flooding the uplink with status reports
pollPDU / pollByte PDU-count / byte-count thresholds that trigger setting the Poll bit
maxRetxThreshold Maximum retransmissions for a given PDU before RLC gives up

Table 6. RLC Acknowledged Mode (AM) Configuration Timers and Thresholds

When maxRetxThreshold is hit

If a PDU exceeds maxRetxThreshold, RLC declares failure and reports it upward — this is one of the triggers that can lead the UE into RRC re-establishment (RRCReestablishmentRequest), since RLC has effectively concluded the link can't reliably recover on its own.

Function Comparison Across Modes

For a side-by-side view of everything covered mode-by-mode above:2

Function TM UM AM
Transfer of upper layer PDUs ✅ ✅ ✅
Sequence numbering (independent of the PDCP SN) — ✅ ✅
Segmentation of RLC SDUs — ✅ ✅
Re-segmentation of RLC data PDUs — — ✅
Reassembly of SDUs — ✅ ✅
Error correction through ARQ — — ✅
Duplicate detection — — ✅
RLC SDU discard — ✅ ✅
RLC re-establishment ✅ ✅ ✅
Protocol error detection — — ✅

Table 7. Comparison of RLC Modes and Functions

Which Mode for Which Bearer

Bearer
 RLC Mode Why
SRB0 (CCCH) TM No security or reliability infrastructure exists yet — see RRC's message catalog
SRB1 / SRB2 AM RRC and NAS signalling always needs guaranteed delivery
DRB UM or AM SMF/PDCP configuration decides, based on the QoS flow's delay vs. reliability requirements

Table 8. Bearer Matching

Useful Resources

  • 3GPP TS 38.322 — NR RLC protocol specification: modes, functions, PDU formats, ARQ, timers
  • 3GPP TS 38.300 — NR overall description, protocol stack overview
  • ShareTechnote — 5G/NR: RLC

  1. Ryu, J. (n.d.). 5G/NR – RLC. ShareTechnote. https://www.sharetechnote.com/html/5G/5G_RLC.html ↩

  2. 3GPP. (n.d.). NR; Radio Link Control (RLC) protocol specification (Technical Specification TS 38.322). 3rd Generation Partnership Project. https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3195 ↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩↩