ARQ, Status PDUs & Polling in 5G NR

Introduction

ARQ is the retransmission engine that runs inside Acknowledged Mode (AM) RLC (TS 38.322). It sits between PDCP above and MAC below, and its single job is to guarantee that the stream handed up to PDCP is complete, in order, and duplicate-free — no matter what the radio channel did to individual transport blocks.

It matters because the fast retransmission layer beneath it, HARQ, is not perfect: its one-bit feedback can be misread and its retransmission count is capped, so it occasionally leaves a residual hole. AM RLC's ARQ closes exactly those holes using explicit sequence numbers and byte-precise acknowledgement, which is why the bearers that cannot tolerate loss — signalling radio bearers (SRB) and reliable data bearers — always run in AM.

Because ARQ is a request/response loop, a stalled or lossy AM bearer almost always breaks at one identifiable place: the poll that solicits feedback, the STATUS PDU that carries it, or the retransmission that acts on it. Reading those three in order is how you localise an AM problem.

Why ARQ is needed

Concretely, three things must hold for a reliable bearer. The transmitter must keep a copy of everything unacknowledged so it can resend on demand. The receiver must be able to report precisely what it has and has not received. And the transmitter must be able to resend exactly the missing bytes and free everything confirmed. ARQ provides all three, on top of HARQ, which handles the common case but leaves rare residual losses.

What ARQ in AM RLC Does

Acknowledged Mode (AM) is one of three RLC modes — the other two, Transparent Mode (TM) and Unacknowledged Mode (UM), never retransmit. AM is the only mode that runs ARQ, which is precisely why it carries the traffic that cannot tolerate loss: signalling radio bearers (SRB) and reliable data bearers such as TCP-based flows. The single AM RLC entity is bidirectional: it contains a transmitting side that generates AMD PDUs and a receiving side that reassembles them and issues status reports, and each side runs against its peer's opposite side.

The value of ARQ is that it is selective and byte-precise. A modern AM entity does not retransmit blindly on a timer the way early ARQ protocols did; it retransmits only the specific PDUs — or even the specific byte ranges within a PDU — that the receiver explicitly reports as missing. Everything the receiver confirms is discarded from the retransmission buffer, freeing memory and letting the transmit window slide forward. The rest of this page is really about the two messages that make that precision possible: the poll and the STATUS PDU.

Polling — Asking for a Status Report

A receiver does not report continuously; that would burn uplink on feedback nobody asked for. Instead the transmitter solicits a report exactly when it needs one, by setting the poll bit — the P field in the header of an AMD PDU — to 1. When the receiving side sees P=1, it is obliged to construct and return a STATUS PDU. Polling is the transmitter saying, in effect, "tell me how far you have got, so I know what to free and what to resend."

The transmitter decides when to poll using two counters, a state variable, and a timer, all governed by parameters that RRC sets in RLC-Config:

Beyond the two counters, the specification requires a poll in two structural situations. First, when the transmitter has just submitted the last AMD PDU in its transmission buffer — there is no more data coming, so it needs feedback now to make progress rather than idling. Second, when the transmit window has stalled — the window is full and no new SN can be sent until acknowledgements arrive. In both cases the transmitter cannot advance without a fresh report, so it forces one. When a poll is set, the transmitter resets PDU_WITHOUT_POLL and BYTE_WITHOUT_POLL to zero, records POLL_SN, and (re)starts t-PollRetransmit.

The STATUS PDU — ACK_SN, NACK_SN, and Segment Offsets

The receiver's reply is a STATUS PDU (a control PDU, distinct from the AMD PDUs that carry data). Its job is to be compact yet exact: state the point up to which everything is present, then enumerate the gaps below that point. Four field types do all of this.

Each NACK_SN carries flag bits in the header that say which optional parts follow it: an E1-style indicator for whether another NACK follows, an indicator for whether SOstart/SOend are present, and an indicator for whether a NACK range is present. A NACK range and a segment offset can even combine to express "a run of whole PDUs is missing, and additionally a partial slice of the PDU at the end of the run." So a rich STATUS PDU reads like: "I have everything below ACK_SN=20, except I am missing NACK_SN=11 entirely, I am missing the three consecutive PDUs starting at NACK_SN=14 (NACK range=3), and I am missing bytes SOstart..SOend of NACK_SN=18." That single message tells the transmitter exactly what to resend and exactly what to free.

The receiver does not fire a STATUS PDU for every poll unconditionally — it is rate-limited by t-StatusProhibit. When the receiver sends a status report it starts this timer; while it runs, no further status report may be transmitted, even if additional polls arrive. Only when t-StatusProhibit expires can a fresh (and by then more complete) report go out. This prevents a flurry of polls from provoking a storm of near-identical reports that would clog the uplink and add nothing.

Reading a STATUS PDU in the logs

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

Retransmission and Re-segmentation

On receiving a STATUS PDU, the transmitting side processes it against its buffer. First it acts on the positive part: every SN below ACK_SN that is not NACKed is now delivered, so those PDUs are removed from the retransmission buffer and TX_Next_Ack advances past them. Then it acts on each NACK.

For a whole missing PDU, the transmitter re-queues that entire AMD PDU for transmission. For a partial NACK carrying SOstart/SOend, it resends only that byte range as an AMD PDU segment; the segment's header carries a Segmentation Offset (SO) field giving the byte position of the segment within the original RLC SDU, so the receiver can slot the bytes back into exactly the right place during reassembly. This byte-level precision is what makes AM efficient: a 30-byte hole punched in the middle of a large PDU costs a ~30-byte resend, not a full-PDU resend.

Crucially, a PDU or segment queued for retransmission can be re-segmented again at transmission time. If the grant the MAC layer hands RLC is smaller than the data waiting to be resent, RLC splits the retransmission into smaller AMD PDU segments, each with its own SO, and sends as much as fits now. The remainder waits for the next grant. The original SN is preserved across all these fragments — segmentation changes byte boundaries, never the sequence number — so the receiver reassembles them all under one SN.

Every time a PDU is retransmitted for a NACKed SN, the transmitter increments a per-PDU counter, RETX_COUNT, and compares it against maxRetxThreshold. If a PDU keeps getting NACKed until RETX_COUNT reaches that ceiling, RLC concludes the radio link is broken beyond ARQ's ability to fix it and indicates the failure to RRC, which typically triggers re-establishment. This ceiling is what keeps a dead link from retransmitting forever; the threshold itself is covered in RLC Timers & Windows.

AM State Variables

Both sides of an AM entity keep a small set of SN-valued state variables. They are the moving parts behind everything above: the poll logic reads POLL_SN, the buffer-freeing reads TX_Next_Ack, and the receiver builds its STATUS PDU from RX_Highest_Status. All are counted modulo the SN space and interpreted relative to the appropriate window edge.

Two more receive-side counters are worth naming even though the full timer story lives elsewhere: RX_Next_Status_Trigger records the SN that started the reassembly timer t-Reassembly, and it is the expiry of that timer (a detected gap that never filled from HARQ) that ultimately triggers a NACK in the next status report. On the transmit side, PDU_WITHOUT_POLL, BYTE_WITHOUT_POLL, and the per-PDU RETX_COUNT round out the bookkeeping already described.

Transmit and Receive Windows

Sequence numbers are finite — the SN field is either 12 bits or 18 bits — so they wrap around. To keep an "old" PDU and a "new" PDU that happen to share the same SN value unambiguous, each side runs a sliding window that bounds which SNs may legitimately be in flight at once.

On the transmitter, the window spans from TX_Next_Ack (its lower edge, the oldest unacknowledged SN) upward. The transmitter may not assign an SN that would fall outside this window; if the receiver stops acknowledging, the window fills and the transmitter stalls — exactly the condition, mentioned earlier, that forces a poll to shake loose a fresh report. On the receiver, a matching window from RX_Next upward bounds which SNs it will accept and reassemble; anything falling outside it is discarded as stale or a duplicate.

The window is exactly half the total SN space. That is the whole trick: with the window capped at 2^(SN−1), the set of "valid new" SNs and the set of "possible old wrap-around" SNs can never overlap, so the receiver can always tell a freshly wrapped SN from a lingering old one and never mistakes a new PDU for a stale duplicate. The precise arithmetic that positions each window edge relative to RX_Next and TX_Next_Ack is detailed alongside the timers in RLC Timers & Windows.

ARQ in Action — Message Sequence

The chart below shows one full turn of the AM loop between the transmitting and receiving RLC entities: a run of data PDUs (one of them lost to a HARQ residual error), a later PDU that carries the poll, the STATUS PDU that acknowledges up to a point and NACKs the gap, and the targeted retransmission that closes it.

How ARQ Complements HARQ

It is tempting to ask why 5G bothers with two retransmission layers. The answer is that they operate at different timescales and against different failure modes, and each is bad at the other's job.

So the division of labour is: HARQ handles the common case — the overwhelming majority of channel errors, cleaned up locally and quickly so latency stays low. RLC ARQ handles the rare residual case — the few blocks HARQ fails to recover, which without ARQ would become permanent holes at PDCP. Because HARQ has already scrubbed out almost all errors, ARQ retransmissions are infrequent, which is what lets AM afford the luxury of precise, selective, byte-level resends without flooding the air interface. The two layers are complementary, not redundant: remove HARQ and ARQ would be far too slow to keep the error rate down; remove ARQ and HARQ's residual failures would break reliable bearers.

Summary

AM RLC's ARQ is a request/response reliability loop: the transmitter polls (sets P=1 per pollPDU/pollByte, on the last PDU, or on a window stall), the receiver answers with a STATUS PDU (cumulative ACK_SN plus selective NACK_SN, with SOstart/SOend and NACK range for precision), and the transmitter retransmits exactly what was NACKed, re-segmenting to fit each grant while preserving the SN. Two timers pace it — t-PollRetransmit guarantees feedback is chased, t-StatusProhibit stops feedback flooding — and maxRetxThreshold bounds retransmission before declaring failure to RRC.

To debug an AM bearer, walk the loop: is the transmitter polling? is the STATUS PDU coming back and advancing ACK_SN? are NACKs turning into correctly-scoped retransmissions? The first link that breaks localises the fault — a silent poll, a suppressed status, or a runaway RETX_COUNT.

Q&A

Quick LTE 4G / 5G NR Interview Questions