ECT

Explicit Congestion Notification-Capable Transport

Protocol →
Introduced in Rel-5

ECT is a transport layer capability, primarily for TCP, that allows network nodes to signal impending congestion to endpoints before packet loss occurs.

Category
Protocol
Introduced
Rel-5
Where
Services › Codecs
Specifications
43 specs
ECT Description Purpose Related Detected Changes Specifications

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.

Detected Changes Across Releases

from 3GPP Change Requests

Specific changes extracted from the „Change history“ tables of 3GPP specifications (5 CRs across 4 releases). Complements the general historical overview above with the evidence-based evolution of this function.

Studied in Rel-5, normative work from Rel-15.

Rel-15 2 changes

In Release 15, the ECT function was updated to clarify its interaction with the "Enhanced calling name" service. Furthermore, the specification introduced details regarding the notification procedure for timer T3325 as documented in Annex M. These changes provided specific operational clarifications for the Explicit Congestion Notification-Capable Transport mechanism within the 3GPP framework.

  • Interaction between ECT and "Enhanced calling name" service TS 24.629CR0038
  • T3325 notification in Annex M TS 24.173CR0129
Rel-17 1 change

In Release 17, the enhancement for Explicit Congestion Notification-Capable Transport (ECT) introduced specific handling for lower layer congestion notification for MMTEL video services. This update defined procedures to manage transport block sets and transport channels when explicit congestion notifications are received. The change aimed to improve the quality of multimedia telephony services by allowing more responsive transport layer adaptation to network congestion conditions.

  • Handling of lower layer congestion notification for MMTEL video TS 24.173CR0145
Rel-18 1 change

In Release 18, the key enhancement for the Explicit Congestion Notification-Capable Transport (ECT) function was the introduction of support for MPS (Multimedia Priority Service) priority within the ECT supplementary service. This allows the transport function to handle priority traffic explicitly in relation to congestion notification mechanisms. The change is specified through the supplementary service procedures.

  • MPS priority for ECT supplementary service TS 24.629CR0040
Rel-19 1 change

In Release 19, the ECT function was updated with corrections for scenarios involving the Access Stratum (AS) serving the transferee and for blind call flows. These enhancements specifically addressed the handling of transport bearers and the associated signalling procedures to ensure proper network operation during call transfers.

  • ECT corrections: AS serving the transferee and blind call flow TS 24.186CR0067

Explore further

Broader topics and technologies where ECT plays a role.

Defining Specifications

3GPP specifications that define or reference ECT, with the latest known release. Sourced from the 3GPP document catalog — see methodology.

SpecificationTitleRelease
TR 21.905 vj00 3GPP Technical Terms and Definitions Rel-19
TS 22.173 vk00 IMS Multimedia Telephony Service Definition Rel-20
TS 22.273 v1700 IMS Multimedia Telephony with PSTN/ISDN Simulation Rel-7
TS 22.401 v1800 Videotelephony Service Requirements for NGN Rel-8
TS 23.806 v1700 Voice Call Continuity between CS and IMS Rel-7
TS 24.173 vj00 Multimedia Telephony Service and Supplementary Services in IMS Rel-19
TS 24.186 vj60 IMS Data Channel applications Rel-19
TS 24.196 vj00 Enhanced Calling Name (eCNAM) Stage 3 Protocol Rel-19
TS 24.292 vj00 IMS Centralized Services (ICS) Protocol Rel-19
TS 24.315 vj00 Operator Determined Barring (ODB) for IMS Rel-19
TS 24.404 v1700 Communication Diversion Services (CDIV) Rel-7
TS 24.405 v1700 Conference Service Protocol Description Rel-7
TS 24.406 v810 Message Waiting Indication (MWI) Protocol Rel-8
TS 24.410 v810 Protocol Description of HOLD Services Rel-8
TS 24.411 v1830 ACR and CB Service Protocol Specification Rel-8
TS 24.416 v1700 Malicious Call Identification Service Rel-7
TS 24.429 v1700 Explicit Communication Transfer (ECT) Service Specification Rel-7
TS 24.447 v800 Advice Of Charge (AOC) Service Protocol Rel-8
TS 24.454 v840 Closed User Group (CUG) Protocol Specification Rel-8
TS 24.504 v8m0 Communication Diversion Services Stage 3 Rel-8
TS 24.505 v810 Protocol Description of the Conference Service Rel-8
TS 24.516 v830 MCID Protocol Specification for NGN Rel-8
TS 24.529 v820 Explicit Communication Transfer (ECT) Simulation Service Rel-8
TS 24.604 vj00 Communications Diversion (CDIV) Protocol Spec Rel-19
TS 24.605 vj00 3GPP CONF Service Protocol Specification Rel-19
TS 24.606 vj00 MWI Service Protocol Description Rel-19
TS 24.610 vj00 Communication Hold (HOLD) Service Protocol Rel-19
TS 24.611 vj00 Anonymous Communication Rejection & Barring Rel-19
TS 24.616 vj00 Malicious Call Identification (MCID) Protocol Rel-19
TS 24.629 vj00 Explicit Communication Transfer (ECT) Protocol Rel-19
TS 24.642 vj00 CCBS/CCNR/CCNL SIP Protocol Specification Rel-19
TS 24.647 vj00 Advice of Charge (AOC) service protocol Rel-19
TS 24.654 vj00 Closed User Group (CUG) supplementary service Rel-19
TS 26.114 vj10 IMS Multimedia Telephony Media Handling Rel-19
TS 26.804 vj10 5G Media Streaming Extensions Study Rel-19
TS 29.165 vj10 Inter-IMS Network to Network Interface (NNI) Rel-19
TS 29.292 vj00 IMS Centralized Services (ICS) Interworking Rel-19
TS 29.364 vj10 IMS AS Service Data Descriptions Rel-19
TS 29.864 v801 Application Server Service Data Definition for IMS Telephony Rel-8
TS 32.275 vj00 MMTel Charging Specification Rel-19
TS 32.850 ve00 IMS Charging Correlation Methods Study Rel-14
TS 33.107 vj00 Lawful Interception Architecture & Functions Rel-19
TS 36.750 ve10 Study on enhancement of VoLTE Rel-14