How L4S Can Transform 5G: Low Latency, Low Loss, Scalable Throughput Explained

L4S (Low‑Latency, Low‑Loss, Scalable‑Throughput) is a new internet service that aims to dramatically reduce queueing delay by using ECN markings and feedback to adjust the sender’s congestion‑control parameters, improving real‑time application performance.

Classic Congestion Control

Traditional TCP relies on a sliding window for flow control and a congestion window (cwnd) for congestion control. The sender’s window size is limited by the minimum of the advertised receiver window and cwnd. TCP’s slow‑start phase increases cwnd exponentially until a loss event, after which cwnd is reduced and grows linearly. Variants such as Tahoe and Reno add fast‑retransmit and fast‑recovery mechanisms.

L4S Fundamentals

L4S augments classic congestion control by allowing network devices to provide explicit congestion signals. These signals enable the sender to react more precisely, reducing unnecessary queuing and achieving lower latency without sacrificing throughput.

L4S Architecture

The architecture consists of three key components:

Host‑side support : Hosts must set the ECN field to ECT(1) in outgoing IP packets, interpret ECN‑Echo feedback, implement scalable congestion‑control algorithms, and smooth rate adjustments (RFC 9331, §4).

Network support : Network elements (switches, routers) use a dual‑queue coupled AQM to separate L4S flows (queue L) from classic flows (queue C). Each queue runs its own AQM to compute marking probabilities (p_L, p_C). When both queues are congested, L‑queue marking is influenced by C‑queue congestion to maintain fairness.

Protocol support : ECN is the signaling mechanism defined in RFC 9331. Packets marked with ECT(1) are treated as L4S‑eligible; CE marks indicate congestion, and the ECN‑Echo flag informs the sender.

Host‑Side Requirements

According to RFC 9331 §4, a host must:

Set the ECN field to ECT(1) on transmitted IP packets.

Allow the receiver to echo congestion information via the ECN‑Echo flag.

Implement a scalable congestion‑control algorithm compatible with L4S.

Apply smoothing mechanisms to avoid abrupt rate changes.

Network‑Side Mechanisms

The dual‑queue coupled AQM works as follows:

A classifier separates incoming traffic into L‑queue (L4S) and C‑queue (classic).

Each queue independently computes its own marking probability.

If only one queue is congested, only that queue’s packets are marked or dropped.

If both queues are congested, L‑queue marking probability increases with C‑queue congestion, ensuring classic‑flow friendliness.

During persistent overload, L4S packets may also be dropped to match classic‑flow loss rates.

Network devices must continue to support classic AQM for ECT(0) and non‑ECN packets for backward compatibility.

Integration with 5G (R18)

3GPP R18 introduces L4S support across NG‑RAN, UPF, SMF, PCF, and AF. The SMF orchestrates policy and charging control (PCC) rules to enable L4S ECN marking on specific QoS flows. Two deployment options exist:

NG‑RAN‑based marking : The base station marks uplink/downlink packets according to PCC‑defined QoS flows.

UPF‑based marking : The PSA UPF performs ECN marking after receiving congestion information from NG‑RAN via GTP‑U extensions.

Mobility scenarios are handled by the SMF: if a UE moves from an L4S‑capable NG‑RAN to a non‑L4S node, the SMF can instruct the target UPF to continue ECN marking, preserving low‑latency characteristics.

Policy distribution follows this flow:

AF (or PCF) signals the need for L4S ECN marking on UL/DL flows.

PCF installs PCC rules with the l4sInd attribute (UL, DL, or UL_DL).

SMF translates PCC rules into configuration for NG‑RAN or UPF, using N4 or NGAP interfaces.

When L4S support becomes unavailable (e.g., after handover), SMF notifies PCF via Npcf_SMPolicyControl_Update with the repPolicyCtrlReqTriggers indicating loss of L4S capability.

Conclusion

Combining L4S with 5G promises ultra‑low latency and high reliability for XR, remote control, industrial automation, and vehicular communications. Adoption will be gradual, similar to IPv6 rollout, requiring coordinated effort across standards bodies, equipment vendors, and operators.