RLC Overview & Modes (TM / UM / AM) in LTE 4G
The three RLC modes and which logical channels and services each one serves in LTE.
Sitting between PDCP above and MAC below, the RLC layer (TS 36.322) is the part of the LTE stack that turns a stream of PDCP packets into pieces MAC can drop into whatever radio grant the scheduler hands out — and, when reliability matters, makes sure every piece actually 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 modes and their per-channel assignment straight and the rest of the LTE user-plane and control-plane data path falls into place.
Introduction
The RLC layer (Radio Link Control, TS 36.322) sits between PDCP above and MAC below in the LTE Layer-2 stack. Its job is to take the stream of packets PDCP hands down and reshape them into pieces that fit whatever radio grant the MAC scheduler produces — and, on channels where reliability matters, to make sure every piece actually arrives. It is instantiated once per logical channel, so a single UE runs many independent RLC entities at the same time.
RLC is active on essentially every bearer a UE has. A broadcast or paging channel needs a stateless pass-through; a voice call needs ordering without delay; a signalling bearer or a TCP flow needs guaranteed delivery. RLC serves all of them with one of three modes — TM, UM or AM — each layering one more capability on top of the last, and each configured per bearer by RRC.
It matters because the mode assigned to a channel is a deliberate trade of overhead against reliability, and getting that mapping right (and knowing why) is central to how the LTE data path behaves. It is also one of the most reliably asked LTE Layer-2 interview topics, usually paired with "what changed in NR".
On this page
Why RLC is needed
In plain words: RLC is the shipping room between two floors of a warehouse. PDCP upstairs hands it parcels of whatever size; MAC downstairs keeps sending out trucks whose size the scheduler decides at the last minute. RLC's job is to cut the big parcels and bundle the small ones so each truck leaves full — and, for the parcels that must not be lost, to keep a receipt book and resend anything that never arrives.
Concretely, RLC exists to solve two problems the layers around it cannot. First, a size mismatch: PDCP packets are whatever size the application produced, but the MAC grant is a byte count the scheduler chooses per Transmission Time Interval, and the two almost never match — so something has to segment large packets and pack small ones to fill each grant tightly. Second, selective reliability: different traffic wants different guarantees, and paying the full cost of retransmission on every flow would be wasteful. RLC's three modes let the network buy exactly the reliability each flow needs — nothing on broadcast, ordering-only on voice, full ARQ on signalling and TCP — from one layer with three behaviours.
What RLC does, and the three modes
RLC is a per-logical-channel entity. For each radio bearer, PDCP hands RLC a stream of RLC SDUs; RLC packages them into RLC PDUs sized to whatever grant MAC offers, and on the receive side it puts them back together, in order, before delivering to PDCP. Every RLC entity serves exactly one logical channel, and its entire personality — whether it adds a header, whether it numbers packets, whether it retransmits — is fixed by its mode. There is no dynamic switching: RRC configures the mode once, per bearer, and it stays until reconfiguration.
Three modes of operation: Transparent Mode (TM), Unacknowledged Mode (UM) and Acknowledged Mode (AM). Each defines a distinct RLC entity behaviour and a distinct PDU format.
Different traffic wants different things. Broadcast and pre-access control that must stay 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 layer, three behaviours, so the network pays only for the reliability each flow actually needs.
RRC configures the mode per logical channel via the RLC-Config IE inside the bearer setup. The mode determines whether an RLC header with a Sequence Number is present, whether segmentation and concatenation happen, and whether an ARQ state machine and its timers run.
Because RLC is instantiated once per logical channel, a single UE runs many RLC entities at once: a TM receiver reading BCCH, another watching PCCH, an AM entity for its signalling radio bearers, and one UM or AM entity for each data radio bearer. They are independent state machines that happen to share the same code.
The one-line mental model: TM = a pass-through pipe with no header at all; UM = a numbered pipe that packs and cuts packets to fit the grant but never resends; AM = a numbered pipe that packs and cuts to fit and guarantees delivery through retransmissions and status reports. Each mode simply adds one more capability on top of the previous.
SDUs, PDUs, and the LTE-defining trick: segmentation AND concatenation
The relationship between RLC SDU and RLC PDU is the heart of what RLC does day to day. An RLC SDU is one packet as PDCP delivered it — a whole PDCP PDU, whatever size it happens to be. An RLC PDU is one payload block sized to fit exactly the byte count MAC granted for this logical channel in this Transmission Time Interval. Those two sizes almost never match, which is why RLC has to reshape the data.
RLC has two tools to make an SDU stream fit a grant, and the key LTE feature is that it uses both:
- Segmentation — if an
RLC SDUis larger than the grant, RLC cuts it into segments and sends them across several PDUs. - Concatenation — if the grant is larger than a single waiting SDU, RLC packs several SDUs (and/or segments) into one PDU so the grant is filled tightly, with no padding wasted.
To let the receiver undo this, the transmitter marks boundaries with two header fields. The Framing Info (FI) field says whether the first and last data field of the PDU are complete SDUs or partial (segment) pieces. One or more Length Indicator (LI) fields then give the byte length of each concatenated SDU except the last, and an extension bit (E) chains the header so the receiver knows how many LIs follow. With FI and the LI list the receiver can slice the PDU payload back into the exact SDUs PDCP originally handed down.
Why LTE concatenates and NR does not: in LTE, RLC cannot build its PDU until MAC tells it the exact grant size, because the PDU must be assembled to fill that grant — segmenting the head SDU and concatenating enough following SDUs to reach the byte target. That "assemble on demand" step happens inside the tight scheduling deadline and adds latency. NR removed concatenation precisely to break this dependency: NR RLC can pre-build PDUs before the grant is known (each carrying at most one SDU or one segment), and MAC does all the packing. LTE traded a little latency for tighter grant utilisation; NR made the opposite choice for speed.
Concatenation is where the LTE receive path also does more bookkeeping than NR's: a single lost UM or AM PDU in LTE can straddle several SDUs, so losing it can damage more than one packet. That is one reason the concatenation design was reconsidered for NR. It is also why the LI-based framing is a genuine part of the LTE RLC header format rather than an afterthought.
Grant-driven timing (interaction with MAC): MAC runs the logical-channel prioritisation (LCP) procedure, decides how many bytes each logical channel gets this TTI, then asks each RLC entity for a PDU of that size. RLC segments/concatenates to hit the number and returns the PDU. MAC multiplexes the PDUs from several logical channels into one transport block, tagging each with an LCID in a MAC subheader, and hands the block to HARQ. So the RLC PDU size is an output of MAC scheduling, not a fixed value.
RLC never works alone; it is one link in the Layer-2 chain, and its two neighbours define what comes in and what goes out. PDCP above performs header compression (ROHC), ciphering, and (for SRBs) integrity protection, then hands RLC its output as RLC SDUs. MAC below performs logical-channel multiplexing, HARQ, and scheduling, and consumes the RLC PDUs RLC produces. The figure traces one SDU stream down through the reshaping RLC does.
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 concatenation, no reassembly, no retransmission. There is nothing for RLC to track, so a TM entity holds essentially no state and adds essentially no delay.
A pass-through mode used only for channels that are broadcast or pre-access, where per-packet numbering would be pointless. Carries BCCH, PCCH and CCCH, and by extension the broadcast/paging traffic on them.
System information, paging and the initial-access common control channel go to UEs that have no dedicated context yet. There is no receiver state to synchronise against, so any RLC header or SN would be dead weight the whole cell has to carry.
A TM entity is unidirectional: a separate transmitting TM entity and a separate receiving TM entity. The transmitter simply forwards the SDU as-is; the receiver delivers the received PDU straight up to the upper layer with no processing.
Remember it by its channels: if you see BCCH, PCCH or CCCH, 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. This is also why SRB0, which rides CCCH during initial access, is the one signalling bearer that is not AM — there is no UE context yet to run ARQ against.
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 PDU carries a Sequence Number (SN), and UM can segment an RLC SDU that is too big for the grant and concatenate several small SDUs into one PDU, marking the boundaries with the FI and LI fields described above. The receiver uses the SN, runs a t-Reordering timer to put out-of-order PDUs back in sequence, reassembles the SDUs — but if a segment is lost for good, UM just moves on.
A mode with sequence numbering, segmentation, concatenation, reassembly and reordering, but no ARQ — no acknowledgements, no retransmissions, no status reporting.
For delay-sensitive traffic, a late packet is a useless packet. Voice (VoLTE) and similar real-time media would rather drop a frame than wait for a retransmission that arrives after its playout deadline. So UM keeps ordering but skips the reliability tax.
UM entities are unidirectional (separate TX and RX). The UM SN is configurable as 5 or 10 bits. The receiver keeps a reordering window and runs t-Reordering; if it expires with PDUs still missing, the receiver stops waiting, discards what cannot be reassembled, advances its window state variables and continues.
UM carries the real-time DTCH — the user-plane data radio bearers where timeliness beats completeness. VoLTE is the classic example: the voice DRB is mapped to a UM RLC entity because a resent speech frame is worthless once its 20 ms window has passed. Streaming and other conversational media use it for the same reason.
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 DTCH.
Acknowledged Mode (AM) — the reliable, bidirectional workhorse
AM is UM plus a full ARQ engine. It numbers PDUs, segments, concatenates and reassembles like UM, but it also tracks what the peer has received and retransmits anything reported missing. The receiver sends a STATUS PDU — triggered periodically, or on demand when the transmitter sets the Polling (P) bit — listing acknowledged and negatively-acknowledged sequence numbers (ACK_SN / NACK_SN), and the transmitter resends exactly the gaps.
A reliable mode: Sequence Number, segmentation / concatenation / reassembly, ARQ retransmission, re-segmentation of retransmissions, and status reporting between the two peers.
Signalling (SRBs) 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 cheaply.
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 10 bits (a 16-bit SN was added in later releases to keep more PDUs in flight at high data rates). When a retransmission must be re-sized to a smaller grant, AM re-segments the PDU and uses a Segment Offset (SO) field, flagged by the resegmentation flag (RF), to mark where the byte range starts.
Polling is how the transmitter forces feedback. It sets the P bit when a configured amount of data has been sent (pollPDU / pollByte), or when it has emptied its buffer, and then starts t-PollRetransmit; if no STATUS PDU arrives before the timer fires, it polls again. On the receive side, t-StatusProhibit rate-limits how often status reports go out so feedback never floods the return link. These timers, plus the window state variables VT(A)/VT(S) on the transmit side and VR(R)/VR(MR)/VR(H) on the receive side, are the whole AM state machine.
AM carries the reliable bearers: SRB1 and SRB2 (the RRC signalling that rides DCCH) and the majority of user-plane DRBs, especially anything carrying TCP or other loss-sensitive application data.
Two error-recovery layers, on purpose: HARQ in MAC handles fast, physical-layer errors within roughly 8 ms; RLC ARQ in AM is the slower backstop that catches the residual errors HARQ misses (for example a HARQ NACK-to-ACK misread that would otherwise silently drop a block). They complement rather than duplicate each other.
Side by side: modes, headers, ARQ, bearers — and LTE vs NR
The quickest way to keep the three modes straight is one table. Note the pattern: each mode simply adds capability — TM has none, UM adds numbering plus segmentation/concatenation, AM adds ARQ on top.
| Mode | RLC header / SN | Segmentation & concatenation | Retransmission (ARQ) | Entity structure | Typical bearer / channel |
|---|---|---|---|---|---|
TM | None (no header, no SN) | No | No | Unidirectional (TX + RX) | SRB0 on CCCH; BCCH, PCCH (broadcast / paging / initial access) |
UM | Header with SN = 5 or 10 bits | Yes (FI + LI) | No | Unidirectional (TX + RX) | Delay-sensitive DTCH DRB (e.g. VoLTE, streaming) |
AM | Header with SN = 10 bits (16-bit option) | Yes (FI + LI) + re-segmentation (SO, RF) | Yes (STATUS PDU, ACK_SN/NACK_SN) | Single bidirectional entity | DCCH = SRB1/SRB2; most user-plane DRBs (TCP) |
The second table is the one interviewers love: how LTE RLC differs from NR RLC. NR streamlined RLC for latency, and the single biggest change is that NR dropped concatenation.
| Aspect | LTE RLC (TS 36.322) | NR RLC (TS 38.322) |
|---|---|---|
| Concatenation | Yes — a PDU may pack several SDUs/segments (LI fields) | No — one PDU carries at most one SDU or one segment; MAC does the packing |
| Segmentation | Yes | Yes (via SO-based segmentation only) |
| PDU build timing | After the grant is known (assemble to grant size) → adds latency | Pre-built before the grant (RLC PDUs ready in advance) → lower latency |
| In-order delivery to upper layer | RLC delivers in order | RLC does not reorder for in-order delivery; PDCP handles ordering |
| Reassembly / SN | UM 5/10-bit, AM 10/16-bit SN | UM 6/12-bit, AM 12/18-bit SN |
| Modes | TM, UM, AM | TM, UM, AM (same three) |
The headline difference: LTE RLC concatenates and reorders; NR RLC does neither. NR pushed concatenation down to MAC and reordering up to PDCP so that RLC PDUs can be prepared before the scheduler grant arrives — shaving latency off the critical path. When someone asks "what changed in RLC from LTE to NR," lead with concatenation removed.
The three RLC entity types, drawn
The structural difference between the modes is easiest to see visually: TM and UM are each two separate one-way entities, while AM is one two-way entity whose transmit and receive halves talk to each other to run ARQ.
Why AM is one entity, not two: ARQ needs the receiving side to feed STATUS PDUs back to the same peer's transmitting side, so the two halves are tightly coupled — 3GPP models that coupling as a single bidirectional AM entity. TM and UM have no feedback, so their transmit and receive parts are independent, and each is modelled as its own unidirectional entity.
Summary
RLC is a per-logical-channel layer that reshapes PDCP's RLC SDUs into grant-sized RLC PDUs for MAC, using two tools that are the LTE signature: segmentation (cut an SDU too big for the grant) and concatenation (pack several small SDUs into one PDU), with the FI and LI header fields marking the boundaries so the receiver can rebuild the originals.
Its behaviour is fixed per bearer by the mode, and each mode simply adds capability. TM is a header-less pass-through for BCCH, PCCH, CCCH and SRB0 — broadcast, paging and initial access, where there is no UE context to number against. UM adds a Sequence Number (5 or 10 bits), segmentation/concatenation and reordering but never retransmits, which suits delay-sensitive DTCH DRBs like VoLTE. AM adds a full ARQ engine — STATUS PDUs with ACK_SN/NACK_SN, polling, re-segmentation via SO/RF, and its window/timer state machine — carrying DCCH (SRB1/SRB2) and most user-plane DRBs.
Two structural facts round it out: AM is modelled as one bidirectional entity (its receive side feeds status back to its own transmit side) while TM and UM are pairs of independent unidirectional entities; and RLC ARQ complements MAC HARQ rather than duplicating it, acting as the slower backstop for the residual errors HARQ misses. The one change to lead with for NR: concatenation was removed, so NR RLC can pre-build PDUs before the grant arrives and MAC does the packing.
Quick Q&A
Q. Which RLC mode carries which channels and bearers, and why is TM header-less?
A. TM carries BCCH, PCCH, CCCH and SRB0 — broadcast, paging and initial access, where the UE has no dedicated context, so numbering would be useless and TM adds no header. UM carries delay-sensitive DTCH DRBs such as VoLTE and streaming. AM carries DCCH (SRB1/SRB2) and most user-plane DRBs, especially TCP traffic.
Q. What is the one big feature LTE RLC has that NR RLC removed, and why?
A. Concatenation. LTE RLC packs multiple RLC SDUs into one PDU (delimited by LI fields) so it must wait for the exact MAC grant before building the PDU. NR dropped concatenation so RLC can pre-build PDUs (one SDU/segment each) before the grant arrives, cutting latency; MAC does the multiplexing instead.
Q. Explain the SDU-to-PDU relationship and how the receiver rebuilds SDUs.
A. An RLC SDU is a whole packet from PDCP; an RLC PDU is a grant-sized block. RLC segments a large SDU across PDUs and/or concatenates several SDUs into one PDU. The header's FI field says whether the first/last data fields are complete or partial, and the LI fields give each concatenated SDU's length, so the receiver can slice the payload back into the original SDUs.
Q. Why is AM a single bidirectional entity while TM and UM are two unidirectional entities?
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. Do all SRBs use AM?
A. Almost. SRB1 and SRB2 use AM because RRC signalling must be delivered reliably. The exception is SRB0, which is carried on CCCH during initial access and therefore uses TM — there is no UE context yet to run ARQ against.
Q. How do RLC ARQ and MAC HARQ relate?
A. They are two error-recovery layers. HARQ in MAC is the fast physical-layer loop (~8 ms) that corrects most block errors; RLC ARQ in AM is the slower backstop that catches the residual errors HARQ misses, such as a HARQ NACK-to-ACK misread. They complement each other rather than duplicate work.
Where RLC leads next
RLC takes SDUs from PDCP above and hands grant-sized PDUs to MAC below, and its AM reliability complements HARQ underneath. Follow the pieces further: