Description
Congestion Experienced (CE) is a codepoint within the Explicit Congestion Notification (ECN) field of the IP header, standardized in RFC 3168 and adopted by 3GPP specifications. In 3GPP networks, CE functions as a critical Quality of Service (QoS) mechanism that provides early warning of network congestion without requiring packet drops. When network elements (such as routers, gateways, or radio nodes) detect impending congestion based on queue lengths or buffer occupancy, they mark the ECN field in IP packet headers with the CE codepoint instead of dropping packets. This marking travels end-to-end, informing both the sender and receiver that congestion is occurring along the path.
The CE mechanism operates through a coordinated interaction between network elements and end-host transport protocols. Network elements capable of ECN (ECN-Capable Transport, or ECT) monitor their queues and apply CE marking according to configured thresholds, typically using Active Queue Management (AQM) algorithms like Random Early Detection (RED). When a packet marked with CE arrives at the receiver, the receiver echoes this congestion indication back to the sender using transport-layer acknowledgments (e.g., TCP ECN-Echo). Upon receiving this feedback, the sender reduces its transmission rate through congestion control algorithms, thereby alleviating the congestion before it leads to packet loss.
Within the 3GPP architecture, CE marking can be applied at multiple points: in the Radio Access Network (RAN) at eNodeBs/gNBs for air interface congestion, in the Core Network at gateways (PGW/UPF) for backhaul and core congestion, and at interconnection points between operators. 3GPP specifications define how CE interacts with QoS Flow management, bearer services, and policy control. The mechanism is particularly valuable in mobile networks where radio conditions are variable and congestion can occur rapidly. By using CE instead of packet drops, networks maintain higher throughput and lower latency for real-time services like VoIP and video streaming.
Key technical components include the 2-bit ECN field in the IP header (with values 00 for Non-ECT, 01/10 for ECT, and 11 for CE), ECN-capable transport protocols (TCP, SCTP, QUIC), and AQM implementations in network equipment. 3GPP ensures interoperability by specifying CE handling across interfaces (S1, N3, N6, etc.) and in protocol layers (PDCP, GTP-U, IP). The effectiveness of CE depends on proper configuration of marking thresholds and widespread deployment of ECN support in both network infrastructure and end devices.
Purpose & Motivation
CE was created to address the fundamental problem of network congestion in packet-switched networks, where traditional congestion control relies on packet loss as a congestion signal. This reactive approach causes significant performance degradation: packet loss triggers retransmissions, increases latency, and reduces throughput, particularly harming delay-sensitive applications. In mobile networks, where bandwidth is scarce and shared dynamically, these effects are magnified. CE provides an explicit, proactive signaling mechanism that allows endpoints to reduce transmission rates before congestion leads to packet loss, thereby improving overall network efficiency and user experience.
The motivation for CE within 3GPP stems from the need to support diverse services with stringent QoS requirements, especially as networks evolved toward all-IP architectures in 3G and beyond. Prior to ECN/CE, congestion management often involved tail-drop queues, which lead to bufferbloat, synchronization problems, and unfairness among flows. CE enables finer-grained congestion control, reduces the latency and jitter that plague real-time communications, and allows networks to operate at higher utilization without sacrificing performance. It aligns with 3GPP's focus on end-to-end QoS across heterogeneous access technologies.
Historically, CE's integration into 3GPP standards addressed limitations in earlier congestion control methods that were insufficient for LTE and 5G's low-latency, high-reliability use cases. By adopting IETF's ECN standard, 3GPP provided a standardized way for mobile networks to participate in Internet-wide congestion management. This is especially critical for enabling efficient transport for services like VoLTE, video streaming, and IoT applications, where predictable performance is essential. CE solves the problem of silent congestion—where packets are delayed excessively in buffers without being dropped—by providing an explicit signal that triggers timely congestion avoidance responses.
Evolution Across Releases
Introduced initial support for congestion management mechanisms in the IP Multimedia Subsystem (IMS) and packet-switched domains. CE was defined as part of QoS architecture for UMTS, enabling basic congestion signaling between network elements and endpoints to improve service reliability in early 3G networks.
Explore further
Broader topics and technologies where CE plays a role.
Defining Specifications
3GPP specifications that define or reference CE, with the latest known release. Sourced from the 3GPP document catalog — see methodology.
| Specification | Title | Release |
|---|---|---|
| TS 23.202 vj00 | CS Bearer Services Architecture in UMTS | Rel-19 |
| TR 23.737 vh20 | Satellite Access in 5G Architecture Study | Rel-17 |
| TR 23.910 v1400 | UMTS Circuit Switched Bearer Services Overview | Rel-5 |
| TS 28.310 vj20 | Energy Efficiency Management for 5G Networks | Rel-19 |
| TS 28.880 vj00 | Study on 5G Energy Efficiency & Saving | 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.332 vj00 | MGCF-IM-MGW Interface Protocol (Mn) | Rel-19 |
| TS 29.333 vj00 | MRFC-MRFP Mp Interface Protocol | Rel-19 |
| TS 32.425 vj00 | E-UTRAN Performance Measurements | Rel-19 |
| TS 36.331 vj00 | LTE RRC Protocol Specification | Rel-19 |
| TS 36.423 vj10 | X2 Application Protocol (X2AP) Specification | Rel-19 |
| TS 38.321 vj00 | NR MAC Protocol Specification | Rel-19 |
| TS 38.762 vj00 | Dynamic MIMO OTA Test Methodology for NR FR1 | Rel-19 |