5G RLC Acknowledged Mode
Acknowledged mode is the reliable operating mode in the NR RLC family. It combines data transfer, retransmission, STATUS-based feedback, duplicate detection, reassembly, and timer-driven control so that upper- layer data can be recovered when ordinary one-shot transfer is not enough.
This page treats AM as one complete RLC mode rather than as isolated spec fragments. It links the AM entity architecture, AMD and STATUS PDUs, transmit and receive windows, clause 5 data transfer behavior, ARQ procedures, clause 7 control values, and practical trace-reading cues into one mode-specific reference.
Quick facts
| Technology | 5G NR |
|---|---|
| Topic | RLC acknowledged mode (AM) |
| Main spec areas | TS 38.322 sections 4.2.1.3, 5.2.3, 5.3, clause 6 AMD or STATUS, and clause 7 AM variables |
| Release | Release 18 |
| AM control PDUs | STATUS PDUs for ARQ feedback |
| AM data PDUs | AMD PDUs for data transfer |
| Key controls | TX_Next_Ack, POLL_SN, RX_Next, t-PollRetransmit, t-Reassembly, t-StatusProhibit, maxRetxThreshold |
Contents
- Introduction to 5G RLC Acknowledged Mode
- Where AM Fits in the RLC Protocol Family
- AM RLC Architecture Overview
- Logical Channels and Typical AM Use Cases
- AM Data PDU and Control PDU Model
- Transmitting Side of AM RLC
- Receiving Side of AM RLC
- AM Transmitting Window and Receive Window
- AM Data Transfer Behavior
- ARQ, Polling, and STATUS in AM
- AM State Variables, Counters, Timers, and Parameters
- Why AM Is Used
- Trace Reading Notes
- Related Pages / Next Reading
- References
- FAQ
Introduction to 5G RLC Acknowledged Mode
AM is the richest mode in the NR RLC family because it combines ordinary data transfer with recovery and feedback behavior. Where TM is transparent and UM stops short of retransmission, AM adds the sender and receiver mechanisms needed to recover missing data at RLC level.
In practice, AM should be read as one linked system: upper-layer SDUs become AMD PDUs, the receiver checks what arrived and what is missing, STATUS PDUs report that feedback, and the sender retransmits or re-segments data as needed until progress is restored or retransmission limits are reached.
Where AM Fits in the RLC Protocol Family
TM is the simplest RLC mode and does not add header-driven sequence control or ARQ. UM adds segmentation and reassembly behavior with receive-side state, but it does not request retransmission. AM adds both richer data- transfer behavior and the full ARQ control loop through polling and STATUS feedback.
| Mode | Main behavior | Recovery model |
|---|---|---|
| TM | Transparent forwarding with minimal structure. | No RLC retransmission. |
| UM | Segmentation and reassembly without ARQ. | No RLC retransmission. |
| AM | Reliable transfer with data and control paths. | RLC ARQ through STATUS feedback and retransmission. |
AM RLC Architecture Overview
An AM RLC entity consists of a transmitting side and a receiving side. The transmitting side prepares AMD PDUs, manages retransmission context, and handles control-driven feedback timing. The receiving side stores received data, removes headers, detects duplicates or gaps, and reassembles SDUs for delivery upward.
At high level, the main AM internal blocks are the transmission buffer, retransmission buffer, RLC control, routing, reception buffer, header removal, and SDU reassembly. The exact implementation is vendor-specific, but the functional model is stable across compliant AM behavior.
Logical Channels and Typical AM Use Cases
AM may be configured to submit or receive RLC PDUs through several logical-channel contexts. The common theme is that AM is chosen where reliable RLC behavior matters more than the lower-latency, no-retransmission behavior of UM or the simplicity of TM.
| Logical channel | Direction | Why AM may be used |
|---|---|---|
| DCCH | DL or UL | Reliable control transfer matters for radio-control signaling. |
| DTCH | DL or UL | Reliable user-plane delivery can justify ARQ and retransmission behavior. |
| SCCH | Sidelink | Reliable sidelink control handling benefits from AM behavior. |
| STCH | Sidelink | Sidelink traffic channels may use AM where recovery and controlled reassembly are needed. |
AM Data PDU and Control PDU Model
AM uses two packet families. AMD PDUs carry AM data. STATUS PDUs carry AM feedback for ARQ. This split is the cleanest way to understand AM: data PDUs move user or control content forward, while control PDUs tell the sender what the receiver has accepted and what is still missing.
This page keeps the format detail short and uses it as a bridge to the dedicated PDU formats and parameters page and the ARQ procedures page.
Transmitting Side of AM RLC
The AM transmitting side generates an AMD PDU for each RLC SDU. When the lower layer offers a transmission opportunity that is smaller than the full SDU, the AM sender segments the data so the transfer can still proceed. If missing data later needs retransmission, the sender may retransmit the full SDU content or an SDU segment depending on what the feedback requires.
If a retransmission does not fit the next transmission opportunity, the sender can segment or re-segment again. The number of re-segmentations is not limited. This is one of the features that makes AM operationally richer than UM: retransmission is not a simple replay, but a flexible re-packaging of outstanding data to match the current lower-layer opportunity.
Receiving Side of AM RLC
The AM receiving side checks arriving AMD PDUs for sequence continuity, detects duplicates, and discards those duplicates instead of delivering them twice. It also detects lower-layer loss indirectly through sequence gaps and uses that information to request retransmission from the peer through STATUS feedback.
After header removal and buffering, the receiving side reassembles the original SDUs and delivers them upward when the required byte or sequence continuity conditions are satisfied. In this sense, the AM receiver is both a data consumer and a control-feedback generator.
AM Transmitting Window and Receive Window
The AM transmitting window is anchored by TX_Next_Ack. A sequence number is within the AM transmitting window when TX_Next_Ack <= SN < TX_Next_Ack + AM_Window_Size. The sender shall not submit AMD PDUs outside that transmitting window.
On the receive side, RX_Next acts as the lower edge of the receiving window. Together with the AM window size, it defines which sequence numbers are inside the current valid receive span. Release 18 uses AM_Window_Size = 2048 for 12-bit SN and 131072 for 18-bit SN.
For deeper state-variable detail, use the variables, constants, and timers page.
AM Data Transfer Behavior
AM data transfer should be read as a controlled priority system rather than as a simple first-in-first-out data path. The transmitting side prioritizes RLC control PDUs over AMD PDUs, and among AMD PDUs it prioritizes retransmitted data over not previously transmitted data. This keeps feedback and recovery ahead of fresh transmission when the system is under error pressure.
On the receiving side, data transfer behavior is tied to receive buffering, duplicate handling, receive-window progression, and eventual SDU reassembly. Timer detail such as t-Reassembly matters here, but this page keeps that detail short and points to the dedicated clause 7 reference.
ARQ, Polling, and STATUS in AM
ARQ exists only in AM. When the receiver detects missing data, STATUS PDUs inform the sender which data has been successfully received and which data is missing. Negative acknowledgement then drives retransmission consideration at the sender.
Polling is how the sender asks the peer for STATUS feedback. The sender sets poll requests in AMD transmission, tracks the resulting poll state, and uses timer-driven logic if feedback does not arrive in time. This page keeps the explanation at overview level and uses it as a bridge to the dedicated ARQ page rather than replacing it.
AM State Variables, Counters, Timers, and Parameters
AM behavior depends on a compact but important state set. On the transmit side the key values are TX_Next_Ack, TX_Next, POLL_SN, PDU_WITHOUT_POLL, BYTE_WITHOUT_POLL, and RETX_COUNT. On the receive side the main values are RX_Next, RX_Next_Status_Trigger, RX_Highest_Status, and RX_Next_Highest.
The main AM timers and parameters are t-PollRetransmit, t-Reassembly, t-StatusProhibit, maxRetxThreshold, pollPDU, and pollByte. This page summarizes them only briefly and links the full detail to the dedicated clause 7 page.
| AM transmit-side variable or counter | Main role |
|---|---|
| TX_Next_Ack | Anchors the transmitting window. |
| TX_Next | Tracks the next new AMD sequence number. |
| POLL_SN | Tracks the sequence point associated with an outstanding poll. |
| PDU_WITHOUT_POLL | Counts PDUs sent since the last poll reset point. |
| BYTE_WITHOUT_POLL | Counts bytes sent since the last poll reset point. |
| RETX_COUNT | Tracks retransmission count toward maxRetxThreshold behavior. |
| AM receive-side variable | Main role |
|---|---|
| RX_Next | Anchors receive-side in-sequence progress. |
| RX_Next_Status_Trigger | Supports STATUS-trigger logic. |
| RX_Highest_Status | Tracks the receive-side status boundary. |
| RX_Next_Highest | Tracks the highest received progress point. |
| AM timer or parameter | Main role |
|---|---|
| t-PollRetransmit | Limits how long the sender waits after polling. |
| t-Reassembly | Limits how long the receiver waits for missing data before progressing. |
| t-StatusProhibit | Limits how often STATUS PDUs are sent. |
| maxRetxThreshold | Limits repeated retransmission attempts. |
| pollPDU | Sets the PDU-count threshold for polling. |
| pollByte | Sets the byte-count threshold for polling. |
Why AM Is Used
AM is used because it combines the broadest set of RLC functions: ARQ, segmentation and reassembly, re-segmentation, duplicate detection, SDU discard, and protocol- error handling in one mode. No other RLC mode combines all of those behaviors.
This makes AM the most feature-rich and the most operationally demanding RLC mode. It is also why AM is the mode most often involved when engineers need to interpret recovery loops, send-window stalls, or repeated feedback traffic in traces.
Trace Reading Notes
At protocol level, AMD PDUs are the clearest sign of AM data flow. STATUS PDUs are the clearest sign of AM feedback behavior. Repeated polls usually suggest recovery pressure or a transmit- window stall. Repeated retransmissions usually suggest persistent NACK-driven recovery rather than ordinary fresh data flow.
| Trace clue | What it usually means |
|---|---|
| AMD PDUs dominate | AM data transfer is active. |
| STATUS PDUs appear regularly | AM feedback and ARQ behavior are active. |
| Repeated polls | Feedback is being requested repeatedly, often due to uncertainty or stalled progress. |
| Repeated retransmissions | Persistent NACK-driven recovery is underway. |
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
Why is AM richer than UM?
Because AM adds feedback and retransmission behavior on top of segmentation, reassembly, and receive-side state.
Can AM retransmit only whole SDUs?
No. AM can retransmit whole SDUs or SDU segments, and it can segment or re-segment again to fit later lower- layer transmission opportunities.
What is the clearest sign of AM control behavior in a trace?
STATUS PDUs are the clearest sign because they represent AM feedback and ARQ control behavior.
Does AM allow sending outside the transmitting window?
No. AMD PDUs must stay inside the AM transmitting window anchored by TX_Next_Ack.