ARQ, Status PDUs & Polling in LTE 4G

Introduction

RLC ARQ is the outer retransmission loop of the LTE user and control plane, defined in TS 36.322. It runs inside the RLC layer whenever a radio bearer is configured in Acknowledged Mode (AM) — the mode used for anything that cannot tolerate loss or reordering: signalling on SRB1/SRB2, and reliable data flows such as TCP.

It sits between PDCP above and MAC/HARQ below. HARQ cleans up the great majority of air-interface errors within a few milliseconds; RLC ARQ mops up the residual few that HARQ could not fix and restores strict in-order delivery to PDCP. The whole machine is a closed feedback loop: the transmitter sends numbered PDUs and periodically polls for a status report; the receiver replies with a STATUS PDU naming exactly what did and did not arrive; the transmitter resends only the missing byte ranges.

Because ARQ is entirely bookkeeping — sequence numbers, byte offsets, windows and a handful of timers — a stall or a torn-down bearer almost always traces to one specific counter or timer: a poll that was never answered, a window that stalled, a retransmission budget that ran out. Reading the state variables in order is what turns "the bearer dropped" into a precise root cause.

Why RLC ARQ is needed — Acknowledged Mode and ARQ

RLC has three modes — Transparent (TM), Unacknowledged (UM) and Acknowledged (AM). Only AM gives you reliable, in-order, loss-free delivery, and it does so through ARQ (Automatic Repeat reQuest): the receiver tells the transmitter what it did and did not get, and the transmitter resends whatever was lost. Bearers that carry signalling or anything intolerant of loss run in AM; latency-sensitive but loss-tolerant flows like VoLTE media typically run in UM, which has reordering but no retransmission.

The unit RLC AM operates on is the AMD PDU (Acknowledged Mode Data PDU). Its fixed header carries the D/C field (data vs control), a re-segmentation flag RF, the poll bit P, a framing-info field FI, an extension bit E, and the SN. When a PDU has been re-segmented for retransmission it becomes an AMD PDU segment, whose header additionally carries a last-segment flag LSF and a Segment Offset SO naming the byte position of this piece inside the original SN. The whole ARQ machine is built around two ideas: sequence numbers to name PDUs, and segment offsets to name byte ranges within a PDU.

ARQ traffic is not scheduled on its own channel: AMD PDUs and STATUS PDUs are handed to MAC and ride the ordinary transport blocks — downlink on PDSCH (scheduled by DCI format 1/1A/2 on PDCCH, CRC scrambled by the UE's C-RNTI, in the UE-specific search space) and uplink on PUSCH (granted by DCI format 0 / C-RNTI). RLC sees only SNs and byte offsets; the physical addressing is entirely MAC/PHY's job.

Polling — asking for a status report

The receiver does not volunteer status constantly; that would waste uplink. Instead the transmitter requests feedback by setting the P field to 1 in the header of an AMD PDU. When the receiver sees P=1, it is obliged to send back a STATUS PDU — subject only to its own t-StatusProhibit timer, which rate-limits how often it may reply.

A poll is triggered by any of several conditions, so the transmitter learns about losses without polling on every PDU. TS 36.322 defines two counters that the transmitter maintains and compares against RRC-configured thresholds:

• PDU_WITHOUT_POLL vs pollPDU: the transmitter counts AMD PDUs sent since the last poll in PDU_WITHOUT_POLL; when it reaches the configured pollPDU value, it sets P=1 and resets the counter.
• BYTE_WITHOUT_POLL vs pollByte: in parallel it counts data bytes sent in BYTE_WITHOUT_POLL; when that reaches pollByte, it polls and resets. Two counters means either "enough packets" or "enough volume" can trigger feedback, whichever comes first.
• Window / last-PDU rule: if there is no new data or retransmission left to send once this PDU goes out (the buffer empties), or the transmit window is stalled and cannot advance, the transmitter must poll — otherwise it would sit idle forever waiting on feedback it never asked for.

When it sets the poll bit, the transmitter records POLL_SN — the SN of the highest-numbered AMD PDU it has submitted to lower layers at that moment — and (re)starts the t-PollRetransmit timer. POLL_SN is the "watermark" the pending poll is asking about: the poll is considered answered once a STATUS PDU arrives whose ACK_SN has moved past POLL_SN, or which explicitly reports POLL_SN.

If t-PollRetransmit expires before that happens, the transmitter assumes the poll (or its answer) was lost and polls again — either by transmitting the PDU with SN = VT(S)−1, or by transmitting a not-yet-acknowledged PDU, with P=1. This guards against a single lost poll deadlocking the whole loop.

The STATUS PDU — ACK_SN, NACK_SN and Segment Offsets

The receiver's reply is a STATUS PDU, a control PDU distinguished from data by its D/C field = 0 and a CPT (Control PDU Type) field = 000. It compactly describes exactly what has and has not arrived using two kinds of sequence number and a chain of extension bits.

• ACK_SN: the SN of the next not-yet-received PDU that is not being reported as missing — in effect, "I have everything below this SN, except the NACKs I am about to list." There is exactly one ACK_SN per STATUS PDU and it sits at the front.
• NACK_SN: the SN of a PDU below ACK_SN that is missing. A STATUS PDU can carry many NACK_SN fields, one per gap.

The fields are strung together by two extension bits. E1 follows the ACK_SN (and follows each NACK block): E1=1 means "another NACK_SN block follows", E1=0 means "the list ends here". E2 follows a NACK_SN and signals whether that NACK carries a segment-offset pair: E2=1 means "an SOstart/SOend pair follows for this SN". This lets a status report be as short as one ACK_SN, or grow to cover many gaps and partial gaps, without any wasted bits.

The segment offsets handle partial NACKs. When a lost PDU had already been re-segmented on a previous transmission, the receiver may be missing only part of an SN. In that case the NACK_SN is followed (via E2=1) by SOstart and SOend: byte offsets that mark the exact range within that SN that must be resent. SOstart is the first missing byte and SOend the last; a special SOend value of all-ones means "to the end of the PDU". This avoids resending a whole large PDU when only a slice is missing.

The STATUS PDU is itself rate-limited on the receive side by t-StatusProhibit. When the receiver sends a status report it starts this timer, and while it runs the receiver will not send another status report even if it is polled again. This stops a burst of polls (or a burst of losses) from triggering a flood of status reports that would themselves congest the uplink.

State variables and the AM windows

ARQ is bookkeeping, and the bookkeeping lives in a handful of state variables per RLC entity — three on the transmit side, three on the receive side. They define two sliding windows that bound which SNs may be sent and which may be accepted. Because the AM SN is 10 bits, the SN space is 0…1023 and the AM window size is 512 (half the SN space, so wrap-around is unambiguous); this is the constant AM_Window_Size.

The transmit window is the span [VT(A), VT(MS)). The transmitter may generate new PDUs only while VT(S) is inside it; if STATUS PDUs stop arriving and VT(A) cannot advance, VT(S) eventually bumps into VT(MS) and the window stalls — which is precisely why the last-PDU/window poll rule exists, to shake feedback loose before the entity locks up. The receive window [VR(R), VR(MR)) does the mirror job: PDUs inside it are buffered and reassembled in SN order, PDUs at or above VR(MR) are dropped, and VR(R) only advances once the PDU it points at is completely received. VR(H) tracks the leading edge so the receiver knows a gap exists even before it reports one.

Retransmission and re-segmentation

When the transmitter receives a STATUS PDU it processes it against its state. Every SN in the range [VT(A), ACK_SN) that is not listed as a NACK_SN is now confirmed delivered: it is discarded from the retransmission buffer, and VT(A) (and hence VT(MS)) slides forward to free the transmit window. Every NACK_SN is queued for retransmission and given priority over new data.

Retransmission is not always a byte-for-byte copy. If the MAC grant available for the retransmission is smaller than the original PDU, RLC re-segments it: the AMD PDU is split into AMD PDU segments, the header RF flag is set to mark them as segments, and each carries its own Segment Offset SO so the receiver can slot the piece back into the correct byte position of the original SN. A partial NACK carrying SOstart/SOend tells the transmitter exactly which byte range to rebuild, so re-segmentation and partial NACK are two halves of the same byte-range mechanism.

A per-PDU counter RETX_COUNT is incremented when a PDU (or the segment containing the NACKed byte range) is retransmitted. If RETX_COUNT reaches the RRC-configured maxRetxThreshold, RLC declares an unrecoverable error and indicates it to upper layers — which for an SRB typically triggers RRC re-establishment for that radio link. This bounds how long ARQ will keep trying before it admits defeat, so a dead link is torn down rather than retried forever.

A poll / status / retransmit exchange

Putting it together: the eNB, acting as the RLC transmitter for a downlink AM bearer, sends a run of AMD PDUs and polls on the last one; one PDU is lost over the air; the UE reports the gap; the eNB retransmits just that PDU, re-segmenting it if the new grant is smaller.

Notice the eNB only resends SN 6 — SN 5 and SN 7 were confirmed by ACK_SN=8. That selectivity is the whole point of ARQ: retransmit the gaps, not the stream. And because ACK_SN=8 is above POLL_SN=7, the pending poll is satisfied and t-PollRetransmit can be stopped rather than firing a redundant re-poll.

Reading the ARQ loop in the logs

An RLC AM trace shows the poll being set with its POLL_SN, the returning STATUS PDU's ACK_SN/NACK_SN, the retransmission (with any re-segmentation), and the window sliding as VT(A) advances. Reading these in sequence tells you whether a stall is a lost poll, a lost status, or an exhausted retransmission budget.

Representative RLC AM log (QXDM/QCAT-style) — illustrative, values vary by vendor/build:

Summary

RLC AM ARQ is the outer, byte-accurate retransmission loop that turns a lossy, reordering radio link into reliable, in-order delivery. Walk it in the order it runs: the transmitter numbers PDUs (SN) and polls (sets P=1, records POLL_SN, starts t-PollRetransmit) when pollPDU/pollByte or the last-PDU/window rule fires; the receiver replies with a STATUS PDU (ACK_SN plus any NACK_SN, with SOstart/SOend for partial gaps, chained by E1/E2); the transmitter retransmits only the NACKed ranges, re-segmenting to fit the grant, and slides VT(A) forward.

When a bearer stalls or resets, the fault is almost always one specific piece of bookkeeping: an unanswered poll (t-PollRetransmit expiring), a stalled transmit window (VT(S) hitting VT(MS) because VT(A) is frozen), a silenced receiver (t-StatusProhibit), or an exhausted retry budget (RETX_COUNT reaching maxRetxThreshold → unrecoverable error → re-establishment). Identifying which one narrows a vague "call dropped" into a precise, testable cause.

Best used trace-in-hand: line up poll → status → retransmit → window-slide, and the first step that does not complete is your root cause.

Interplay with HARQ, and quick Q&A

RLC ARQ never works alone; it sits directly on top of MAC HARQ, and the two are deliberately tuned for different jobs. HARQ is the fast loop: each transport block is protected by a stop-and-wait process with soft combining, so a corrupted block is re-sent and combined within a few milliseconds, and the vast majority of air-interface errors are cleaned up there before RLC ever notices. But HARQ is bounded — it stops after maxHARQ-Tx attempts, and because several HARQ processes run in parallel a late success can deliver blocks out of order. Those two failure modes — a residual undecoded block, and reordering — are exactly what RLC ARQ is designed to catch.

So the division of labour is: HARQ handles the many fast errors; RLC ARQ handles the residual few. HARQ feedback (ACK/NACK on PUCCH) is per transport block and lives in the MAC; RLC feedback (the STATUS PDU) is per SN range and lives in RLC. Because HARQ already suppresses most errors, RLC polls sparingly and status reports stay small — a well-tuned link spends almost all its retransmission budget in the fast HARQ loop and only occasionally invokes the slower, byte-accurate ARQ loop. This layering is why LTE can offer both low latency and near-lossless delivery on the same bearer.