Description
Explicit Congestion Notification-Capable Transport (ECT) refers to the implementation of the Explicit Congestion Notification (ECN) mechanism as defined in IETF RFC 3168, which has been adopted and referenced within 3GPP specifications for transport protocols. ECN is an extension to the Internet Protocol (IP) and Transmission Control Protocol (TCP) that allows routers to mark packets with a Congestion Experienced (CE) codepoint instead of dropping them when congestion is imminent. An ECT-capable transport layer, such as TCP, must negotiate the use of ECN at connection setup and then properly interpret and react to these CE markings from the network.
The operation of ECT involves two main phases: capability negotiation and congestion signaling. During TCP connection establishment, endpoints set the ECN-Echo (ECE) and Congestion Window Reduced (CWR) flags in the TCP header to indicate they are ECN-capable (ECT). Once the connection is established, IP routers monitor their queue lengths. When a queue exceeds a configured threshold, indicating incipient congestion, the router marks the IP header's ECN field in passing packets to CE (Congestion Experienced), provided the packet was sent as ECT(0) or ECT(1) by the sender. The receiver detects this CE mark and echoes it back to the sender by setting the ECE flag in subsequent TCP ACK packets. Upon receiving this echo, the sender reduces its congestion window as if a packet loss had occurred, thereby alleviating the congestion without requiring packet drops and retransmissions.
Within the 3GPP architecture, ECT is relevant for transport connections used by network functions and user equipment. Specifications like TS 29.165 (GTP) and TS 36.750 (F1 interface) reference ECN for managing congestion on critical interfaces. The use of ECT improves the performance of transport protocols over wireless links, where packet loss can be due to radio errors rather than congestion. By distinguishing between congestion signals (ECN marks) and loss signals, TCP can respond more appropriately, avoiding unnecessary rate reductions. This leads to higher link utilization, lower latency, and a better quality of experience for applications, especially in congested core network or backhaul links.
Purpose & Motivation
ECT was developed to address the limitations of traditional loss-based congestion control, where TCP interprets packet loss as a sign of network congestion and drastically reduces its sending rate. In modern networks, especially with large buffers (bufferbloat), this reaction can cause high latency and underutilization. ECN provides an early, explicit signal of congestion before buffers overflow and packets are dropped, allowing endpoints to throttle back smoothly.
The motivation for incorporating ECT into 3GPP systems stems from the need for efficient transport in mobile networks. 3GPP interfaces, such as the N3/N9 interfaces in 5G or the S1-U interface in LTE, carry massive amounts of user plane data. Congestion on these links can degrade service quality. Using ECT-capable transport allows the network to manage congestion more intelligently, reducing packet loss and retransmission delays. This is particularly important for real-time and latency-sensitive services enabled by 5G. ECT represents a shift from a purely loss-based to a signal-based congestion control paradigm, aligning with broader Internet engineering efforts to improve network responsiveness and fairness.
Key Features
- Enables IP routers to mark packets with a Congestion Experienced (CE) codepoint
- Requires negotiation between endpoints at transport layer setup (e.g., TCP SYN)
- Allows senders to react to congestion before packet loss occurs
- Reduces packet loss and retransmissions, lowering latency
- Improves throughput and fairness in shared bottleneck links
- Integrated into 3GPP specifications for GTP-based and other internal interfaces
Evolution Across Releases
Initial adoption and references to ECN/ECT within 3GPP specifications, primarily for background study and inclusion in general transport requirements for IP-based services in the core network.
Defining Specifications
| Specification | Title |
|---|---|
| TS 21.905 | 3GPP TS 21.905 |
| TS 22.173 | 3GPP TS 22.173 |
| TS 22.273 | 3GPP TS 22.273 |
| TS 22.401 | 3GPP TS 22.401 |
| TS 23.806 | 3GPP TS 23.806 |
| TS 24.173 | 3GPP TS 24.173 |
| TS 24.186 | 3GPP TS 24.186 |
| TS 24.196 | 3GPP TS 24.196 |
| TS 24.292 | 3GPP TS 24.292 |
| TS 24.315 | 3GPP TS 24.315 |
| TS 24.404 | 3GPP TS 24.404 |
| TS 24.405 | 3GPP TS 24.405 |
| TS 24.406 | 3GPP TS 24.406 |
| TS 24.410 | 3GPP TS 24.410 |
| TS 24.411 | 3GPP TS 24.411 |
| TS 24.416 | 3GPP TS 24.416 |
| TS 24.429 | 3GPP TS 24.429 |
| TS 24.447 | 3GPP TS 24.447 |
| TS 24.454 | 3GPP TS 24.454 |
| TS 24.504 | 3GPP TS 24.504 |
| TS 24.505 | 3GPP TS 24.505 |
| TS 24.516 | 3GPP TS 24.516 |
| TS 24.529 | 3GPP TS 24.529 |
| TS 24.604 | 3GPP TS 24.604 |
| TS 24.605 | 3GPP TS 24.605 |
| TS 24.606 | 3GPP TS 24.606 |
| TS 24.610 | 3GPP TS 24.610 |
| TS 24.611 | 3GPP TS 24.611 |
| TS 24.616 | 3GPP TS 24.616 |
| TS 24.629 | 3GPP TS 24.629 |
| TS 24.642 | 3GPP TS 24.642 |
| TS 24.647 | 3GPP TS 24.647 |
| TS 24.654 | 3GPP TS 24.654 |
| TS 26.114 | 3GPP TS 26.114 |
| TS 26.804 | 3GPP TS 26.804 |
| TS 29.165 | 3GPP TS 29.165 |
| TS 29.292 | 3GPP TS 29.292 |
| TS 29.364 | 3GPP TS 29.364 |
| TS 29.864 | 3GPP TS 29.864 |
| TS 32.275 | 3GPP TR 32.275 |
| TS 32.850 | 3GPP TR 32.850 |
| TS 33.107 | 3GPP TR 33.107 |
| TS 36.750 | 3GPP TR 36.750 |