Menu
Latest
12 meetings · Prague, Jeju · 12–16 Oct
Reports
RAN1#126-bis · SA2#177

Glossary term · QoS

L4S

Low Latency, Low Loss, and Scalable Throughput

QoS →

L4S is a framework for achieving ultra-low latency, minimal packet loss, and scalable throughput in IP networks by allowing latency-sensitive traffic to coexist with standard traffic without separate queues.

Introduced
Rel-18
Where
Services › Codecs
Specifications
11 specs
Also in
Core Network
L4S Description Purpose What changed Neighbours Detected Changes Specifications

Description

Low Latency, Low Loss, and Scalable Throughput (L4S) is a Quality of Service (QoS) framework standardized by 3GPP and IETF to enable extremely low queuing delays and near-zero packet loss in IP networks, particularly for 5G and beyond. It operates by modifying the behavior of both endpoints and network nodes to signal and manage latency-critical traffic. The core mechanism involves using the Explicit Congestion Notification (ECN) field in the IP header with a new L4S codepoint (ECT(1) or CE) to distinguish packets that require low-latency treatment. When a network node (like a router or UPF) experiences incipient congestion, it can mark these L4S packets with the CE codepoint at a very low queueing delay threshold, rather than dropping them or waiting for deep queues. This immediate feedback allows the sender (e.g., a UE or server) to react almost instantly using scalable congestion control algorithms like TCP Prague or equivalent real-time transport protocols, reducing its sending rate before significant queuing builds up.

Architecturally, L4S requires support in the end-to-end path: the sender must generate packets with the L4S ECN codepoint and use a scalable congestion control algorithm that reacts to single marked packets with a multiplicative decrease. The receiver must echo the ECN marks back to the sender via transport-layer acknowledgments. Critically, network nodes must implement a dual-queue coupled AQM (Active Queue Management) mechanism, such as Dual-Queue Coupled AQM (DQCA) or similar. This involves two queues: a Classic queue for standard traffic (e.g., traditional TCP) and an L4S queue for latency-sensitive traffic. The AQM applies very shallow thresholds (e.g., microseconds of queueing delay) to the L4S queue, marking packets at the first sign of congestion, while the Classic queue uses deeper thresholds. The queues are coupled so that L4S traffic does not starve Classic traffic, maintaining fairness.

In the 3GPP system, L4S is integrated into the 5G Core (5GC) and User Plane Function (UPF) to ensure low-latency treatment across the mobile network. Specifications define QoS flows and packet detection rules (PDRs) to identify and mark L4S traffic, often mapping to 5QI values designed for low latency. The UPF acts as a L4S network node, implementing the dual-queue AQM and marking packets accordingly. This enables applications like augmented reality (AR), virtual reality (VR), cloud gaming, and industrial control to achieve consistent sub-10ms latencies even under load, which is critical for immersive experiences and real-time automation. L4S thus transforms best-effort IP networks into predictable, low-latency platforms without requiring over-provisioning or dedicated physical resources.

Purpose & Motivation

L4S was created to address the fundamental limitations of traditional Internet congestion control and queue management in supporting ultra-low latency applications. Historically, TCP and standard Active Queue Management (e.g., RED, CoDel) were designed for throughput efficiency and fairness, but they induce latency due to bufferbloat—large queues in network buffers that cause delays. While solutions like DiffServ provided priority queuing, they required complex configuration, could starve background traffic, and did not scale well. The rise of 5G and demanding use cases like tactile internet, autonomous vehicles, and real-time holography necessitated a new approach that could deliver consistent microsecond-level latency without sacrificing throughput or fairness.

The motivation for L4S stems from the need for scalable low latency: as more applications require low delay, networks must handle many such flows simultaneously without performance degradation. Previous attempts, such as using separate high-priority queues, led to isolation issues and management overhead. L4S solves this by enabling low-latency and classic traffic to share the same link capacity efficiently through coupled congestion control. It leverages and extends Explicit Congestion Notification (ECN), which was underutilized, to provide immediate feedback. This allows congestion control algorithms to react within one round-trip time, minimizing queuing delays. By standardizing in 3GPP Release 18 and beyond, L4S ensures mobile networks can support the stringent requirements of future services, enabling economic scalability for operators while delivering superior user experiences.

What changed in its specifications

The latest release-to-release comparison of specifications that define L4S. Each summary describes the whole specification, not only this term.

TS 23.289Rel-18 → Rel-19

Rel-19 added 5G ProSe UE-to-UE relay, L4S congestion control, satellite access, LMR interworking, MC gateway UE, and 5MBS for non-3GPP devices. It also added UE capability for multicast MBS in RRC_INACTIVE plus two reference point descriptions.

Full comparison in TS 23.289 →
TS 23.501Rel-18 → Rel-19

Rel-19 added MPQUIC steering to multi-access PDU sessions, XR and media handling, and an Energy Information Function. It also added Local Offloading Management for edge computing, Vertical Federated Learning for AI/ML, and Ambient IoT text.

Full comparison in TS 23.501 →

Release Timeline

Detected Changes Across Releases

from 3GPP Change Requests

Specific changes extracted from the „Change history“ tables of 3GPP specifications (30 CRs across 2 releases). Complements the general historical overview above with the evidence-based evolution of this function.

Rel-18 15 changes

+ 9 more changes

Rel-19 15 changes
  • MCVideo push enhancement via ECN marking for L4S TS 23.289CR0131
  • XRM_Ph2 KI#6 L4S support in non-3GPP access TS 23.501CR5422
  • Support of ECN marking for L4S for 5G-RG TS 24.501CR6626
  • Updates for SEALDD enabled congestion control for VAL application by supporting L4S mechanism for HTTP TS 24.543CR0027
  • Updates for SEALDD enabled congestion control for VAL application by supporting L4S mechanism for CoAP TS 24.543CR0028
  • L4S support for non-3GPP accesses TS 29.244CR0891

+ 9 more changes

Defining Specifications

3GPP specifications that define or reference L4S, with the latest known release. Sourced from the 3GPP document catalog — see methodology.

SpecificationTitleRelease
TS 23.289 vk30 Mission Critical Services over 5G System Architecture Rel-20 read
TS 23.501 vk30 5G System Architecture Rel-20 read
TS 24.501 vk10 5GS NAS Protocol Specification Rel-20 read
TS 24.543 vk10 SEAL Data Delivery Management Protocol Rel-20 read
TS 26.501 vk00 5G Media Streaming Architecture Rel-20 read
TS 26.510 vj20 5G Media Streaming and Real-Time Communication APIs Rel-19 read
TS 26.512 vj30 5G Media Streaming Protocols and APIs Rel-19 read
TS 28.541 vk41 5G Network Resource Model Stage 2/3 Rel-20 read
TS 29.244 vk10 PFCP for Control and User Plane Separation Rel-20 read
TS 29.512 vk10 Session Management Policy Control Service Stage 3 Rel-20 read
TS 29.514 vk10 Policy Authorization Service Rel-20 read