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
Release Timeline
Detected Changes Across Releases
from 3GPP Change RequestsSpecific 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.
In Release 18, 3GPP introduced support for the Low Latency, Low Loss, and Scalable Throughput (L4S) function, enabling Explicit Congestion Notification (ECN) marking for L4S on a per-QoS flow basis in the 5G System for both uplink and downlink directions. This feature allows a Mission Critical (MC) service server to request L4S marking from the network to obtain congestion information, with end-points like an MCVideo client and server generating L4S feedback reports based on ECN marks in the IP header. The support includes policy control, traffic steering to L4S-enabled QoS flows, and procedures for both video pull from server and video push enhancements utilizing this capability.
- Introduction of support for L4S TS 23.501CR3855
- ECN marking for L4S TS 29.244CR0721
- Traffic steering to an L4S enabled QoS flow TS 29.244CR0753
- Policy Control for L4S TS 29.512CR1100
- Definition of L4S feature TS 29.512CR1155
- Policy Control for L4S TS 29.514CR0528
+ 9 more changes
In Release 19, the L4S function was expanded to support video push enhancements for Mission Critical (MCVideo) services and its support was extended to non-3GPP accesses. The release introduced specific signaling procedures for MCVideo push and pull scenarios where the server can request ECN marking from the 5G system to obtain congestion feedback for both uplink and downlink stream control. Furthermore, it included numerous corrections and clarifications to the ECN marking mechanisms, QoS flow behaviors, and capability indications to solidify the feature's implementation.
- 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.
| Specification | Title | Release |
|---|---|---|
| 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 |