Backward Explicit Congestion Notification

Description

Backward Explicit Congestion Notification (BECN) is a congestion control mechanism specified in 3GPP TS 48.016 for the Gb interface, which connects the Base Station System (BSS) with the Serving GPRS Support Node (SGSN) in 2G and 3G mobile networks. The Gb interface carries both signaling and user data traffic for GPRS and EDGE services, and BECN operates specifically within the Frame Relay-based transport layer of this interface. When congestion occurs in the downlink direction (from SGSN to BSS), BECN provides a standardized method for the BSS to notify the SGSN about the congestion condition, enabling coordinated traffic management between network elements.

The BECN mechanism works through the Frame Relay protocol's congestion notification bits within the Frame Relay header. When the BSS detects congestion in its buffers or transmission queues for downlink traffic, it sets the Backward Explicit Congestion Notification bit in the Frame Relay header of frames traveling in the opposite direction (from BSS to SGSN). This backward notification approach is essential because congestion typically occurs at the receiving end (BSS), but the traffic control needs to be implemented at the sending end (SGSN). The BECN bit is carried in the Data Link Connection Identifier (DLCI) field of the Frame Relay header, specifically in the Address Field where congestion control bits are defined according to Frame Relay standards.

Upon receiving frames with the BECN bit set, the SGSN interprets this as an indication of congestion in the downlink path to the BSS. The SGSN can then implement various congestion response mechanisms, typically involving rate reduction or traffic shaping for the affected connections. The specific response algorithms are implementation-dependent but generally follow principles of gradual rate reduction to alleviate congestion without causing abrupt service disruption. The SGSN may reduce the transmission rate for specific Packet Data Protocol (PDP) contexts or apply more generalized traffic throttling for all traffic destined to the congested BSS.

BECN operates in conjunction with Forward Explicit Congestion Notification (FECN), which provides congestion notification in the forward direction. While FECN notifies the receiving end (BSS) about congestion in the uplink direction, BECN specifically addresses the more critical downlink congestion scenario where the SGSN controls the traffic flow. The combination of BECN and FECN creates a bidirectional congestion management system for the Gb interface. BECN's effectiveness depends on proper implementation of response mechanisms in the SGSN and appropriate congestion detection algorithms in the BSS, making it a cooperative congestion control scheme rather than a mandatory traffic regulation mechanism.

The architecture supporting BECN involves multiple protocol layers: at the physical layer, the Gb interface typically uses E1/T1 lines; at the data link layer, Frame Relay provides the congestion notification capabilities; and at the network layer, BSSGP (BSS GPRS Protocol) manages the actual GPRS traffic. BECN functions at the Frame Relay layer, making it transparent to higher-layer protocols but essential for maintaining transport efficiency. Key components include the Frame Relay switches in the transmission network, the BSS's congestion detection mechanisms, and the SGSN's traffic management functions. BECN plays a critical role in preventing buffer overflow in the BSS, reducing packet loss, and maintaining quality of service for mobile data users.

Purpose & Motivation

BECN was created to address the fundamental challenge of congestion management in packet-switched mobile networks, specifically for the Gb interface in 2G and 3G systems. Before standardized congestion notification mechanisms, network elements operated with limited visibility into congestion conditions at adjacent nodes, leading to inefficient traffic handling, increased packet loss, and degraded user experience. The Gb interface's Frame Relay transport presented particular challenges because it lacked inherent congestion control mechanisms, requiring explicit notification schemes to coordinate traffic management between SGSN and BSS.

The primary problem BECN solves is the asymmetric nature of congestion detection and control in mobile networks. Congestion typically occurs at the receiving node (BSS) when downlink traffic exceeds its processing or forwarding capacity, but traffic control must be implemented at the sending node (SGSN). Without BECN, the SGSN would have no direct indication of congestion at the BSS, potentially continuing to transmit data that would be dropped, wasting network resources and degrading service quality. BECN provides the essential feedback mechanism that enables closed-loop congestion control.

Historical context reveals that early GPRS implementations suffered from inefficient congestion handling, leading to suboptimal resource utilization and poor user experience during peak traffic periods. The Frame Relay technology used for Gb interface transport included congestion notification capabilities in its specification, but 3GPP needed to define how these capabilities would be utilized in the mobile network context. BECN, along with FECN, represented the standardization of best practices for congestion management, ensuring interoperability between equipment from different vendors and consistent network performance. The mechanism addressed limitations of previous approaches that relied solely on buffer management or simple packet dropping, providing a more sophisticated, network-aware congestion control system.

Key Features

• Frame Relay-based congestion notification using dedicated bits in the header
• Backward notification direction (from BSS to SGSN) for downlink congestion management
• Integration with SGSN traffic shaping and rate control mechanisms
• Cooperative operation with Forward Explicit Congestion Notification (FECN)
• Transparent to higher-layer protocols like BSSGP and IP
• Implementation-dependent response algorithms allowing vendor optimization

Evolution Across Releases

Defining Specifications