The Radio Link Control (RLC) layer in LTE sits between PDCP (above) and MAC (below), and its main job is to make sure that data packets are delivered reliably, in order, and correctly reassembled at the other end. Think of it as the “quality inspector” on the assembly line between your IP data and the radio air interface.

Where RLC Fits in the Stack

Before diving in, picture the layers like this:

[ PDCP ]   ← provides IP packet compression, ciphering
   ↕
[ RLC  ]   ← segmentation, reassembly, retransmission ← YOU ARE HERE
   ↕
[ MAC  ]   ← schedules radio resources (HARQ lives here)
   ↕
[ PHY  ]   ← actual radio transmission

RLC receives SDUs (Service Data Units) from PDCP, think of these as full IP packets, and breaks them into smaller PDUs (Protocol Data Units) to match what the MAC/PHY layer can carry at any given moment. On the receiver side, it does the reverse: it collects PDUs and reassembles them back into the original SDUs.

The Three RLC Modes

RLC operates in three modes. Each serves a different purpose:

ModeFull NameACK/NACK?Retransmission?Typical Use
TMTransparent ModeNoNoBroadcasting, paging signals
UMUnacknowledged ModeNoNoVoIP, real-time video
AMAcknowledged ModeYesYesFile downloads, web browsing

The focus of retransmission and reassembly is almost entirely in AM (Acknowledged Mode), which is the most complex. AM is like TCP in the IP world, the sender keeps a copy of every packet it sends, and will resend it if confirmation of delivery doesn’t arrive.

Segmentation and Packet Size Evolution

When PDCP hands an IP packet (SDU) to RLC, the RLC must cut it into pieces that fit within the Transport Block Size (TBS) told to it by the MAC layer. The MAC scheduler decides how many radio resource blocks (RBs) to give each user, which determines the TBS. This creates packet size evolution across a session:

  • Good channel conditions: MAC grants large TBS → RLC can send big PDUs or even concatenate multiple small SDUs into one PDU
  • Poor channel conditions: MAC grants small TBS → RLC must segment one SDU into many small PDUs, each with its own Sequence Number (SN)
  • During retransmission: If a PDU that was originally large needs to be retransmitted but the new TBS is smaller, RLC can re-segment it into even smaller pieces — and this re-segmentation can happen multiple times without a limit

This is a critical insight: Packet sizes on the radio link are not fixed. They constantly evolve depending on channel quality, scheduler decisions, and whether packets are new transmissions or retransmissions. A large IP packet from a video download might initially travel as one big PDU, then be re-segmented into four smaller PDUs on retransmission if the channel has degraded.

How Retransmission Works (ARQ)

AM RLC uses a mechanism called ARQ (Automatic Repeat Request). Here is the step-by-step flow:

  1. Transmitter sends PDUs — each one gets a Sequence Number (SN). A copy is kept in the Retransmission Buffer until acknowledged.
  2. Transmitter polls the receiver — by setting a Poll Bit = 1 in the RLC header. This asks: “Hey, how are we doing?”
  3. Receiver sends a STATUS PDU — a small control message containing ACK_SN (up to which SN everything is received fine) and NACK information (specific SNs that are missing).
  4. Transmitter acts on NACK — any NACKed PDU is fetched from the retransmission buffer and resent. If it doesn’t fit the new TBS, it is re-segmented first.
  5. ACKed PDUs are freed — once a PDU is acknowledged, it is removed from the retransmission buffer, freeing memory.

This polling process is governed by a set of configurable timers:

TimerRole
t-PollRetransmitHow long to wait for a STATUS PDU before sending a poll again
t-ReorderingHow long the receiver waits for a missing PDU before declaring it lost
t-StatusProhibitMinimum gap between STATUS PDUs (prevents flooding the uplink)

Reassembly at the Receiver

On the receiving side, PDUs arrive from MAC, but they may arrive out of order, because HARQ (at MAC) processes multiple packets in parallel. The RLC receiver must:

  1. Place PDUs in a reorder buffer — holding them until the gap is filled or t-Reordering expires.
  2. Check sequence numbers — using the SN to detect missing pieces.
  3. Reassemble SDUs — once all segments of an SDU have arrived (in order), they are stitched together and passed up to PDCP.
  4. Trigger a STATUS PDU — if t-Reordering expires and a gap still exists, the receiver sends a NACK for the missing SN/

The key point is that the receiver must not deliver an SDU to PDCP until all its pieces have arrived and are in order. This guarantees in-sequence delivery to the upper layer.

Buffer Occupancy

Buffer occupancy refers to how much data is waiting inside the RLC buffers at any moment. There are two key buffers at the transmitter side:

  • Transmission Buffer (SDU) — holds new SDUs coming from PDCP, waiting to be segmented and sent for the first time
  • Retransmission Buffer (PDU) — holds copies of PDUs that have been sent but not yet acknowledged

A critical rule in AM mode: A PDU cannot be removed from the retransmission buffer until an ACK is received. This means:

  • If the channel is bad and many NACKs come in, the retransmission buffer fills up rapidly
  • If t-StatusProhibit is set too high, the receiver delays sending STATUS PDUs, which delays ACKs reaching the transmitter, which keeps the retransmission buffer full for longer — consuming significant memory
  • High buffer occupancy at the RLC layer is a hallmark of a congested or poor-quality radio link

Nokia Bell Labs research showed that dynamic RLC buffer sizing can reduce queuing delay by up to 95% compared to default static configurations, specifically because oversized buffers cause packets to pile up unnecessarily - a phenomenon called bufferbloat.

Delay Accumulation

Delay in RLC does not come from a single source — it accumulates in layers:

  1. Transmission buffer delay — a newly arrived SDU must wait in the transmission buffer until the MAC scheduler grants resources
  2. Segmentation delay — if the SDU is large and TBS is small, the SDU is split and each segment must wait for its own transmission opportunity (multiple TTIs = multiple milliseconds)
  3. HARQ delay — before RLC even considers retransmitting, the MAC HARQ layer gets up to 8 attempts to fix errors. Only after HARQ gives up does RLC step in
  4. ARQ retransmission delay — the round-trip time to send a PDU, receive a NACK in a STATUS PDU, and retransmit adds delay per retransmission event
  5. Reordering delay — the receiver holds PDUs in the reorder buffer for up to t-Reordering ms (e.g., 30–80 ms) before acting on missing ones
  6. t-StatusProhibit delay — the receiver cannot immediately send a NACK; it must wait for this timer to expire first

These delays stack on top of each other. In a bad channel scenario, a single IP packet could experience: transmission buffer wait → segmentation across 3 TTIs → 3 HARQ retries by MAC → 1 RLC retransmission → 35 ms reordering wait → total end-to-end delay of 100+ ms, compared to ~5 ms in ideal conditions. This is why tuning RLC timers and buffer sizes is critical for latency-sensitive applications.

The Interaction Between Buffer, Packet Size, and Delay

These three factors form a feedback loop that you should always visualize together:

  • Poor channel → MAC grants small TBS → RLC re-segments packets into more, smaller PDUs → more PDUs in flight → retransmission buffer grows
  • Growing retransmission buffer → more PDUs waiting for ACK → memory pressure → potential packet discard if max retransmissions is hit (maxRetxThreshold) → Radio Link Failure
  • Each retransmission event adds a deterministic delay inflation of (T_R) (RLC retransmission delay) to every packet that was waiting behind the retransmitted one in the buffer

This is why engineers monitor RLC buffer occupancy as a real-time health indicator: a suddenly growing buffer means channel quality is degrading, retransmissions are increasing, and end-user delay is about to spike.