ECN

Explicit Congestion Notification

QoS →
Introduced in Rel-7 Also in: Services

ECN is a network congestion management mechanism adapted for mobile networks, where routers signal impending congestion by marking packets instead of dropping them to reduce loss and latency and improve QoS.

Category
QoS
Introduced
Rel-7
Where
Core Network › 5G Core
Also touches
1 segments
Specifications
30 specs
ECN Description Purpose Related Classification Detected Changes Specifications

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

Part ofQoS

Release Timeline

Detected Changes Across Releases

from 3GPP Change Requests

Specific 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.

Rel-16 1 change

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.

Rel-18 1 change

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
Rel-19 5 changes

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
Rel-20 1 change

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.

SpecificationTitleRelease
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
Patrick Zandl

About the author: Patrick Zandl (b. 1974)

Telecommunications specialist, technology journalist (founder of the Mobil server), and developer who has been running since 2025 — the largest Czech-language resource on AI-assisted programming. Formerly Chief Wizard Architect at Prusa3D and head of development for Turris at CZ.NIC; currently a consultant and instructor on AI implementation in companies.