RLC Timers & Windows in LTE 4G

Introduction

The RLC (Radio Link Control) layer sits between PDCP above and MAC below, and its Acknowledged Mode (AM) is the layer that turns the lossy, reordering air interface into a reliable, in-order pipe. It does that with an ARQ loop — sequence numbers, gap detection, NACKs and retransmissions — but ARQ only works if both ends agree on when to act and which sequence numbers are live. Those two questions are answered by three timers and two sliding windows, all defined in TS 36.322 and configured by RRC in RLC-Config.

These objects are in play on essentially every LTE call. A default-bearer DRB mapped to RLC AM uses them continuously; every signalling radio bearer (SRB) runs AM and therefore leans on the poll and STATUS machinery; and any latency-sensitive UM DRB (VoLTE, for example) runs the reordering half of the same story. When a bearer stalls, throughput collapses, or STATUS storms clog the uplink, the root cause is almost always one specific timer misconfigured or one window edge stuck.

Because each timer is (re)started on a defined event and, on expiry, drives exactly one reaction, an RLC problem almost always lives in one specific timer or window edge. That is why a structured, per-object troubleshooting habit pays off: if you know which timer fired (or failed to), or which window edge froze, you have already narrowed the root cause enormously.

Why AM needs timers and windows

In Acknowledged Mode (AM) the RLC entity is a reliable, in-order pipe built on top of an unreliable one. PDUs are numbered with a Sequence Number (SN), the receiver detects gaps, and it asks for retransmissions by sending a STATUS PDU carrying NACKs. But nothing on the air is instantaneous: a "missing" PDU might just be a slow HARQ retransmission arriving a few milliseconds late, or a reordered burst from a lower layer. If the receiver screamed for a retransmission the moment SNs arrived out of order, it would flood the uplink with needless NACKs and trigger retransmissions of PDUs that were never actually lost.

The timer durations and polling thresholds are signalled by RRC inside RLC-Config (the AM branch, am-Config), separately for each direction (ul-AM-RLC and dl-AM-RLC). The window sizes, by contrast, are not configured at all — they are fixed by the SN length the standard assigns to the mode. That single choice, tying window size to SN length, is where the number 512 comes from.

The 10-bit SN and the 512 Window

An AM RLC PDU carries a 10-bit SN. Ten bits count from 0 to 1023 and then wrap back to 0, so the entire sequence-number space is 1024 values arranged in a circle. A sliding window is just an arc of that circle: a contiguous run of SNs the entity currently cares about. The receiver accepts PDUs whose SN falls inside its receive window and rejects the rest; the transmitter is allowed to send new PDUs only while their SN falls inside its transmit window.

The critical rule is how big that arc is allowed to be. In AM, AM_Window_Size = 512 — exactly half of the 1024-value space. This is not a tunable knob; it is baked into TS 36.322 as a direct consequence of the 10-bit SN. The reason is disambiguation of wrap-around. When you only have a modulo-1024 counter, a raw SN value like 5 could mean "5 just after 1020 wrapped" or "5 a long time ago." By promising never to let the live window span more than half the circle, the entity can always tell which side of the current lower edge any received SN belongs to, using modular arithmetic centred on that edge. Make the window larger than half the space and two different PDUs could map to the same relative position — the receiver would no longer know whether a SN is "ahead" (a future PDU to buffer) or "behind" (an old duplicate to drop).

So each window holds at most 512 PDUs in flight before its lower edge must advance. If that edge stalls — because a low SN is stuck being retransmitted — the transmitter eventually hits the top of its own window and can send no new data at all. That condition is a window stall, and it is precisely why the poll and reordering timers exist: to get a stalled window moving again before it becomes permanent. UM uses the same halving rule against its own shorter SN, as we will see.

t-Reordering — waiting out reordering before declaring loss

t-Reordering lives at the receiving side and it exists in both AM and UM. When PDUs arrive out of order, the receiver cannot immediately tell "lost forever" from "merely late." So instead of reacting, it arms t-Reordering against the gap and waits. If the missing PDU shows up before the timer fires, the gap closes silently: no NACK, no fuss. If the timer expires and the gap is still open, the receiver concludes the PDU really is lost and finally acts.

What "acts" means depends on the mode, and this is the single most important distinction on the page:

• In AM, expiry drives the receiver to include the missing SN as a NACK in its next STATUS PDU, asking the transmitter to retransmit it. AM never drops a hole — it repairs it.
• In UM, there is no retransmission machinery at all, so expiry means "give up on the hole, deliver everything you already have below and up to it in order, and slide the reordering window forward past the lost PDU." UM discards rather than repairs.

The timer is armed the moment a gap first appears — when a PDU arrives with a SN higher than the one the receiver is still waiting for, so reception has run ahead of the in-sequence edge. At that instant the receiver records which SN boundary it is timing: VR(X) in AM (and VR(UX) in UM). Only one t-Reordering runs per entity at a time; if reception later advances but a gap still remains beyond the one being timed, the timer is restarted against the new boundary rather than left to time a stale gap.

Choosing t-Reordering is a latency-versus-overhead trade. Too short and the receiver declares loss on PDUs only a HARQ round-trip late, provoking wasteful retransmissions; too long and every genuine loss stalls in-order delivery for that whole duration, throttling a TCP flow above. It is normally tuned to comfortably exceed the worst-case HARQ delay so only real losses reach expiry. The configured value is an enumeration in milliseconds — the RRC field t-Reordering spans roughly ms0…ms200, and setting it to ms0 effectively disables the wait so any gap is treated as loss immediately.

t-PollRetransmit — guarding a poll that got no answer

The transmitter learns what the receiver is missing only when a STATUS PDU comes back, and a STATUS is normally produced because the transmitter asked for one. It asks by setting the polling bit (P) in an AMD PDU header — essentially "please tell me what you have." The transmitter sets that bit when a polling condition is met, for example after it has sent pollPDU data PDUs or pollByte bytes since the last poll, or when it has just submitted the last PDU currently in its buffer. When it does, it records POLL_SN = the highest SN it has sent so far, and starts (or restarts) t-PollRetransmit.

The problem the timer solves is that a poll, or the STATUS it should have produced, can itself be lost. Without a safeguard the transmitter would wait forever for feedback that never comes, and since its window cannot advance without acknowledgements, it would stall and go silent. If a STATUS reaching up to POLL_SN arrives before the timer fires, the timer is stopped. If it expires with the poll still unanswered, the transmitter forces the issue: it re-polls by retransmitting the PDU with the highest SN still awaiting acknowledgement (or includes a fresh poll on another PDU), and restarts t-PollRetransmit so the loop is protected again.

t-StatusProhibit — rate-limiting STATUS feedback

Every gap the receiver detects tempts it to fire off a STATUS PDU, and several triggers can pile up in quick succession: a poll arrives, then a t-Reordering expires, then another poll. If the receiver honoured each one immediately, a burst of losses could produce a storm of STATUS PDUs — wasting uplink resources and, worse, NACKing PDUs that are already in flight as retransmissions, which provokes yet more redundant retransmissions. t-StatusProhibit throttles this.

When the receiver sends a STATUS PDU, it starts t-StatusProhibit. While that timer runs, the receiver is prohibited from sending another STATUS PDU even if new triggers occur; those triggers are simply remembered as pending. Once the timer expires, STATUS reporting is allowed again, and any pending trigger produces a single consolidated report covering everything learned in the meantime. The value is a direct knob on feedback frequency: a short prohibit gives snappier retransmissions but more uplink overhead and more risk of duplicate NACKs; a long prohibit gives leaner feedback but slower loss recovery. A common configuration is to keep t-StatusProhibit comfortably shorter than t-PollRetransmit, so that the receiver is generally free to answer a poll by the time the transmitter would otherwise give up and re-poll.

State Variables and the AM Windows

AM keeps a small set of state variables per direction. On the transmit side they bound the transmit window; on the receive side they bound the receive (reordering) window. You do not need to memorise every arithmetic rule, but you should know what each variable stands for and why the window exists.

The transmit window runs from VT(A) up to VT(MS) = VT(A) + 512. The transmitter may send new PDUs (advancing VT(S)) only while they fall inside this window; it cannot outrun the oldest unacknowledged PDU by more than 512. As STATUS PDUs acknowledge low SNs, VT(A) slides up and the whole window drags forward, freeing room for new data. If VT(A) stops moving because a low SN is stuck, VT(S) eventually reaches VT(MS) and the transmitter stalls — which is exactly the situation t-PollRetransmit is there to break.

The receive window runs from VR(R) up to VR(MR) = VR(R) + 512. PDUs inside it are accepted and buffered; PDUs at or beyond VR(MR), or below VR(R), are discarded. A gap is detected whenever reception runs ahead — whenever VR(H) gets in front of VR(R) because a higher SN arrived while a lower expected one is still missing — which is exactly the condition that starts t-Reordering against VR(X). As the missing PDUs fill in, VR(R) advances and the window slides forward, releasing complete, in-order data to the upper layer. Meanwhile VR(MS) tracks the highest SN the receiver is entitled to report as ACKed, so that a STATUS PDU never claims to have received something above the contiguous run it can actually vouch for.

The UM Reordering Window

Unacknowledged Mode has no NACKs, no STATUS PDUs and no retransmissions — it never asks for anything back. What it keeps is the reordering half of the story: a receive window and one timer, t-Reordering, used purely to bound how long it will wait for out-of-order PDUs before it gives up on a hole and delivers what it has. That makes UM the natural home for latency-sensitive traffic like VoLTE, where a late packet is worthless and repairing a loss would only add delay.

UM in LTE uses a shorter SN than AM, and it can be configured to one of two lengths. The reordering window follows the same halving rule as AM:

The 5-bit SN keeps UM headers tiny for small, frequent packets, at the cost of a shallow window that tolerates only modest reordering; the 10-bit option trades header bytes for a deeper window when more reordering is expected. The SN field length is signalled by RRC in the UM configuration (sn-FieldLength).

UM tracks its window with its own state variables: VR(UR) is the UM receive state, the lower edge (the earliest SN still considered for reordering); VR(UH) is the UM highest received state, one above the highest SN received; and VR(UX) is the UM t-Reordering state — the SN following the PDU that triggered the running timer, the analogue of AM's VR(X). The reordering window covers the UM_Window_Size values ending just below VR(UH). When t-Reordering expires in UM, the receiver advances VR(UR) up to the first SN at or beyond VR(UX) that has not yet been received, reassembles and delivers in SN order every SDU it can now complete, and — if reception is still ahead of the new edge — restarts the timer against the next hole. The hole that expired is simply abandoned; UM never looks back.

Reading RLC AM in the logs

The RLC loop is a sequence of concrete events you can walk through in a trace: a data PDU is sent with the poll bit, a timer starts, a STATUS comes back (or does not), the window advances (or stalls). Two things anchor everything — the state variables above and the AMD/STATUS PDU fields below. When a bearer stalls, the fastest root-cause is to line up the configured timers against the observed events and find the first one that does not match.

Representative RLC AM trace — illustrative, values vary by vendor/build:

Summary

The three timers and two windows form one cooperative loop: the transmit window paces sending, the receive window catches and orders arrivals, and the timers decide precisely when patience turns into action. The fastest way to root-cause an RLC stall is to identify which object is stuck — a frozen VT(A) points at unanswered polls (t-PollRetransmit); a frozen VR(R) points at an unrecovered low SN (t-Reordering and retransmission); a STATUS storm points at t-StatusProhibit. The table below is the one-glance reference for the timers; a second table gives typical configured ranges so you can sanity-check a real RLC-Config.