Description
The Background Data Transfer Answer (BTA) is a critical Diameter command within the 3GPP Policy and Charging Control (PCC) architecture, specifically defined for the Sd reference point (interface) between the Policy and Charging Rules Function (PCRF) and the Traffic Detection Function (TDF). As a Diameter answer message, it operates within a request-answer transaction initiated by the PCRF sending a Background Data Transfer Request (BTR). The BTA carries the result of the request, indicating whether the TDF has successfully accepted and will apply the requested policies for detecting and controlling background data transfers, or if an error has occurred.
Technically, the BTA command (Command-Code 8388722) is defined in 3GPP TS 29.154. It is an application-specific command that extends the base Diameter protocol (RFC 6733) for 3GPP's service data flow detection and control purposes. The message structure includes a standard Diameter header with the Command Flags set appropriately for an answer message, followed by a sequence of Attribute-Value Pairs (AVPs). These AVPs convey the session context, the result of the request (e.g., success or specific error codes), and any relevant experimental or vendor-specific AVPs defined by 3GPP. The Session-Id AVP is mandatory and must match the one in the corresponding BTR to correlate the request and answer within the same Diameter session.
The primary role of the BTA in the network is to provide a standardized, reliable confirmation mechanism within the PCC framework. When the PCRF provisions application detection and control rules to the TDF—such as instructions to detect specific background data transfer applications (e.g., software updates, cloud sync) and to apply specific QoS or charging actions—the TDF uses the BTA to signal its compliance or report any issues. A successful BTA (with Result-Code AVP indicating DIAMETER_SUCCESS) confirms the TDF's commitment to enforce the policies. An erroneous BTA, containing an appropriate error Result-Code (e.g., DIAMETER_UNABLE_TO_COMPLY, DIAMETER_UNKNOWN_SESSION_ID), informs the PCRF of a failure, allowing the PCRF to take corrective action, such as attempting re-provisioning or triggering alternative policy enforcement logic.
This answer message is integral to maintaining state and synchronization between the PCRF and TDF. It ensures that the policy decision point (PCRF) has a confirmed view of the policy enforcement status at the detection point (TDF). This confirmation loop is essential for reliable service delivery, accurate charging for background data services, and enabling advanced network capabilities like sponsored data connectivity or optimized traffic management for background applications without impacting user experience for foreground traffic.
Purpose & Motivation
The BTA command was created to fulfill a specific signaling need within the evolved 3GPP PCC architecture, particularly with the introduction of the Traffic Detection Function (TDF) as a standalone entity or as a functional enhancement to the PCEF. Prior to Rel-13 and the formal definition of the Sd interface, application detection and control for non-GBR bearers, especially for background data, was less standardized and often handled in a proprietary manner within the PCEF/Gateway or via deep packet inspection (DPI) boxes with non-standard interfaces. This lack of standardization made it difficult for operators to consistently implement and monetize policies for background data traffic, such as differentiating between user-initiated traffic and automated background transfers from applications.
The introduction of the standardized Sd interface, with its BTR/BTA command pair, solved this by providing an open, interoperable protocol for the PCRF to dynamically delegate application detection and reporting tasks to a specialized TDF. The BTA, as the answer part of this transaction, serves the fundamental purpose of completing the Diameter signaling exchange, providing reliability. It ensures the PCRF receives explicit acknowledgment that its policy provisioning instructions have been received and accepted (or rejected) by the TDF. This acknowledgment is crucial for maintaining a consistent policy state across network functions and for triggering appropriate charging events.
Furthermore, the BTA enables sophisticated service models. For example, an operator can implement "sponsored data" for specific background application updates, where the data usage is not charged to the end user. The PCRF would provision a corresponding policy to the TDF via a BTR. The TDF's BTA confirms the policy is in place, allowing the PCRF to then instruct the PCEF/PGW on the appropriate charging rules (Gy interface). Without the confirmed handshake provided by the BTR/BTA exchange, such coordinated policy enforcement across multiple network elements would be unreliable and prone to errors, leading to charging discrepancies and poor service quality.
Key Features
- Diameter-based answer command (Command-Code 8388722) for the Sd interface
- Provides acknowledgment and result for Background Data Transfer Request (BTR) commands
- Carries standard Diameter Result-Code AVP to indicate success or specific failure
- Uses Session-Id AVP to correlate with the originating BTR within a session
- Enables reliable state synchronization between PCRF and Traffic Detection Function (TDF)
- Fundamental for confirming application detection and control rule provisioning
Evolution Across Releases
Introduced as part of the initial standardization of the Sd interface in TS 29.154. Defined the BTA command's format, mandatory/optional AVPs, and its role within the PCC architecture for acknowledging background data transfer policies provisioned from the PCRF to the TDF. Established the foundational protocol for dynamic application detection and control signaling.
Defining Specifications
| Specification | Title |
|---|---|
| TS 29.154 | 3GPP TS 29.154 |