RLC Overview & Modes (TM / UM / AM) in 5G NR
The three RLC modes and which logical channels and services each one serves.
Sitting between PDCP above and MAC below, the RLC layer (TS 38.322) is the part of the NR stack that turns a stream of PDCP packets into pieces MAC can actually fit into a radio grant — and, when reliability matters, makes sure every piece arrives. It runs in one of three modes — TM, UM or AM — and which one a channel uses is a deliberate trade of overhead against reliability. Get the three modes straight and almost everything else about RLC falls into place.
Introduction
RLC (Radio Link Control), defined in TS 38.322, is the middle sublayer of the NR user-plane and control-plane L2 stack: it sits directly below PDCP and directly above MAC. Its job is to take the arbitrary-sized packets PDCP produces and turn them into pieces that fit whatever grant the MAC scheduler hands out slot by slot — and, for the traffic that needs it, to make sure nothing is lost.
There is exactly one RLC entity per logical channel per radio bearer, instantiated when RRC configures the bearer and torn down or reset (re-established) at handover and reconfiguration. So RLC is active for the whole life of every bearer a UE has: the signalling bearers that carry RRC, the data bearers that carry your traffic, and the common channels a UE reads before it even has a dedicated context. Every byte that goes up or down through a bearer passes through an RLC entity.
What makes RLC easy to reason about is that its entire behaviour is fixed by one choice: its mode. Transparent Mode does nothing but forward; Unacknowledged Mode numbers and segments but never resends; Acknowledged Mode adds a full retransmission engine on top. Pick the mode and you have fixed whether there is a header, whether there is a sequence number, whether segmentation runs, and whether an ARQ state machine runs. The rest of this page is those three modes and the functions they switch on.
On this page
Why RLC is needed
In plain words: RLC is the shipping-and-mail room between two floors that never agree on package size. PDCP upstairs hands down parcels of whatever size it likes; MAC downstairs only offers boxes of a size the scheduler picks fresh each slot. RLC cuts the parcels to fit the boxes (segmentation), numbers them so the far end can reassemble them in order, and — for registered mail (AM) — keeps a receipt book so anything lost gets sent again. For ordinary post (UM) it numbers and forwards but never chases a lost item; for a public notice on the wall (TM) it just posts it as-is.
Concretely, two mismatches must be bridged. First, size: PDCP produces packets of arbitrary length, while MAC hands out grants of whatever size the scheduler decides, slot by slot — so something has to segment upper-layer packets to fit and reassemble them on the far side. Second, reliability at the right latency: for signalling and TCP, recovering a loss locally at L2 is far faster than waiting for the endpoints to time out, but for real-time media a late retransmission is worthless. RLC's three modes exist precisely so each bearer can pick the reliability/latency trade it wants without changing anything above or below it.
What RLC is, and where it sits
RLC is a per-logical-channel entity. For every radio bearer that PDCP is running, there is exactly one RLC entity beneath it, configured for one mode. PDCP hands that entity RLC SDUs (each SDU is one PDCP PDU); the RLC entity packages them into RLC PDUs sized to whatever grant MAC offers, and on the receive side it puts them back together — in order or not, depending on mode — before delivering reassembled RLC SDUs up to PDCP. That is the whole job in one sentence: adapt upper-layer packets to the transport MAC can carry, and, in the reliable mode, guarantee they get there.
A layer-2 sublayer that transfers upper-layer PDUs, optionally numbers them, segments them to fit the grant, reassembles on receive, and — in one mode only — retransmits what is lost. One RLC entity exists per logical channel per bearer.
PDCP produces packets of arbitrary size; MAC hands out grants of whatever size the scheduler decides, slot by slot. Something has to bridge those two worlds and, for signalling and TCP, recover losses faster than the endpoints would. That is RLC.
RRC configures the mode and all timers/window sizes per logical channel through the RLC-Config IE. The mode fixes whether a header with a Sequence Number is present, whether segmentation runs, and whether an ARQ state machine runs.
The interface downward is the RLC channel — the logical connection between an RLC entity and its MAC entity for one logical channel. MAC multiplexes several RLC channels into one transport block and drives HARQ underneath; RLC never sees HARQ retransmissions, only the SDUs it is asked to deliver and the grant sizes it is offered. The interface upward is the SAP to PDCP. Because each layer keeps its own numbering and its own state, RLC and PDCP are cleanly decoupled: RLC's Sequence Number is independent of the PDCP SN, so RLC can reorder and reassemble on its own SN space without ever inspecting PDCP's.
SDU vs PDU, precisely: an RLC SDU is a payload received from PDCP (one PDCP PDU). An RLC PDU is what RLC sends to MAC — either a whole SDU or a single segment of one, plus (in UM/AM) an RLC header. In NR one RLC PDU never carries more than one SDU or SDU-segment. Data PDUs carry payload; in AM there are also control PDUs (the STATUS PDU) that carry no user data at all.
The three modes, at a glance
The entire personality of an RLC entity — whether it adds a header, whether it numbers packets, whether it retransmits — is fixed by its mode. There are exactly three, and they form a neat ladder of capability: each mode simply adds machinery on top of the one before it.
Transparent Mode (TM): pass-through, no header. Unacknowledged Mode (UM): numbered, segments/reassembles, never resends. Acknowledged Mode (AM): everything UM does, plus ARQ retransmission and status reporting.
Different traffic wants different things. Broadcast/control that must be dumb and fast wants zero overhead (TM); delay-sensitive media wants ordering but not retransmission (UM); reliable signalling and TCP want full ARQ (AM). One sublayer, three behaviours.
RRC picks the mode per logical channel in RLC-Config (am, um-Bi-Directional, um-Uni-Directional-UL/DL, or implicitly TM for the channels that always use it). The choice fixes header format, SN size, timers and window sizes.
The one-line mental model: TM = pass-through pipe (no header at all); UM = numbered pipe that can cut packets to fit but never resends; AM = numbered pipe that cuts to fit and guarantees delivery with retransmissions and status reports. Everything below is just detail on those three sentences.
A second axis is directionality. TM and UM are modelled as pairs of independent one-way entities — a transmitting entity at one end and a receiving entity at the other — because there is no feedback to couple them. AM is a single bidirectional entity whose transmitting side and receiving side are coupled, because ARQ feedback has to flow from the receive side back to the transmit side. That structural difference is the reason AM is drawn as one box and TM/UM as two.
Transparent Mode (TM) — no header, no numbering
TM is exactly what the name says: the RLC entity is transparent. It receives an RLC SDU and forwards it as an RLC PDU with no RLC header added at all — no Sequence Number, no segmentation, no reassembly, no retransmission. There is nothing for RLC to track, so a TM entity holds essentially no state. The bytes that PDCP (or, for these channels, RRC directly) hands down are the bytes that go on the air.
A stateless pass-through used only for channels that are broadcast, paged, or pre-access, where per-packet numbering would be pointless. Carries BCCH, PCCH and the initial-access CCCH (i.e. SRB0).
System information, paging and the initial common-control exchange go to UEs that have no dedicated context yet. There is no receiver state to synchronise, so any RLC header or SN would be dead weight on a channel that is already tightly budgeted.
The TM entity is unidirectional: a separate transmitting TM entity and receiving TM entity. The transmitter forwards the SDU unchanged; the receiver delivers the received PDU straight up. The only "function" is transfer of upper-layer PDUs.
Remember it by its channels: if you see BCCH, PCCH or the CCCH that carries SRB0, RLC is in TM. Those are the channels a UE reads (or is paged on) before it has any dedicated radio bearer, so a stateless, header-less pipe is exactly right. Note that once a UE is connected, its dedicated signalling (SRB1/SRB2) moves to AM — TM is purely a common-channel mode.
Because TM adds no framing, sizing to the grant is not RLC's problem here: these channels carry fixed or bounded messages (a SIB, a paging record set, an RRCSetupRequest) that already fit, and MAC handles any needed adaptation. TM's virtue is precisely that it does nothing — the fewer moving parts on a channel every UE in the cell must read blind, the better.
Unacknowledged Mode (UM) — numbered, but never resends
UM adds just enough machinery to reorder and rebuild packets, but deliberately stops short of retransmission. Each UM data PDU carries a Sequence Number (SN), and if an RLC SDU is too big for the grant, UM will segment it and mark each piece with a Segmentation Info (SI) field and, for non-first segments, a Segmentation Offset (SO). The receiver uses the SN plus SO, together with a t-Reassembly timer, to reassemble — but if a segment is lost for good, UM simply moves on.
A mode with sequence numbering, segmentation and reassembly, plus RLC SDU discard on the transmit side — but no ARQ: no acknowledgements, no retransmissions, no status reporting.
For delay-sensitive traffic, a late packet is a useless packet. Voice (VoNR) and similar real-time media would rather drop a frame than wait for a retransmission that arrives after its playout deadline. UM keeps ordering and loss detection but skips the reliability tax.
UM entities are unidirectional (separate TX and RX) in the uni-directional variants, and modelled as a bidirectional pair only for convenience in um-Bi-Directional. The UM SN is 6 or 12 bits (sn-FieldLengthUM = size6/size12). The receiver runs t-Reassembly; if it expires with segments still missing, those SDUs are discarded and the reassembly window advances.
The UM header only appears when there is something to describe. A complete SDU that fits the grant in one piece is sent with a minimal header (the 2-bit SI field marks it as a full SDU and, in that case, the SN is not even needed for reassembly); a segmented SDU carries the SN so its pieces can be regrouped, and every non-initial segment carries the 16-bit SO giving the byte offset of that piece within the original SDU. The SI field's four values (00 = complete SDU, 01 = first segment, 10 = last segment, 11 = middle segment) tell the receiver exactly which part it holds. This "header only as needed" design is part of why NR RLC is leaner than LTE's.
Why UM for voice: a retransmitted voice packet arriving after its deadline is worse than useless — it costs airtime and still gets discarded by the codec. UM gives you ordering and loss detection without ever spending time chasing lost packets. That is the whole point of a delay-sensitive DRB. Reliability, if it is wanted at all for such flows, is left to the application.
Acknowledged Mode (AM) — the reliable, bidirectional workhorse
AM is UM plus a full ARQ engine. It numbers PDUs, segments and reassembles like UM, but it also tracks what the peer has received and retransmits anything reported missing. The receiving side periodically, or when prompted by a Polling bit the transmitter sets, sends a STATUS PDU listing acknowledged and negatively-acknowledged sequence numbers (ACK_SN / NACK_SN), and the transmitter resends exactly the gaps — re-segmenting a retransmission if the new grant is smaller than the original PDU.
A reliable mode: Sequence Number, segmentation and reassembly, ARQ retransmission, re-segmentation of retransmissions, and status reporting between the two peers, on top of RLC SDU discard.
Signalling (SRB1, SRB2) must not be lost — a dropped RRC message can break a whole procedure. TCP-carrying DRBs also benefit: RLC recovering a loss locally is far faster than letting TCP time out and halve its congestion window. AM buys that reliability.
Unlike TM/UM, an AM entity is a single bidirectional entity with a coupled transmitting and receiving side, so ARQ feedback flows both ways. The AM SN is 12 or 18 bits (sn-FieldLengthAM = size12/size18) — a larger space than UM, to keep more PDUs in flight for retransmission; the transmit/receive windows span 2(SN−1) PDUs. Timers t-PollRetransmit, t-Reassembly and t-StatusProhibit govern the ARQ loop.
The polling mechanism is what keeps the loop moving without flooding the reverse link. When the transmitter has sent a configured number of PDUs or bytes (pollPDU / pollByte), or has emptied its buffer, it sets the poll bit; the receiver responds with a STATUS PDU, unless t-StatusProhibit is still running (which throttles how often status is sent). On the transmit side, t-PollRetransmit guards against a lost poll: if no status comes back in time, the transmitter re-polls. Every NACK'd SN is retransmitted — a NACK can even carry an SOstart/SOend range to request only a missing byte-segment of a PDU — and a per-SDU retransmission counter bounded by maxRetxThreshold means a PDU that keeps failing is not retried forever; exceeding the threshold instead signals a problem to RRC, which may trigger radio-link recovery.
Two error-recovery layers, on purpose: HARQ in MAC handles fast, physical-layer errors slot by slot; RLC ARQ in AM is the slower backstop that catches the residual errors HARQ misses (e.g. a HARQ NACK-to-ACK misread that lets a corrupt block slip through). They complement rather than duplicate each other — see the MAC overview for how HARQ sits directly below the RLC channel.
The RLC functions — and the one NR dropped
TS 38.322 defines a compact list of functions, and every mode is just a subset of it. Reading the list top to bottom is the cleanest way to see what each mode does and does not do.
- Transfer of upper-layer PDUs — the base job in all three modes: move an
RLC SDUfrom PDCP down to MAC (and back up on receive). - Sequence numbering independent of PDCP — UM and AM stamp each PDU with an
SNon RLC's own number space, so reordering/reassembly never depends on the PDCP SN. - Error correction through ARQ — AM only: status reports and retransmission of missing PDUs.
- Segmentation and re-segmentation — UM and AM cut an SDU into pieces to fit the grant; AM additionally re-segments an already-sent PDU when it must be retransmitted into a smaller grant.
- Reassembly — UM and AM rebuild the original SDU from its segments using
SNandSO. - RLC SDU discard — UM and AM drop an SDU (e.g. on a PDCP discard indication, when the packet delay budget is blown) provided no segment of it has yet been submitted to lower layers.
- RLC re-establishment — all modes: on RRC command, reset state, flush buffers, stop timers and start clean (used at handover and reconfiguration).
- Protocol error detection — UM/AM sanity-check received PDUs.
The single most important NR change is what is missing from that list: concatenation. In LTE, RLC could concatenate several SDUs into one PDU to fill a grant exactly. NR RLC does not — an RLC PDU carries at most one SDU or one segment of an SDU. Sizing to the grant is done by segmentation alone.
Why NR dropped concatenation: in LTE, RLC could not build a PDU until it knew the exact grant size, because concatenation had to pack the PDU to fit. That put RLC on the critical timing path. In NR, RLC can pre-build PDUs (headers and SNs assigned) ahead of the grant, and only a final segmentation step adapts the last PDU to the grant. That shortens the processing pipeline for NR's tight slot timing, and it moves all multiplexing of different logical channels into MAC, where the MAC PDU already assembles multiple RLC PDUs anyway. Concatenation in RLC would have been redundant with MAC multiplexing.
LTE ↔ NR: beyond dropping concatenation, NR widened the sequence numbers (UM 6/12 bits and AM 12/18 bits, versus LTE's UM 5/10 and AM 10 bits) to keep more PDUs in flight at NR data rates, replaced LTE's separate framing-info/extension fields with the compact SI/SO scheme, and made the UM header appear only when a PDU is actually segmented. The three modes themselves (TM/UM/AM) and their roles are carried over unchanged from LTE — the mode-to-bearer mapping (SRB0=TM, SRB1/SRB2=AM, DRBs AM or UM) is essentially the same.
Function-by-mode matrix
| Function | TM | UM | AM |
|---|---|---|---|
| Transfer of upper-layer PDUs | Yes | Yes | Yes |
RLC header / Sequence Number | No | Yes | Yes |
| Segmentation & reassembly | No | Yes | Yes |
| Re-segmentation (of retransmissions) | No | No | Yes |
| ARQ / retransmission | No | No | Yes |
Status reporting (STATUS PDU) | No | No | Yes |
| Reordering before delivery | No | Yes (t-Reassembly) | Yes (in-order) |
RLC SDU discard | No | Yes | Yes |
| Re-establishment | Yes | Yes | Yes |
| Concatenation | Removed in NR — not performed by RLC in any mode (MAC multiplexes) | ||
Which mode carries which channel — and the entity types drawn
Mode is chosen to match the bearer. The rule of thumb: common/pre-access channels are TM; dedicated signalling is AM; and dedicated user data (DTCH) is AM or UM depending on whether the flow prizes reliability or low latency.
| Mode | RLC header / SN | ARQ | Reordering | Entity structure | Typical bearer / channel |
|---|---|---|---|---|---|
TM | None (no header, no SN) | No | No | Unidirectional (TX / RX separate) | SRB0 (CCCH), broadcast BCCH, paging PCCH |
UM | Header, SN = 6 or 12 bits | No | Yes (t-Reassembly) | Unidirectional (or Bi-Directional pair) | Delay-sensitive DRB on DTCH (e.g. VoNR) |
AM | Header, SN = 12 or 18 bits | Yes (status + retransmit) | Yes (in-order delivery) | Single bidirectional entity | SRB1/SRB2 (DCCH), reliable DRB (TCP) |
To make the bearer mapping concrete: SRB0 always uses TM because it runs on the CCCH before any dedicated context exists. SRB1 and SRB2 — the dedicated RRC signalling bearers on the DCCH — always use AM, because losing an RRC message would break the procedure they carry. Most data radio bearers (DRBs) use AM for anything that wants reliable, in-order delivery (web, file transfer, any TCP flow), and UM for real-time flows where latency beats reliability (conversational voice and video). Broadcast (BCCH) and paging (PCCH) are always TM.
The structural difference between the modes is easiest to see as a data path. Below, follow one RLC SDU down each mode's transmit path to the MAC channel, and note how only AM has a return arrow — the status feedback that makes retransmission possible.
⚠ Common pitfalls / gotchas
- Assuming AM guarantees zero loss. It bounds retransmissions by
maxRetxThreshold; exceeding it does not retry forever — it reports failure to RRC, which may trigger re-establishment or RLF handling. - Confusing RLC ARQ with MAC HARQ. HARQ is the fast per-slot recovery below the RLC channel; RLC ARQ is the slower backstop above it. RLC never sees HARQ retransmissions.
- Expecting UM to deliver everything in order regardless. If
t-Reassemblyexpires with a segment still missing, UM discards that SDU and moves the window on — by design, for latency. - Tying RLC's
SNto the PDCP SN. They are independent number spaces; RLC reorders on its own SN and never inspects PDCP's. - Thinking a mismatched
sn-FieldLengthor window config between peers is harmless. Both ends must agree viaRLC-Config; a mismatch corrupts window/SN interpretation and breaks reassembly.
Summary & Q&A
RLC bridges PDCP's arbitrary-sized packets to MAC's slot-by-slot grants, one entity per logical channel per bearer, its whole behaviour fixed by mode. TM: stateless pass-through, no header, for SRB0/BCCH/PCCH. UM: 6/12-bit SN, segmentation and reassembly with SI/SO and t-Reassembly, but no retransmission — for delay-sensitive DRBs like VoNR. AM: everything UM does plus ARQ (STATUS PDU with ACK_SN/NACK_SN, polling, re-segmentation, maxRetxThreshold), a 12/18-bit SN and a single bidirectional entity — for SRB1/SRB2 and reliable DRBs. NR's defining change is dropping concatenation so RLC can pre-build PDUs; RLC ARQ complements MAC HARQ rather than duplicating it. Get those three modes straight and the rest is detail.
Q. Which RLC mode carries which channels and bearers, and why is TM header-less?
A. TM carries SRB0 (CCCH), broadcast BCCH and paging PCCH — channels used before a dedicated context exists, so numbering would be useless and TM adds no header. UM carries delay-sensitive DRBs like VoNR. AM carries SRB1/SRB2 (DCCH) and reliable DRBs such as TCP traffic.
Q. Why is AM a single bidirectional entity while TM and UM are unidirectional?
A. AM runs ARQ, so its receiving side must feed STATUS PDUs back to its own transmitting side to trigger retransmissions — the two halves are coupled, so 3GPP models AM as one bidirectional entity. TM and UM have no such feedback, so their transmit and receive parts are independent unidirectional entities.
Q. What is the single biggest change in NR RLC versus LTE, and why was it made?
A. NR RLC no longer performs concatenation. An RLC PDU carries a single SDU or one segment of an SDU; sizing to the grant is done purely by segmentation. This lets RLC pre-build PDUs and assign SNs before the exact grant is known, shortening the processing pipeline for NR's tight timing, and it moves all logical-channel multiplexing into MAC (where it already happens).
Q. How is RLC's Sequence Number related to the PDCP SN?
A. They are independent. RLC numbers PDUs on its own SN space (UM 6/12 bits, AM 12/18 bits) purely for its own reordering, reassembly and ARQ. RLC never inspects the PDCP SN, which keeps the two layers cleanly decoupled.
Q. List the RLC functions that exist only in AM.
A. ARQ error correction (retransmission), status reporting via the STATUS PDU (ACK_SN/NACK_SN), and re-segmentation of retransmitted PDUs. Segmentation, reassembly, sequence numbering and SDU discard are shared with UM; transfer of PDUs and re-establishment exist in all three modes.
Q. What is the "RLC channel" and how does RLC relate to HARQ?
A. The RLC channel is the connection between an RLC entity and MAC for one logical channel; MAC multiplexes several RLC channels into a transport block and runs HARQ beneath them. RLC never sees HARQ retransmissions — HARQ is the fast physical-layer recovery, while RLC ARQ in AM is the slower backstop for the residual errors HARQ lets through.
Where RLC sits in the stack
RLC takes SDUs from the layer above and hands PDUs to the layer below, and its reliability complements HARQ underneath. Follow the packet up and down the stack: