Description
Unacknowledged Mode (UM) is one of the three operational modes of the Radio Link Control (RLC) layer in 3GPP wireless systems, alongside Acknowledged Mode (AM) and Transparent Mode (TM). The RLC layer resides in both the User Equipment (UE) and the radio access network (RAN) node (e.g., NodeB, eNodeB, gNB) and is responsible for the transfer of upper layer protocol data units (PDUs). In UM, the primary function is the unacknowledged transfer of data. This means the transmitting RLC entity sends RLC PDUs without expecting a positive or negative acknowledgment from the receiver. Consequently, there is no automatic repeat request (ARQ) mechanism for error correction at the RLC level in this mode. The protocol handles segmentation and concatenation of RLC service data units (SDUs) from the upper layers into RLC PDUs for transmission, and performs reassembly of these PDUs back into SDUs at the receiver.
Architecturally, an RLC entity configured in UM has a transmitting side and a receiving side. The transmitting side includes a transmission buffer and functionality for segmentation/concatenation and PDU construction. A key component is the sequence numbering. Each RLC PDU is assigned a sequence number within a finite range, which is included in the PDU header. This sequence number is essential for the receiver's operation. The receiving side utilizes a reassembly buffer. It uses the sequence numbers to detect any missing PDUs (due to errors or loss over the air interface) and to ensure in-sequence delivery of RLC SDUs to the upper layer. Since delivery is not guaranteed, detected missing PDUs are not requested for retransmission; instead, the RLC may deliver a partially reassembled SDU or indicate an error, depending on configuration and the nature of the upper layer service.
The role of UM in the network is to support services that are sensitive to delay and jitter but can tolerate a certain level of packet loss. The absence of ARQ retransmissions avoids the introduction of variable and potentially large delays that come with waiting for acknowledgments and performing retransmissions. This makes UM ideal for real-time services carried over packet-switched networks, such as Voice over IP (VoIP) using the Internet Protocol (IP) Multimedia Subsystem (IMS), or streaming video. The in-sequence delivery feature is still important to maintain the order of packets, as out-of-order delivery could severely degrade the quality of these real-time applications. The configuration of UM (e.g., sequence number field size) is determined by the Radio Resource Control (RRC) layer based on the requirements of the established radio bearer.
Purpose & Motivation
Unacknowledged Mode was created to efficiently support real-time, streaming, and broadcast/multicast services over 3GPP packet-switched networks. Prior to widespread packet data, circuit-switched voice had guaranteed, constant bitrate channels. With the move to IP-based services, a mechanism was needed to carry delay-sensitive IP packets over the unreliable wireless link without introducing the latency overhead of retransmission protocols. Pure, connectionless IP delivery could result in out-of-order packets causing poor application performance. UM solves this by providing a lightweight, connection-oriented link layer service that adds sequence numbering for in-order delivery but deliberately omits acknowledgment and retransmission to keep latency minimal.
The problem it addresses is the fundamental trade-off between reliability and latency. Acknowledged Mode (AM) with ARQ provides high reliability but variable, potentially high latency, which is suitable for data traffic like web browsing or file transfer. For real-time conversational or streaming traffic, this latency is unacceptable. Transparent Mode (TM) offers even lower processing overhead but does not provide segmentation or in-sequence delivery, limiting its use. UM occupies the critical middle ground, adding necessary sequencing and reassembly functions for packet-based real-time services while avoiding the delay penalty of reliability mechanisms. Its creation was motivated by the need to define quality of service (QoS) differentiation at the RLC layer, enabling the network to optimize transport for different traffic types, a cornerstone of the Universal Mobile Telecommunications System (UMTS) and subsequent 4G and 5G architectures.
Classification
Detected Changes Across Releases
from 3GPP Change RequestsSpecific changes extracted from the „Change history“ tables of 3GPP specifications (6 CRs across 2 releases). Complements the general historical overview above with the evidence-based evolution of this function.
Studied in Rel-4, normative work from Rel-15.
In Release 15, enhancements for Unacknowledged Mode (UM) included clarifying the RLC UM Sequence Number size for NB-IoT and specifying the delivery of stored PDCP SDUs for a UM DRB during PDCP re-establishment. Additionally, a change was introduced to avoid a security risk for RLC UM bearers during a termination point change. These updates provided clarifications and security improvements to the unacknowledged data transfer service within the Radio Link Control sublayer.
In Release 16, specific enhancements were made to the Unacknowledged Mode function, focusing on the PDCP re-establishment procedure for UM DRBs when the t-Reordering timer is running and addressing an incorrect restriction for RLC UM radio bearers. Furthermore, the release introduced a method for avoiding a security risk for RLC UM bearers during a termination point change. These updates refined the behavior and security of the Radio Link Control sublayer's unacknowledged data transfer service.
Explore further
Broader topics and technologies where UM plays a role.
Defining Specifications
3GPP specifications that define or reference UM, with the latest known release. Sourced from the 3GPP document catalog — see methodology.
| Specification | Title | Release |
|---|---|---|
| TR 21.905 vj00 | 3GPP Technical Terms and Definitions | Rel-19 |
| TS 23.179 vd50 | MCPTT Functional Architecture | Rel-13 |
| TS 23.282 vk00 | MCData Functional Architecture & Info Flows | Rel-20 |
| TS 23.379 vk00 | MCPTT Functional Architecture | Rel-20 |
| TR 24.980 vg00 | MCPTT IMS Profile for Gm Reference Point | Rel-16 |
| TS 25.322 vj00 | RLC Protocol Specification | Rel-19 |
| TS 25.331 vj00 | UTRAN RRC Protocol Specification | Rel-19 |
| TR 25.912 vj00 | Evolved UTRA and UTRAN Technical Report | Rel-19 |
| TR 25.931 vj00 | UTRAN Signalling Procedures Examples | Rel-19 |
| TR 26.935 vj00 | Speech Codec Performance for Packet Switched Multimedia | Rel-19 |
| TS 31.115 vj00 | Secured Packet Structure for UICC Applications | Rel-19 |
| TS 36.300 vj00 | E-UTRAN Radio Interface Protocol Architecture Overview | Rel-19 |
| TS 36.302 vj00 | E-UTRA Physical Layer Services | Rel-19 |
| TS 36.322 vj00 | E-UTRA Radio Link Control Protocol Specification | Rel-19 |
| TS 36.323 vj00 | PDCP Protocol Specification | Rel-19 |
| TS 36.331 vj00 | LTE RRC Protocol Specification | Rel-19 |
| TS 37.579 vi40 | Mission Critical services conformance testing | Rel-18 |
| TS 38.322 vj00 | NR Radio Link Control (RLC) Protocol | Rel-19 |
| TS 38.323 vj00 | Packet Data Convergence Protocol (PDCP) | Rel-19 |
| TS 38.331 vj00 | NR Radio Resource Control (RRC) Protocol Specification | Rel-19 |