Description
ECN Congestion Experienced (ECN-CE) is a defined state within the Explicit Congestion Notification (ECN) framework, where the ECN field in the IP header is set to '11' (binary) to indicate that the packet has traversed a congested network node. In 3GPP systems, ECN-CE is utilized as part of end-to-end congestion control across mobile core networks, particularly in the Evolved Packet Core (EPC) and 5G Core (5GC). When a router, gateway, or other network element detects impending congestion—typically through queue monitoring algorithms like Random Early Detection (RED) or Controlled Delay (CoDel)—it marks ECN-capable packets with the CE codepoint instead of dropping them. This marking serves as an explicit signal to the transport layer (e.g., TCP or QUIC) that congestion is occurring, prompting the sender to reduce its transmission rate. The process involves the interaction of IP layer marking with higher-layer protocols to achieve efficient traffic management.
Architecturally, ECN-CE operates within the broader ECN mechanism defined in IETF RFC 3168 and adapted by 3GPP. Key components include the ECN field in IPv4 or IPv6 headers, which consists of two bits: the first bit (ECT) indicates ECN capability, and the second bit (CE) is set to 1 when congestion is experienced. In mobile networks, nodes such as the PGW/UPF, TDF, or PCEF may apply CE marking based on real-time congestion metrics or policy rules from the PCRF/PCF. The role of ECN-CE is to provide a precise congestion indicator that endpoints can use to adjust their behavior without relying on loss-based inference, which is especially valuable in wireless environments where losses may also stem from radio link errors.
How ECN-CE works in practice involves several steps. Endpoints indicate their ECN support by setting ECT bits during session establishment. As packets flow through the network, congested nodes check queue thresholds; if exceeded, they mark packets with CE, provided the ECT bits show capability. In 3GPP, this often occurs at bottlenecks like the SGi interface or within GTP tunnels between core elements. Upon receipt, the receiver detects the CE mark and communicates it back to the sender via transport-layer acknowledgments (e.g., TCP ACKs with ECN-Echo). The sender then invokes congestion avoidance algorithms, such as reducing the congestion window, to mitigate the congestion. 3GPP specifications, such as those for QoS and policy control, ensure ECN-CE is integrated with traffic management functions to support diverse services, from bulk data to real-time communications.
Purpose & Motivation
ECN-CE was created to provide a clear, explicit signal of network congestion within the ECN framework, addressing the need for more accurate congestion feedback than packet drops alone. In mobile networks, where congestion can quickly degrade user experience due to limited bandwidth and variable conditions, ECN-CE enables timely rate adaptation, reducing the risk of bufferbloat and excessive latency. It solves the problem of ambiguous congestion indicators, as packet loss in wireless networks may result from radio errors rather than congestion, leading to inappropriate transport responses.
The historical context stems from IETF's development of ECN, with ECN-CE defined as a specific codepoint in RFC 3168. 3GPP incorporated ECN-CE starting in Release 9 to enhance congestion management for LTE and beyond, building on earlier ECN foundations. Prior approaches relied on implicit signals like packet drops, which could cause unnecessary retransmissions and throughput fluctuations, particularly harmful for real-time services. ECN-CE offered a standardized way to distinguish congestion from other loss causes, improving network efficiency.
Motivations for ECN-CE in 3GPP include supporting low-latency applications like VoIP and video streaming by enabling proactive congestion control, aligning with QoS objectives for 4G and 5G. It addresses limitations of previous congestion mechanisms that lacked granular signaling, facilitating better resource utilization and user satisfaction. ECN-CE also enables compliance with evolving internet standards and supports advanced features like network slicing, where differentiated congestion handling is required.
Key Features
- Specific IP header codepoint (binary '11') indicating packet marking due to network congestion
- Triggers endpoint rate adaptation mechanisms in ECN-capable transport protocols like TCP
- Integration with 3GPP policy control for conditional marking based on subscriber or service policies
- Applicability in mobile core nodes (e.g., UPF, PGW) and at key interfaces (SGi, N6)
- Reduces reliance on packet loss as a congestion signal, minimizing unnecessary retransmissions
- Supports differentiated congestion management for various traffic types and network slices
Evolution Across Releases
Introduced ECN-CE as a defined congestion signaling codepoint within the ECN framework in 3GPP. Initial architecture focused on marking packets with CE in LTE/EPC networks to enable explicit congestion notification, with integration into QoS and policy mechanisms for improved traffic management in congested scenarios.
Enhanced ECN-CE support for 5G networks, including marking capabilities in the UPF and alignment with 5G QoS characteristics. Extended usage for network slicing and URLLC services, allowing fine-grained congestion indication to meet diverse performance requirements in next-generation mobile systems.
Defining Specifications
| Specification | Title |
|---|---|
| TS 23.333 | 3GPP TS 23.333 |
| TS 23.334 | 3GPP TS 23.334 |
| TS 26.114 | 3GPP TS 26.114 |
| TS 29.162 | 3GPP TS 29.162 |
| TS 29.163 | 3GPP TS 29.163 |
| TS 36.750 | 3GPP TR 36.750 |