L4S

Low Latency, Low Loss, and Scalable Throughput

QoS →
Introduced in Rel-18 Also in: Core Network

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.

Category
QoS
Introduced
Rel-18
Where
Services › Codecs
Also touches
1 segments
Specifications
11 specs
L4S Description Purpose Related Classification 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.

Classification

Part of5QI
Related approachesECN

Detected Changes Across Releases

from 3GPP Change Requests

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

Rel-17 1 change

In Release 17, support for Low Latency, Low Loss, and Scalable Throughput (L4S) was introduced, enabling the 5G System to apply Explicit Congestion Notification (ECN) marking on a per-QoS flow basis for both uplink and downlink directions to expose network congestion information. This feature is specifically applied to enhance Mission Critical (MC) video services, where an MCVideo server can request L4S marking from the network, and clients and servers exchange standardized L4S feedback reports to control media transmission rates based on congestion. The procedures defined include enhancements for both one-from-server video pull and one-to-server video push scenarios utilizing this L4S capability.

  • Introduction of support of GSMA NG.116 attributes Maximum DL/UL throughput per slice/UE TS 23.501CR2822
Rel-18 15 changes

In Release 18, the L4S function was introduced, enabling Explicit Congestion Notification (ECN) marking for L4S on a per-QoS flow basis for both uplink and downlink traffic to expose network congestion information. New capabilities include policy control for L4S, traffic steering to L4S-enabled QoS flows, and support for Mission Critical services where an MCVideo server can request L4S marking from the 5G system and exchange L4S feedback reports with the client to improve stream transmission control.

+ 9 more changes

Rel-19 15 changes

In Release 19, the L4S function was expanded to enhance Mission Critical (MCVideo) services by formally specifying procedures for video push enhancement using ECN marking for L4S, complementing the existing pull mechanism. The release also included numerous corrections and clarifications to the technical implementation of ECN marking for L4S, such as updates to the UPF behavior, the <L4S-feedback-capability> element, and the definition of a QoS flow for L4S. Furthermore, support for L4S was extended to non-3GPP accesses and for use with 5G-RG devices.

  • 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

Explore further

Broader topics and technologies where L4S plays a role.

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 vk10 Mission Critical services over 5G System Rel-20
TS 23.501 vk00 5G System Architecture Stage 2 Rel-20
TS 24.501 vj50 5G NAS Protocols Specification Rel-19
TS 24.543 vj50 SEAL Data Delivery Management Protocol Rel-19
TS 26.501 vj30 5G Media Streaming (5GMS) Architecture Rel-19
TS 26.510 vj10 Media Delivery APIs for 5GMS and RTC Systems Rel-19
TS 26.512 vj10 5G Media Streaming Protocols & APIs Rel-19
TS 28.541 vk00 5G Network Resource Model (NRM) Stage 2/3 Rel-20
TS 29.244 vj40 PFCP Specification for Control/User Plane Separation Rel-19
TS 29.512 vj40 5G Session Management Policy Control Service Rel-19
TS 29.514 vj40 5G System; Policy Authorization Service; Stage 3 Rel-19