Sd AVPs
Sd (application id: 16777303)
The Sd interface is a component of the Policy and Charging Control (PCC) architecture in mobile networks. This interface is established between the Policy and Charging Rules Function (PCRF) and the Traffic Detection Function (TDF). It plays a crucial role in the detection, reporting, and control of application-specific traffic within the network. The Sd interface leverages the Diameter protocol for communication, facilitating real-time exchange of Application Detection and Control (ADC) rules and associated information between the PCRF and the TDF.
The primary purpose of the Sd interface is to enable the PCRF to control and manage the behavior of application traffic as detected by the TDF. The PCRF provides ADC rules to the TDF, which in turn monitors network traffic to detect applications that match these rules. Once an application is detected, the TDF reports this event to the PCRF, which then enforces the relevant policies, such as Quality of Service (QoS) adjustments or charging mechanisms.
Architecture
- PCRF (Policy and Charging Rules Function): The PCRF is responsible for making policy decisions in real-time and enforcing these policies across the network. It determines how resources are allocated and manages charging based on the detected application traffic reported by the TDF.
- TDF (Traffic Detection Function): The TDF monitors network traffic to detect specific applications based on the ADC rules provided by the PCRF. It is responsible for reporting these detections back to the PCRF, enabling the network to apply the necessary controls and policies.
- Sd Reference Model: The Sd interface connects the PCRF and the TDF, forming a logical link that enables the exchange of ADC rules and application traffic information. This interface is depicted in the PCC architecture diagrams provided by 3GPP, illustrating how it fits within the broader network ecosystem.
Sd interface workflow:
Provisioning of ADC Rules:
- The PCRF provides ADC rules to the TDF over the Sd interface. These rules define which applications the TDF should monitor and the specific conditions under which the traffic should be reported. ADC rules can be either dynamic, responding to real-time network conditions, or predefined, set up in advance based on expected traffic patterns.
Application Traffic Detection:
- As the TDF monitors network traffic, it uses the ADC rules to identify specific application flows. When an application that matches one of these rules is detected, the TDF prepares a report containing details such as the application identifier, the associated IP addresses, and any relevant event triggers (e.g., application start or stop).
Reporting to PCRF:
- The TDF sends this report to the PCRF via the Sd interface. The report includes critical information that the PCRF requires to enforce the appropriate policies. This could involve adjusting QoS parameters, modifying charging rules, or implementing other control measures depending on the nature of the detected traffic.
Policy Enforcement:
- Upon receiving the application detection report, the PCRF evaluates the information and enforces the relevant policies. For example, if the detected application requires high bandwidth, the PCRF might increase the QoS for that traffic. Alternatively, if the application is identified as chargeable, the PCRF might update the charging mechanisms accordingly.
Solicited vs. Unsolicited Reporting:
- The Sd interface supports both solicited and unsolicited reporting. In solicited reporting, the PCRF explicitly requests the TDF to monitor certain applications and report on them. In unsolicited reporting, the TDF autonomously monitors traffic and reports to the PCRF based on pre-configured ADC rules without needing explicit requests.
For complete technical specification of Sd interface in Diameter protocol please refer to: [3GPP TS 29.212]
package com.mobius.software.telco.protocols.diameter.primitives.sd;
|
Name |
AVP Code |
Data Type |
Vendor |
|
ADC-Rule-Base-Name |
1095 |
UTF8String |
3GPP |
|
Used to indicate the name of a predefined group of ADC (Application Detection and Control) rules. These rules are part of the Policy and Charging Control (PCC) framework and are used to detect and control application traffic based on predefined criteria. As defined in [TS 29.212]. |
|||
|
ADC-Rule-Definition |
1094 |
Grouped |
3GPP |
|
Defines an Application Detection and Control (ADC) rule sent by the Policy and Charging Rules Function (PCRF) to the Traffic Detection Function (TDF). This AVP plays a critical role in identifying and managing traffic that belongs to a particular application or service within a TDF session. The ADC-Rule-Name AVP uniquely identifies each ADC rule, allowing it to be referenced in PCRF-TDF communication over the Sd interface. The rule definition determines traffic flows, policy enforcement criteria, QoS parameters, monitoring policies, and traffic steering directives. If an ADC-Rule-Definition AVP is updated in a subsequent Diameter message, any previously provided information remains valid unless explicitly changed. The AVP structure is defined as follows: ADC-Rule-Name (Mandatory): Uniquely identifies the ADC rule within the TDF session. TDF-Application-Identifier (Optional): Specifies the Application Identifier associated with the traffic detection. Flow-Information (Optional, Multiple): Defines specific IP flows that belong to the detected application or service. Service-Identifier (Optional): Identifies the service to which the detected traffic belongs. Rating-Group (Optional): Specifies the charging category for the detected traffic. Reporting-Level (Optional): Defines the level of traffic reporting, which can be:
(If set to SPONSORED_CONNECTIVITY_LEVEL, the Sponsor-Identity and Application-Service-Provider-Identity AVPs MUST be included.) Online / Offline Charging Indicators (Optional): Specifies if online/offline charging applies. Metering-Method (Optional): Defines the traffic metering approach (e.g., volume-based, duration-based). Precedence (Optional): Determines the priority order of the ADC rule relative to others. Flow-Status (Optional): Indicates the operational state of the detected flow. QoS-Information (Optional): Defines the QoS profile applicable to the ADC rule. Monitoring-Key (Optional): Contains a monitoring key that may apply to the rule. Sponsor-Identity & Application-Service-Provider-Identity (Optional, Mandatory if Reporting-Level = SPONSORED_CONNECTIVITY_LEVEL): Identifies the sponsor entity and application service provider. Redirect-Information (Optional, Max 2 Instances): Contains redirect instructions if traffic needs redirection. Mute-Notification (Optional): Determines whether notification silence is applied to the ADC rule. Cannot be changed during the rule's lifetime. Traffic-Steering-Policy-Identifiers (UL/DL) (Optional): Uplink/Downlink steering policy. (If both exist and the steering policies are identical, they must have the same value.) ToS-Traffic-Class (Optional): Defines Type of Service (ToS) / Traffic Class settings. Allows the inclusion of custom AVPs |
|||
|
ADC-Rule-Install |
1092 |
Grouped |
3GPP |
|
Used to activate, install, or modify ADC (Application Detection and Control) rules as instructed by the Policy and Charging Rules Function (PCRF). When installing a new ADC rule or modifying an existing rule, the ADC-Rule-Definition AVP must be included. When activating a predefined ADC rule, the ADC-Rule-Name AVP is used to reference that rule. The ADC-Rule-Base-Name AVP may be used to activate a predefined group of ADC rules. If Rule-Activation-Time or Rule-Deactivation-Time is specified, the timing applies to all ADC rules within the ADC-Rule-Install AVP. If the Monitoring-Flags AVP is included, it applies to all ADC rules within this AVP and remains valid until a new value is provided. The AVP structure is defined as follows: ADC-Rule-Definition (Optional, Multiple): Defines a new ADC rule or modifies an existing one. ADC-Rule-Name (Optional, Multiple): References an existing predefined ADC rule for activation. ADC-Rule-Base-Name (Optional, Multiple): References a predefined group of ADC rules for activation. Monitoring-Flags (Optional): Indicates the monitoring action related to the application. Applies to all ADC rules within this AVP unless updated. Rule-Activation-Time (Optional): Specifies the time at which the rule(s) should be activated. Applies to all ADC rules within this AVP. Rule-Deactivation-Time (Optional): Specifies the time at which the rule(s) should be deactivated. Applies to all ADC rules within this AVP. |
|||
|
ADC-Rule-Name |
1096 |
OctetString |
3GPP |
|
Uniquely identifies an ADC (Application Detection and Control) rule. It serves as a reference identifier for both dynamically provided and predefined ADC rules in the Traffic Detection Function (TDF). For ADC rules provided by the PCRF, this AVP uniquely identifies an ADC rule within a single TDF session. For predefined ADC rules, this AVP uniquely identifies an ADC rule within the entire TDF system. This AVP is typically used within ADC-Rule-Definition AVP (1094) or ADC-Rule-Install AVP (1092) to reference a specific rule. |
|||
|
ADC-Rule-Remove |
1093 |
Grouped |
3GPP |
|
Used to deactivate or remove ADC (Application Detection and Control) rules as instructed by the Policy and Charging Rules Function (PCRF). This AVP enables the PCRF to remove specific dynamic ADC rules or deactivate predefined ADC rules within the Traffic Detection Function (TDF). To remove a specific dynamic ADC rule or deactivate a predefined ADC rule, the ADC-Rule-Name AVP is used. To deactivate a group of predefined ADC rules, the ADC-Rule-Base-Name AVP is used. The AVP structure is defined as follows: ADC-Rule-Name (Optional, Multiple): Identifies a specific ADC rule to be removed or deactivated. ADC-Rule-Base-Name (Optional, Multiple): Identifies a group of predefined ADC rules to be deactivated. |
|||
|
ADC-Rule-Report |
1097 |
Grouped |
3GPP |
|
Used to report the status of ADC (Application Detection and Control) rules. It provides feedback to the Policy and Charging Rules Function (PCRF) regarding ADC rules that could not be installed, activated, or enforced at the Traffic Detection Function (TDF). This AVP is primarily used to indicate:
If an ADC rule cannot be enforced, the PCC-Rule-Status AVP is set to INACTIVE, and the Rule-Failure-Code AVP provides the reason for the failure. The AVP structure is defined as follows: ADC-Rule-Name (Optional, Multiple): Identifies a specific ADC rule that could not be installed, activated, or enforced. ADC-Rule-Base-Name (Optional, Multiple): Identifies a group of ADC rules that could not be activated. PCC-Rule-Status (Optional): Specifies the status of the ADC rule(s). Typically set to INACTIVE when a rule fails. Rule-Failure-Code (Optional): Indicates the reason why the ADC rule(s) could not be installed, activated, or enforced. Final-Unit-Indication (Optional): Used when credit is no longer available or has been reallocated. Specifies the termination action applied to the ADC rules, as instructed by the OCS. |
|||
Start innovating with Mobius
What's next? Let's talk!