UM

Unacknowledged Mode

Protocol →
Introduced in Rel-4 Also in: Services

UM is an RLC protocol mode for unacknowledged data transfer that ensures in-sequence delivery but not guaranteed delivery, making it suitable for delay-sensitive traffic like voice or video.

Category
Protocol
Introduced
Rel-4
Where
Radio Access Network › NG-RAN (5G)
Also touches
1 segments
Specifications
20 specs
UM Description Purpose Related Classification Detected Changes Specifications

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

Part ofRLC

Detected Changes Across Releases

from 3GPP Change Requests

Specific 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.

Rel-15 3 changes

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.

  • Clarification on RLC UM SN size for NB-IoT TS 36.322CR0145
  • Deliver stored PDCP SDUs for UM DRB at PDCP re-establishment TS 36.323CR0241
  • Avoiding security risk for RLC UM bearers during termination point change TS 38.331CR0570
Rel-16 3 changes

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.

  • CR on LTE PDCP re-establishment for UM DRB when t-Reordering is used TS 36.323CR0291
  • Incorrect restriction for RLC UM radio bearers TS 36.331CR4385
  • Avoiding security risk for RLC AM and RLC UM bearers during termination point change TS 36.331CR4293

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.

SpecificationTitleRelease
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