5G RLC Unacknowledged Mode
Unacknowledged mode is the structured middle mode in the NR RLC family. It supports segmentation and reassembly through UMD PDUs and receive-side control state, but it does not perform ARQ retransmission or STATUS-based feedback the way acknowledged mode does.
This page treats UM as one complete RLC mode. It connects the UM entity model, UMD packet structure, transmit-side segmentation, receive-side reassembly, reassembly-window behavior, t-Reassembly, and practical trace-reading cues into one mode-focused reference.
Quick facts
| Technology | 5G NR |
|---|---|
| Topic | RLC unacknowledged mode (UM) |
| Main spec areas | TS 38.322 sections 4.2.1.2, 5.2.2, clause 6 UMD, and clause 7 UM variables and timer behavior |
| Release | Release 18 |
| UM data PDUs | UMD PDUs only |
| UM recovery model | Segmentation and reassembly without ARQ retransmission |
| Key controls | TX_Next, RX_Next_Reassembly, RX_Timer_Trigger, RX_Next_Highest, UM_Window_Size, t-Reassembly |
Contents
- Introduction to 5G RLC Unacknowledged Mode
- Where UM Fits in the RLC Mode Family
- UM RLC Architecture Overview
- Logical Channels and Typical UM Use
- UMD PDU Model
- Transmitting Side of UM RLC
- Receiving Side of UM RLC
- UM Reassembly Window
- UM Data Transfer Behavior
- t-Reassembly in UM
- UM State Variables and Runtime Control
- Why UM Is Used
- Trace Reading Notes
- Related Pages / Next Reading
- References
- FAQ
Introduction to 5G RLC Unacknowledged Mode
UM sits between TM and AM in the NR RLC family. It is more structured than TM because it supports segmentation, header-driven ordering, and reassembly behavior. It is lighter than AM because it does not request retransmission from the peer and does not use STATUS-based control feedback.
The practical UM model is straightforward: the sender generates UMD PDUs from RLC SDUs and segments them to fit lower-layer transmission opportunities, while the receiver buffers, reassembles, delivers, or discards data depending on sequence progress and t-Reassembly behavior.
Where UM Fits in the RLC Mode Family
TM is the simplest mode and forwards data without the richer segmentation and state model of UM or AM. UM adds structured segmentation and reassembly, receive-side state, and timer-driven loss handling. AM builds on top of that by adding retransmission and feedback control.
| Mode | Main behavior | Recovery model |
|---|---|---|
| TM | Transparent forwarding. | No structured reassembly or ARQ. |
| UM | Segmentation and reassembly with receive-side state. | No ARQ retransmission. |
| AM | Reliable transfer with feedback and retransmission. | RLC ARQ through STATUS and retransmission. |
UM RLC Architecture Overview
A UM RLC entity is configured either as a transmitting UM RLC entity or as a receiving UM RLC entity. This is a cleaner split than AM because UM does not add the separate control-feedback loop used by ARQ.
At high level, the UM entity model can be understood through the transmission buffer, header generation, segmentation, reception buffer, header removal, and SDU reassembly. The sender side packages and segments, and the receiver side collects, checks, reassembles, and discards when necessary.
Logical Channels and Typical UM Use
UM can be configured to submit or receive RLC PDUs through several logical-channel contexts. The practical theme is that UM is chosen where segmentation and receive-side reassembly matter, but the retransmission and feedback overhead of AM is not required.
| Logical channel | Direction or context | Why UM fits |
|---|---|---|
| DTCH | DL or UL | Useful where segmented transport and reassembly are needed without AM recovery overhead. |
| SCCH | Sidelink | Structured sidelink control transfer can use UM behavior. |
| STCH | Sidelink | Structured traffic transfer can use UM when no ARQ loop is required. |
| MCCH | Multicast control | Control distribution can use UM-style structured delivery. |
| MTCH | Multicast traffic | Multicast delivery can use segmentation and reassembly without AM feedback. |
In sidelink contexts, the configured UM entity can be effectively uni-directional from the viewpoint of a given transfer path, which is consistent with the split transmitting-entity or receiving-entity model.
UMD PDU Model
The UMD PDU is the UM data PDU. It contains either one complete RLC SDU or one RLC SDU segment. Structurally, a UMD PDU has a Data field and a byte-aligned UMD header.
UM supports 6-bit or 12-bit sequence numbering. For sidelink groupcast, broadcast, or SL-SRB4, only the 6-bit SN configuration is used. UMD includes SN only when the RLC SDU is segmented. SO is optional and has length 16 bits; it is present only when the PDU carries a segment that is not the first segment of the original RLC SDU.
For the field-level layout and the exact complete-SDU versus segmented cases, open UMD PDU Formats. That page is the better reference when the next question is about header structure rather than UM procedure behavior.
Transmitting Side of UM RLC
The transmitting UM entity generates a UMD PDU for each RLC SDU. When the lower layer signals a transmission opportunity that is smaller than the SDU, the UM sender segments the SDU so the resulting UMD PDUs fit the indicated size.
SN handling is tied to TX_Next. If a UMD PDU contains a segment of an RLC SDU, the SN is set to TX_Next. If that PDU contains the last segment of the RLC SDU, then TX_Next is incremented. This is the core sender-side rule that keeps UM segmentation and sequence progression aligned.
Receiving Side of UM RLC
The receiving UM entity detects lower-layer loss indirectly through missing sequence progress and incomplete segment sets. It reassembles RLC SDUs from received UMD PDUs and delivers reassembled SDUs upward as soon as they become available.
If the related data has been lost at lower layers and the missing part can no longer be resolved within the UM procedure rules, the entity discards UMD PDUs that cannot be reassembled into a correct SDU. This is the key practical difference from AM: UM detects and reacts to loss, but it does not request retransmission through a peer feedback loop.
UM Reassembly Window
The receiving UM entity maintains a reassembly window using RX_Next_Highest. A sequence number is within the UM reassembly window when (RX_Next_Highest - UM_Window_Size) <= SN < RX_Next_Highest. This window determines what is still in relevant receive scope and what should be treated as too old.
UM_Window_Size is 32 for 6-bit SN and 2048 for 12-bit SN. Window behavior matters because it controls whether received data is accepted for buffering, directly processed, or discarded as outside the meaningful reassembly range.
UM Data Transfer Behavior
Clause 5.2.2 for UM can be read as a set of receive decisions tied to header presence and sequence placement. If the header carries no SN, the receiver can deliver directly because the PDU represents a complete SDU case without segmented sequence handling. If segmented sequence handling is active, the receiver decides whether to discard the PDU as too old for the current window or to buffer it for later reassembly.
When all byte segments for a given SN are available, the UM entity reassembles the SDU, removes the relevant headers, and delivers the result upward. This is the practical center of UM behavior: receive-side completion is driven by whether the segmented data needed for one SDU has become complete inside the active receive window.
| UM procedure case | Typical action |
|---|---|
| No SN in header | Direct delivery path. |
| Old-window case | Discard according to UM receive rules. |
| Within active window but incomplete | Buffer for possible later reassembly. |
| All required segments present | Reassemble and deliver upward. |
t-Reassembly in UM
t-Reassembly is the UM receive-side timer used to detect lower-layer loss in a practical way. It limits how long the receiver waits for missing sequence progress before advancing the receive state and discarding older data that can no longer contribute to a correct reassembly outcome.
When t-Reassembly expires, the UM entity updates RX_Next_Reassembly, discards older segments as required by the procedure logic, and may restart t-Reassembly if remaining gaps still justify continued waiting. Only one t-Reassembly per RLC entity can run at a time.
UM State Variables and Runtime Control
UM runtime control is simpler than AM but still important. The transmit side uses TX_Next. The receive side uses RX_Next_Reassembly, RX_Timer_Trigger, and RX_Next_Highest. The main fixed constant is UM_Window_Size, and the main timer is t-Reassembly.
| UM variable or control value | Main role |
|---|---|
| TX_Next | Tracks the next UM sequence number used for segmented transmission progress. |
| RX_Next_Reassembly | Tracks the next receive-side point from which reassembly can advance. |
| RX_Timer_Trigger | Tracks the receive-side context tied to t-Reassembly behavior. |
| RX_Next_Highest | Tracks the highest receive progress point currently observed. |
| UM_Window_Size | Defines the receive reassembly-window size: 32 for 6-bit SN and 2048 for 12-bit SN. |
| t-Reassembly | Controls how long the entity waits before moving past unresolved missing data. |
Use Variables, Constants, and Timers for the deeper formal definitions and arithmetic details behind these values.
Why UM Is Used
UM is used because it offers a useful engineering tradeoff. It is more structured than TM because it supports segmentation and receive-side reassembly behavior, but it is lighter than AM because it avoids retransmission, STATUS feedback, and the associated control overhead.
In practical terms, UM is the mode for cases where segmentation and reassembly are still needed, but the full cost and behavior of AM recovery are not justified.
Trace Reading Notes
At protocol level, UM traces are usually easier to read than AM traces because there is no ARQ feedback path. A complete UMD PDU may carry no SN. Segmented UMD PDUs rely on SI, SN, and sometimes SO. UM issues usually appear as buffering, reassembly-window, and t-Reassembly behavior rather than as poll or STATUS loops.
| Trace clue | What it usually means |
|---|---|
| UMD without SN | Likely complete-SDU case with direct delivery behavior. |
| UMD with SN and no SO | Segmented case carrying the first segment. |
| UMD with SN and SO | Segmented case carrying a non-first segment. |
| Receive progress waits then advances on timeout | t-Reassembly is shaping reassembly-window progression. |
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 UM lighter than AM?
Because UM does not use ARQ retransmission or STATUS-based peer feedback, so it avoids the full AM recovery loop.
Can UMD PDUs carry whole SDUs and segments?
Yes. A UMD PDU can carry one complete RLC SDU or one RLC SDU segment depending on whether segmentation was needed.
When does SO appear in UM?
SO appears only when the UMD PDU carries a segment that is not the first segment of the original RLC SDU.
What is the most important UM timer?
t-Reassembly is the main UM timer because it controls how the receiving entity reacts when missing segments delay reassembly progress.