5G RLC ARQ Procedures
RLC ARQ is the acknowledged-mode recovery mechanism in 5G NR. It allows an AM RLC entity to detect missing data through peer feedback, request or trigger feedback through polling, and retransmit missing content so that incomplete SDUs or missing byte segments can be recovered at RLC level.
This page explains how retransmission, polling, STATUS reporting, t-PollRetransmit, and t-StatusProhibit fit together, while keeping the content trace-friendly and connected to the wider RLC reference set.
Quick facts
| Technology | 5G NR |
|---|---|
| Topic | RLC ARQ procedures |
| Main spec | 3GPP TS 38.322 |
| Release | Release 18 |
| Applies to | AM RLC only |
| Core loop | Polling, STATUS reporting, retransmission, and recovery from missing data |
| Main timers | t-PollRetransmit, t-StatusProhibit, t-Reassembly |
Contents
- Introduction to 5G RLC ARQ Procedures
- Where ARQ Fits in AM RLC
- ARQ Procedures Map
- Retransmission
- Polling Overview
- Polling During Transmission of an AMD PDU
- Reception of a STATUS Report
- Expiry of t-PollRetransmit
- Status Reporting
- ARQ and Timers
- Troubleshooting Notes from ARQ Behavior
- Related Pages / Next Reading
- References
- FAQ
Introduction to 5G RLC ARQ Procedures
In the RLC context, ARQ means the procedure set used by an AM RLC entity to recover missing data after ordinary transmission has not completed successfully. It is not a general RLC function for all modes. TM and UM do not perform these procedures.
The goal is practical and narrow: recover missing SDUs or missing byte segments that prevent correct AM receive- side progression. ARQ therefore connects transmit-side buffering, peer feedback, receive-side gap detection, and timer-driven follow-up behavior.
Where ARQ Fits in AM RLC
ARQ sits inside acknowledged mode as the reliability loop between data transfer and receive-side feedback. AMD PDUs carry AM data. STATUS PDUs are AM control PDUs that report what has been received and what is still missing. Together, they form the feedback path that allows AM to recover losses or incomplete byte ranges.
This section should be read as both architectural and procedural. Architecturally, STATUS PDUs exist because AM has a control path in addition to its data path. Procedurally, that control path is what turns missing-data observation into retransmission behavior at the sender.
ARQ Procedures Map
This ARQ topic can be read as one reliability loop broken into smaller procedure pieces. It starts with the general ARQ rule set, then covers retransmission, polling, AMD transmission with polling decisions, STATUS reception, expiry of t-PollRetransmit, and finally STATUS reporting itself.
| ARQ procedure area | What it covers | Why it matters |
|---|---|---|
| General | ARQ only in AM and the overall sender or receiver feedback model. | Sets the scope correctly before going into details. |
| Retransmission | How missing data indicated by STATUS becomes retransmission work. | Explains how AM repairs missing data. |
| Polling | How the sender asks the peer for feedback. | Without polling, feedback can stall and recovery may not progress. |
| Transmission of an AMD PDU | How poll insertion decisions are made during sending. | Important for understanding P field use and timer start or restart behavior. |
| Reception of a STATUS report | How incoming feedback affects POLL_SN tracking and timer handling. | Important when explaining why t-PollRetransmit stops or continues. |
| Expiry of t-PollRetransmit | How the sender reacts when expected feedback does not arrive in time. | Explains AM stall recovery behavior. |
| Status reporting | How and when the receiver generates STATUS feedback. | Explains ACK_SN, NACK information, and t-StatusProhibit gating. |
Retransmission
Retransmission starts when a received STATUS PDU negatively acknowledges data that has been transmitted and is still valid for retransmission handling. In practical terms, the sender checks which missing ranges are covered by the peer feedback and which transmitted data can still be mapped back to the required recovery work.
AM keeps retransmission state through a retransmission counter and related procedure variables. When data is selected for retransmission, RETX_COUNT handling becomes relevant, and if the configured maxRetxThreshold is reached, the entity indicates this upward so the upper layer can react to a persistent recovery failure.
Retransmission is not necessarily a byte-for-byte replay of the original sent PDU. If the new lower-layer opportunity is smaller or otherwise different, the retransmitted content may be re-segmented. The new AMD PDU still maps back to the original SDU or SDU segment, but its header and byte coverage are updated to match the new transmission opportunity.
Polling Overview
Polling is the sender-side method used to trigger STATUS reporting at the peer AM RLC entity. It is not itself a retransmission. It is the feedback request that helps the sender learn whether the peer has advanced cleanly or whether missing data must be recovered.
In practice, polling is the bridge between ongoing AMD transmission and the control feedback needed to keep AM moving forward.
Polling During Transmission of an AMD PDU
When an AMD PDU is transmitted, the AM sender evaluates whether a poll should be included. This decision is tied to counters such as PDU_WITHOUT_POLL and BYTE_WITHOUT_POLL, configured thresholds such as pollPDU and pollByte, and additional sender conditions such as buffer-empty transitions or transmit-window stalling.
If the sender decides to include a poll, it sets the P field, updates POLL_SN, and starts or restarts t-PollRetransmit as required by the current sender state. This is why poll insertion is a key trace point: it marks a request for peer feedback and starts the timer logic that protects the sender from waiting indefinitely.
If you want to check where these poll-related fields and control bits sit in the actual protocol unit, use RLC PDU Formats and Parameters next. That page is the right reference when the question changes from polling logic to the AMD PDU field view.
| Poll trigger condition | Meaning | Why it matters |
|---|---|---|
| pollPDU threshold | Enough PDUs have been sent without a poll. | Prevents long data bursts without feedback requests. |
| pollByte threshold | Enough bytes have been sent without a poll. | Prevents large-volume transmission without peer confirmation. |
| Buffer empty | The sender has no more immediate data to send. | Useful for confirming that the peer has caught up before the sender goes idle. |
| Window stall | The transmit-side state cannot progress cleanly without peer feedback. | Important for avoiding long AM stalls. |
Reception of a STATUS Report
When a STATUS report is received, the AM sender evaluates what part of its transmitted data has been positively or negatively acknowledged. If the STATUS feedback covers POLL_SN, then t-PollRetransmit is stopped and reset if it is running. This is one of the clearest state transitions to look for in AM traces.
The rest of the STATUS content is then used to advance acknowledged progress and identify retransmission work where NACK information shows missing data or missing byte ranges.
Expiry of t-PollRetransmit
Expiry of t-PollRetransmit means the sender did not receive the expected feedback in time for a poll it had already issued. This forces the entity to treat the situation as a stalled or incomplete feedback condition rather than continuing to wait passively.
In practical terms, timer expiry can lead to retransmission consideration and another poll so that the AM sender actively tries to re-open the feedback loop. This behavior matters because it keeps AM from remaining blocked indefinitely when peer feedback is delayed, lost, or otherwise not useful enough to clear sender uncertainty.
Status Reporting
STATUS PDUs provide the AM receiver's feedback to the sender. They can carry positive acknowledgement through ACK_SN and negative acknowledgement through NACK information, including missing byte-range detail where the missing data is smaller than a full data unit.
STATUS reporting is triggered by several conditions, especially peer polling, detection of reception failure, and expiry of t-Reassembly. Depending on the receive state, the trigger may lead to immediate STATUS construction or to delayed sending when the procedure rules indicate that feedback should wait briefly for a cleaner receive picture.
t-StatusProhibit limits how often STATUS PDUs are actually transmitted. If multiple STATUS triggers occur while this timer is active, the receiver does not emit a flood of control PDUs. Instead, a later single STATUS transmission can represent the accumulated need for feedback once sending is allowed again.
| STATUS trigger | Meaning | Trace relevance |
|---|---|---|
| Peer polling | The sender explicitly requests feedback. | Often the simplest reason a STATUS PDU appears. |
| Reception failure detection | The receiver detects missing data or another condition that requires feedback. | Common during AM gaps and retransmission loops. |
| t-Reassembly expiry | The receiver stops waiting and updates its feedback need. | Important when missing data blocks receive progression. |
At high level, STATUS construction describes what has definitely advanced and what is still missing. A useful reading rule is this: ACK_SN identifies the next not-received data unit that is not already being reported as missing, while NACK entries identify missing full units or missing byte ranges below that point.
ARQ and Timers
Three timers dominate ARQ reading. t-PollRetransmit protects the sender from waiting too long after issuing a poll. t-StatusProhibit limits how often the receiver sends STATUS PDUs. t-Reassembly affects receive-side determination of when enough waiting has happened and when feedback should be advanced after missing data blocks completion.
This page keeps timer definitions short because the deeper timer and variable detail belongs on RLC Variables, Constants, and Timers. For ARQ reading, the key point is how these timers control when feedback is requested, when feedback is allowed, and when stalled receive-side waiting is converted into new STATUS information.
Troubleshooting Notes from ARQ Behavior
ARQ issues are some of the clearest performance and reliability symptoms in AM traces. Repeated retransmissions often point to persistent NACK feedback or repeated failure to close receive-side gaps. Repeated polls with no useful STATUS coverage often point to a stalled feedback path. A POLL_SN that does not clear can indicate that the sender is not receiving the feedback needed to advance beyond the outstanding poll.
t-StatusProhibit can also make STATUS feedback appear compressed or delayed. That does not mean the peer is ignoring missing data. It may mean the peer has already accumulated feedback needs but is not yet allowed to emit another STATUS PDU. In throughput terms, retransmission loops and delayed feedback directly hurt forward data progress because lower-layer opportunities are consumed by recovery rather than fresh data.
| Symptom pattern | Likely ARQ meaning | Best next page |
|---|---|---|
| Repeated retransmissions of related AMD content | Persistent NACK-driven recovery or unresolved receive-side gaps. | Troubleshooting and Trace Analysis |
| Repeated polls without useful feedback closure | STATUS is missing, delayed, or not advancing sender certainty. | Variables, Constants, and Timers |
| POLL_SN appears to remain outstanding | STATUS has not yet covered the sender's tracked poll point. | PDU Formats and Parameters |
| STATUS arrives less often than gap events suggest | t-StatusProhibit is likely gating feedback transmission. | Variables, Constants, and Timers |
| Throughput drops during repeated recovery cycles | Retransmissions and feedback latency are consuming transmission opportunities. | RLC Procedures |
References
- 3GPP TS 38.322 V18.0.0, NR Radio Link Control (RLC) protocol specification
- 3GPP TS 38.300 V19.2.0, NR and NG-RAN overall description for architecture context
- 3GPP TS 38.331 V18.5.1, NR Radio Resource Control (RRC) protocol specification for RLC-related configuration context
FAQ
Does ARQ exist in TM or UM RLC?
No. ARQ procedures are specific to acknowledged mode. TM and UM do not use STATUS-based retransmission.
What is the main purpose of polling in AM RLC?
Polling asks the peer AM entity to provide STATUS feedback so the sender can confirm progress or identify missing data that requires retransmission.
Why can retransmitted data look different from the original AMD PDU?
Because retransmitted data may be re-segmented to fit a new lower-layer transmission opportunity, which changes the new AMD PDU header and byte coverage while preserving the mapping back to the original data.
What does t-PollRetransmit protect against?
It protects the sender from waiting indefinitely after polling. If useful feedback does not arrive in time, the sender can reconsider retransmission and issue another poll.