Rate Control Procedure Acknowledgement

Description

The Rate Control Procedure Acknowledgement (RC) is a specific control message within the Radio Access Network Application Part (RANAP) protocol, which operates over the Iu interface connecting the Radio Network Controller (RNC) and the Core Network (CN) in a 3GPP UMTS network. The Iu interface is split into Iu-CS (Circuit Switched) for voice and Iu-PS (Packet Switched) for data; RC messages are relevant to both domains for managing bearer rates. The RC acknowledgement is sent in response to a RANAP 'Rate Control' message, which is initiated by the CN to request a change in the maximum allowed bit rate for an existing Radio Access Bearer (RAB). This forms part of the RAB modification procedure.

Operationally, when the CN decides to modify the bit rate of an active user session (e.g., due to changing service requirements, network congestion, or subscriber policy), it sends a RANAP Rate Control message to the serving RNC. This message contains the new requested maximum bit rate for uplink and/or downlink. Upon receiving this, the RNC performs admission control and radio resource calculations to determine if the new rate can be supported. If the RNC accepts the request, it will reconfigure the radio bearer with the UE and then send back an RC acknowledgement message to the CN, confirming the successful application of the new rate. If the request cannot be accommodated, the RNC would respond with a Rate Control Failure message instead. The RC acknowledgement itself is a simple confirmation but triggers subsequent actions in both entities to enforce the new data rate limits.

The RC procedure is crucial for dynamic quality of service (QoS) management in UMTS. It allows the network to adapt to changing conditions in real-time, optimizing resource utilization and user experience. The procedure relies on the reliable transport provided by the Signalling Connection Control Part (SCCP) and Message Transfer Part (MTP) layers beneath RANAP. While the term 'RC' specifically denotes the acknowledgement message, the overall 'Rate Control Procedure' encompasses the request, the RNC's internal processing, the radio reconfiguration with the UE, and the final acknowledgement or failure notification, ensuring synchronized QoS states between the RAN and CN.

Purpose & Motivation

The Rate Control Procedure and its Acknowledgement (RC) were created to enable dynamic, in-session adjustment of data rates for user connections in UMTS networks. Prior cellular systems like GSM/GPRS had more static bearer management, where data rates were largely set at connection establishment. UMTS introduced richer multimedia services with variable bandwidth demands, necessitating a mechanism for the core network to request rate changes from the RAN during an active session. This solved the problem of inefficient fixed resource allocation, allowing network resources to be matched to actual service needs and congestion levels.

The introduction of the RC procedure in Release 5 was closely tied to the development of the Iu interface and the RANAP protocol, which separated RAN and CN functionalities. It addressed the need for coordinated QoS management between the service-aware core network (which knows subscriber profiles and service requirements) and the radio-resource-aware RNC (which knows cell load and radio conditions). The RC acknowledgement provides the necessary confirmation to ensure both sides maintain a consistent view of the active bearer's capabilities, preventing service interruptions or billing discrepancies. This dynamic control was particularly important for early 3G data services and video telephony, enabling smooth adaptation between different quality levels.

Key Features

• RANAP control message on the Iu interface (CS & PS)
• Sent by RNC to Core Network to acknowledge a Rate Control command
• Part of the Radio Access Bearer (RAB) modification procedure
• Ensures reliable negotiation of maximum bit rate for a user session
• Triggers after successful radio bearer reconfiguration with UE
• Uses reliable signalling transport via SCCP/MTP

Evolution Across Releases

Defining Specifications