Description
Explicit Congestion Notification (ECN) is a congestion control mechanism defined in IETF RFC 3168 and adopted by 3GPP for use in mobile packet core networks. It enables network nodes (e.g., routers, gateways) to notify endpoints of congestion by setting ECN bits in the IP header of packets, instead of relying solely on packet drops as implicit signals. In 3GPP architectures, ECN is integrated into the Evolved Packet Core (EPC) and 5G Core (5GC) to manage traffic flows, particularly over GTP tunnels and SGi/N6 interfaces. The process involves two bits in the IP header: the ECN-Capable Transport (ECT) bit indicates endpoint support, and the Congestion Experienced (CE) bit is set by congested routers to signal congestion. Endpoints, upon receiving CE-marked packets, reduce their transmission rates proactively, mitigating congestion before it leads to packet loss.
Architecturally, ECN operates across multiple layers in 3GPP systems. At the IP layer, it interacts with transport protocols like TCP and QUIC, which must be ECN-aware to respond to congestion notifications. In the mobile core, elements such as the PGW/UPF, TDF, or PCEF may implement ECN marking based on policy controls or real-time congestion detection. Key components include the ECN field in IPv4 or IPv6 headers, congestion detection algorithms in network nodes (e.g., queue management like RED or CoDel), and endpoint congestion response mechanisms. ECN's role is to enhance Quality of Service (QoS) by reducing packet loss and jitter, which is critical for delay-sensitive applications like voice, video, and interactive gaming in mobile networks.
How ECN works in a 3GPP context involves several steps. First, endpoints negotiate ECN capability during transport session setup. As packets traverse the network, routers monitor queue lengths; if congestion is imminent, they mark packets with CE instead of dropping them, provided the packets are ECN-capable. In mobile networks, this marking can occur at bottlenecks like the SGi interface between the PGW and the internet, or within the core during high traffic loads. The marked packets are delivered to the receiver, which echoes the congestion signal back to the sender via transport-layer acknowledgments. The sender then throttles its transmission rate, easing congestion. 3GPP specifications extend ECN to support differentiated services and integration with QoS frameworks like PCC (Policy and Charging Control), allowing operators to apply ECN policies based on subscriber profiles or service types.
Purpose & Motivation
ECN was created to address the inefficiencies of traditional congestion control, which relies on packet loss as an implicit signal of network congestion. In mobile networks, packet loss can be particularly detrimental due to radio variability and limited bandwidth, causing increased latency and reduced throughput for applications. ECN solves this by providing explicit, early congestion notifications, allowing endpoints to react before loss occurs, thus improving overall network efficiency and user experience.
The historical context traces back to IETF efforts in the late 1990s to enhance Internet congestion management, leading to RFC 3168. 3GPP adopted ECN starting in Release 7 to optimize packet-switched services in UMTS and later LTE/5G networks. Prior approaches, like tail-drop or RED without ECN, led to unnecessary packet drops and TCP timeouts, degrading performance for real-time applications. ECN offered a proactive alternative, aligning with 3GPP's goals for enhanced QoS and support for multimedia services.
Motivations for ECN in 3GPP include reducing latency for low-latency applications, conserving radio resources by minimizing retransmissions, and enabling better traffic management in congested scenarios. It addresses limitations of earlier mobile data systems that lacked sophisticated congestion signaling, supporting the evolution toward all-IP networks and rich media services. ECN also facilitates compliance with regulatory requirements for network neutrality and efficient resource utilization.
Classification
Release Timeline
Detected Changes Across Releases
from 3GPP Change RequestsSpecific changes extracted from the „Change history“ tables of 3GPP specifications (8 CRs across 4 releases). Complements the general historical overview above with the evidence-based evolution of this function.
In Release 16, Explicit Congestion Notification (ECN) support was specifically introduced for the 5G New Radio (NR) user plane. This enhancement enables the marking and forwarding of ECN indications between the UE and the network. The work item "ECN Support in NR" established the necessary procedures and capabilities to facilitate end-to-end congestion control across the 5G system.
- ECN Support in NR TS 26.919CR0001
In Release 18, the new work for ECN focused on defining the interactions between ECN marking for the Low Latency, Low Loss, Scalable throughput (L4S) service and existing Congestion Monitoring functions. This involved specifying how these two mechanisms operate together within the system.
- Interactions between ECN marking for L4S and Congestion Monitoring TS 29.514CR0589
In Release 19, the ECN function was enhanced to support L4S (Low Latency, Low Loss, Scalable throughput) for new services and devices. Specifically, this included enabling ECN marking for L4S in 5G-RG (Residential Gateway) deployments and for MCVideo push services. The release also introduced corrections and clarifications to the related procedures, including the definition of an IP PDU session type term and fixes to the ECN marking for L4S indication information element.
- MCVideo push enhancement via ECN marking for L4S TS 23.289CR0131
- Support of ECN marking for L4S for 5G-RG TS 24.501CR6626
- Corrections in clauses related to ECN marking for L4S TS 23.289CR0130
- Correction to ECN marking for L4S indication TS 24.501CR6690
- Term defined for IP PDU session type and minor fixes in ECN marking for L4S indication IE TS 24.501CR6991
In Release 20, a key enhancement for the ECN (Explicit Congestion Notification) function was the introduction of specific support within policy control. The update focused on modifying the "PreDefinedPccRule" managed object in the network management system to explicitly include parameters for ECN marking. This change standardized how network operators can configure policy rules to enable or control ECN marking for user plane traffic directly from the management interface.
- Rel-20 CR TS 28.541 Enhancement on PreDefinedPccRule for ECN marking TS 28.541CR1569
Explore further
Broader topics and technologies where ECN plays a role.
Defining Specifications
3GPP specifications that define or reference ECN, with the latest known release. Sourced from the 3GPP document catalog — see methodology.
| Specification | Title | Release |
|---|---|---|
| TS 22.495 v1700 | NGN Requirements for IMS Services | Rel-7 |
| TS 23.228 vj50 | IMS Stage-2 Service Description | Rel-19 |
| TS 23.289 vk10 | Mission Critical services over 5G System | Rel-20 |
| TS 23.333 vj00 | MRFC-MRFP Mp Interface Requirements | Rel-19 |
| TS 23.334 vj00 | IMS-ALG to IMS-AGW Interface (Iq) Stage 2 | Rel-19 |
| TS 23.401 vj50 | Evolved Packet System (EPS) Stage 2 Description | Rel-19 |
| TS 23.802 v1700 | Enhanced End-to-End QoS Architecture | Rel-7 |
| TS 23.860 va00 | Codec Rate Adaptation Enhancements Study | Rel-10 |
| TS 24.229 vj50 | IMS call control protocol based on SIP and SDP | Rel-19 |
| TS 24.501 vj50 | 5G NAS Protocols Specification | Rel-19 |
| TS 24.543 vj50 | SEAL Data Delivery Management Protocol | Rel-19 |
| TS 26.114 vj10 | IMS Multimedia Telephony Media Handling | 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 26.804 vj10 | 5G Media Streaming Extensions Study | Rel-19 |
| TR 26.919 vj00 | Study on 5G Conversational Media Handling | Rel-19 |
| TS 28.541 vk00 | 5G Network Resource Model (NRM) Stage 2/3 | Rel-20 |
| TS 29.162 vj00 | IMS-IP Network Interworking | Rel-19 |
| TS 29.163 vj00 | Interworking between 3GPP IM CN and CS networks | Rel-19 |
| TS 29.232 vj00 | Mc Interface Protocol Profile | Rel-19 |
| TS 29.238 vj00 | H.248 Profile for IBCF-TrGW Interface | Rel-19 |
| TS 29.292 vj00 | IMS Centralized Services (ICS) Interworking | Rel-19 |
| TS 29.332 vj00 | MGCF-IM-MGW Interface Protocol (Mn) | Rel-19 |
| TS 29.333 vj00 | MRFC-MRFP Mp Interface Protocol | Rel-19 |
| TS 29.334 vj00 | IMS-ALG to IMS-AGW Interface Protocol | 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 |
| TS 36.750 ve10 | Study on enhancement of VoLTE | Rel-14 |
| TS 38.415 vj10 | PDU Session User Plane Protocol | Rel-19 |