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

Evolution Across Releases

Rel-4 Initial

Introduced as a core RLC mode in the UMTS Terrestrial Radio Access Network (UTRAN) architecture. Defined the fundamental procedures for unacknowledged data transfer, including PDU structure with sequence numbers, segmentation, concatenation, and reassembly. Established its use for specific radio bearers carrying conversational and streaming traffic classes.

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
Patrick Zandl

About the author: Patrick Zandl (b. 1974)

Telecommunications specialist, technology journalist (founder of the Mobil server), and developer who has been running since 2025 — the largest Czech-language resource on AI-assisted programming. Formerly Chief Wizard Architect at Prusa3D and head of development for Turris at CZ.NIC; currently a consultant and instructor on AI implementation in companies.