- Introduction
- General Considerations
- Scope, References and Abbreviations
- Sy Reference Point
- Sy Protocol
- Annex A (Normative): User Identity for Fixed Broadband Access Network Convergence
- Annex B (Informative): Change History
- Reference List
1 Introduction
This document describes to what extent SAPC implementation of Policy and Charging Rule Function (PCRF) role conforms with the 3GPP Technical Specification (TS) 29.219 V13.4.0 (2016-12) standard 3GPP Technical Specification Group Core Network and Terminals; Policy and Charging Control: Spending Limit Reporting over Sy Reference Point with the exemptions or additions stated in this document.
2 General Considerations
This document is structured following the chapters of the 3GPP Technical Specification 29.219 V13.4.0 (2016-12) .
The following terms explain the columns in the fill-in tables in the document:
| Qualifier |
Defines whether the implementation of a certain entity is mandatory (M), optional (Op) or conditional (C). |
|
| Compliance |
Defines whether the implementation of a certain entity is Compliant by the system. |
|
| Comment |
It may contain additional information. |
|
| No requirement (NR) |
The TS statement contains general information for the understanding of other statements not applicable to SAPC (the statements may be applicable for other nodes). |
|
One of the following statements (with the associated interpretation) is given to each of the requirements of the Technical Specification:
| Not compliant (NC) |
The TS statement is not fulfilled. |
|
| Compliant (C) |
All of the TS statements are fulfilled |
|
| Partially compliant (PC) |
Not completely all of the TS statements are fulfilled, the exceptions are described. |
|
One of the following statements (with the associated interpretation) is given to each of the AVPs of the Technical Specification:
| Not compliant (NC) |
The AVP is not supported. |
|
| Compliant (C) |
The AVP is supported and handled by SAPC |
|
| Partially compliant (PC) |
The AVP is supported but not handled (or not fully handled) by SAPC. |
|
In this context, 'is/shall/will' statements are considered as mandatory, 'may and should' statements are considered as optional, and 'can' statements are considered as conditional.
Some sentences (rows in the tables of this document) stating requirements are not completely independent, as they explain a behavior that shall be understood in the context of the corresponding chapter where they appear.
3 Scope, References and Abbreviations
3.1 Scope
No requirement
3.2 References
No requirement
3.3 Definitions and Abbreviations
No requirement
4 Sy Reference Point
4.1 Overview
No requirement
4.2 Sy Reference Model
No requirement
4.3 Subscriber Spending Limits
|
Text |
Qualifier |
Compliance |
Comment |
|---|---|---|---|
|
Policy decisions based on spending limits is a function that allows the PCRF to make policy decisions based on the status of policy counters that are maintained in the OCS. The PCRF uses the policy counter statuses received from the OCS as input to its policy decisions, e.g. downgrade the QoS (e.g. APN-AMBR) or modify the PCC/QoS/ADC Rules. |
M |
PC |
The SAPC does not support the use of ADC/QoS rules. |
|
When the status of policy counters is first required to make a policy decision for a subscriber, the PCRF uses the Initial Spending Limit Report Request procedure. |
M |
C |
The SAPC sends the Initial Spending Limit Report Request at IP-CAN session establishment. |
|
Optionally, the OCS can provide one or more pending statuses for a requested policy counter with the times that have to be applied. The pending status of a policy counter shall autonomously become the current status of a policy counter at the PCRF when the indicated corresponding time is reached. Subsequently, the provided information for pending statuses of a policy counter shall overwrite the previously received information. |
Op |
NC |
|
|
The PCRF may request specific or all policy counter statuses to be reported by the OCS for the user. |
Op |
PC |
The SAPC does not specify the policy counter to be reported in the request. Instead, the SAPC always requests all the policy counter statuses available in the OCS for the specified user. |
|
The PCRF may request reporting for specific policy counter(s) that it is not currently subscribed and/or cancel reporting for specific policy counter status(es) using the Intermediate Spending Limit Report Request. |
Op |
NC |
The SAPC does not specify the policy counter to be reported and it does not support the Intermediate Spending Limit Report Request procedure. |
|
The PCRF may cancel spending limit reporting for all policy counter(s) using the Final Spending Limit Report Request. |
Op |
C |
The SAPC only initiates Final Spending Limit Report Request procedures when all the Gx sessions are ended for the specified user. |
|
The updated subscriber profile may also trigger the PCRF sending the Initial/Intermediate/Final Spending Limit Report Request to the OCS to subscribed and/or cancel reporting for policy counter status(es). |
Op |
PC |
If there is no ongoing Sy session active for that specific subscriber, procedures for Initial Spending Limit Report Request are activated when the subscriber is associated with an OCS profile in the SAPC. Intermediate Spending Limit Report Request procedures are not supported by the SAPC. |
4.4 Functional Elements
4.4.1 PCRF
|
Text |
Qualifier |
Compliance |
Comment |
|---|---|---|---|
|
The PCRF may take information on the subscriber's spending status into account in its policy decisions. |
Op |
C |
|
|
The PCRF may request spending limit reporting for policy counters from the OCS using the Initial or Intermediate Spending Limit Report Request procedure as specified in clause 4.5.1. |
Op |
PC |
The SAPC does not support the Intermediate Spending Limit Report Request procedure. |
|
The PCRF may cancel spending limit reporting for specific policy counter(s) using the Intermediate Spending Limit Report Request procedure, or for all policy counter(s) using the Final Spending Limit Report Request procedure as specified in clause 4.5.3. |
Op |
PC |
The SAPC does not support the Intermediate Spending Limit Report Request procedure and does not specify the policy counter to be canceled. The SAPC only initiates Final Spending Limit Report Request procedures when all the Gx sessions are ended for the specified user. |
|
The PCRF shall have at least one active IP-CAN session to be able to initiate an Sy session to be used when required for spending limit reporting for that subscriber. |
M |
C |
|
|
The PCRF shall terminate the Sy session when the last IP-CAN session for that subscriber is terminated or no IP-CAN session for the same user depends on the spending status information provided over Sy reference point. |
M |
PC |
The SAPC only initiates Final Spending Limit Report Request procedures when all the Gx sessions are ended for the specified user. |
|
The PCRF may use the status of each relevant policy counter as input to its policy decision as required by the decision logic. |
Op |
C |
4.4.2 OCS
No requirement
4.5 Spending Limits Procedures over Sy Reference Point
4.5.1 Initial/Intermediate Spending Limit Report Request
4.5.1.1 General
|
Text |
Qualifier |
Compliance |
Comment |
|---|---|---|---|
|
This procedure shall be used by the PCRF to request the status of policy counters available at the OCS, and to subscribe or unsubscribe to updates of policy counters by the OCS. |
M |
PC |
The SAPC does not support the Intermediate Spending Limit Report Request procedure. |
|
AVP |
Qualifier |
Compliance |
Comment |
|---|---|---|---|
|
Subscription-Id AVP |
M |
C |
|
|
Logical-Access-ID AVP |
C |
NC |
|
|
Physical-Access-ID AVP |
C |
NC |
|
|
SL-Request-Type AVP |
M |
C |
|
|
Policy-Counter-Identifier AVP |
Op |
NC |
The SAPC does not support the Intermediate Spending Limit Report Request procedure and does not specify the policy counter at the Initial SLR. |
4.5.1.2 Detailed Behaviour of the PCRF
|
Text |
Qualifier |
Compliance |
Comment |
|---|---|---|---|
|
The PCRF shall make use of this procedure when it determines for a subscriber that the status of policy counter(s) to which the PCRF does not have an existing subscription for status change notifications is/are required. |
M |
C |
The SAPC sends the Initial Spending Limit Report Request at IP-CAN session establishment. |
|
The PCRF shall make use of this procedure when it determines for a subscriber that the status of one or more, but not all, policy counter(s) to which the PCRF has an existing subscription for status change notifications are no longer required. |
M |
NC |
The SAPC does not support the Intermediate Spending Limit Report Request procedure and does never specify the policy counter at any case. |
|
In the initial request, i.e. when the request is sent for the first time for the Subscriber, the PCRF shall set the SL-Request-Type AVP to the value INITIAL_REQUEST (0). |
M |
C |
|
|
For subsequent requests for the same Subscriber, the PCRF shall set the SL-Request-Type AVP to INTERMEDIATE_REQUEST (1). |
M |
NC |
The SAPC does not support the Intermediate Spending Limit Report Request procedure. |
|
For each policy counter that the PCRF requires the current status and notifications of future status changes, the PCRF shall indicate the concerned policy counter identifiers in the request. |
M |
NC |
The SAPC does not specify the policy counter at any case. It always omits Policy Counter identifier to request current status and notifications of future status changes of all available policy counters. |
|
The policy counter identifiers may be omitted if the PCRF requires the current status and notifications of future status changes of all available policy counters. |
Op |
C |
The SAPC always omits Policy Counter identifier to request current status and notifications of future status changes of all available policy counters. |
4.5.1.3 The Behaviour of the OCS
No requirement
4.5.2 Spending Limit Report
4.5.2.1 General
|
Text |
Qualifier |
Compliance |
Comment |
|---|---|---|---|
|
Policy-Counter-Status-Report AVP |
M |
PC |
Pending policy counter statuses and activation times are not supported. |
4.5.2.2 The Behaviour of the OCS
No requirement
4.5.2.3 Detailed Behaviour of the PCRF
|
Text |
Qualifier |
Compliance |
Comment |
|---|---|---|---|
|
The PCRF shall acknowledge the request by sending a response with a Result-Code AVP set to DIAMETER_SUCCESS and use the status of the received policy counter(s) as input to its policy decision to apply operator defined actions, e.g. downgrade the QoS. |
M |
C |
|
|
The PCRF shall ignore an unknown policy counter status report for all unknown policy counter identifiers in an SLA or in an SNR from the OCS. |
M |
C |
|
|
If the PCRF receives an SNR command while it has an ongoing SLR transaction with the OCS, the PCRF shall update the policy counter information based on the SNR command. |
M |
NC |
|
|
When the corresponding SLA command for the ongoing SLR transaction is eventually received, the PCRF shall only update policy counter information for counters that were not provided in the previously received SNR command. |
M |
NC |
|
|
If the PCRF receives a Policy-Counter-Status-Report with one or more Pending-Policy-Counter-Information AVPs, then at the time defined by the Pending-Policy-Counter-Change-Time AVP, the pending Policy-Counter-Status shall autonomously become the current status of a policy counter. Subsequently provided information for pending statuses of a policy counter shall overwrite the previously received information. |
M |
NC |
|
|
If the pending policy counter statuses are applicable to a policy counter identifier but the Pending-Policy-Counter-Information AVPs are omitted in the new policy counter status report, the PCRF shall remove all the pending policy counter statuses. |
M |
NC |
4.5.3 Final Spending Limit Report Request
4.5.3.1 General
|
Text |
Qualifier |
Compliance |
Comment |
|---|---|---|---|
|
This procedure shall be used by the PCRF to unsubscribe to any future updates of policy counters for a given subscriber by the OCS. |
M |
C |
|
AVP |
Qualifier |
Compliance |
Comment |
|---|---|---|---|
|
Termination-Cause AVP |
M |
C |
4.5.3.2 Detailed Behaviour of the PCRF
|
Text |
Qualifier |
Compliance |
Comment |
|---|---|---|---|
|
When the PCRF decides that policy decisions for a given user no longer depend on policy counter(s) to which the PCRF has existing subscriptions for status change notifications, the PCRF shall send the Final Spending Limit Report Request to the OCS. |
M |
C |
The SAPC sends the Final Spending Limit Report Request only at the last IP CAN session termination for that subscriber. |
4.5.3.3 The Behaviour of the OCS
No requirement
5 Sy Protocol
5.1 Protocol Support
5.1.1 Use of Diameter Base Protocol
Compliant
5.1.2 Void
No requirement
5.1.3 Accounting Functionality
Compliant
5.1.4 Transport Protocol
Compliant
5.1.5 Advertising Application Support
|
Text |
Qualifier |
Compliance |
Comment |
|---|---|---|---|
|
The Diameter application identifier assigned to the Sy interface application is 16777302. |
M |
C |
|
|
The PCRF and OCS shall advertise support of the Diameter Sy Application by including the value of the Sy application identifier in the Auth-Application-Id AVP within the Vendor-Specific-Application-Id grouped AVP of the Capabilities-Exchange-Request and Capabilities-Exchange-Answer commands. |
M |
C |
|
|
The vendor identifier value of 3GPP (10415) shall be included in the Supported-Vendor-Id AVP of the Capabilities-Exchange-Request and Capabilities-Exchange-Answer commands, and in the Vendor-Id AVP within the Vendor-Specific-Application-Id grouped AVP of the Capabilities-Exchange-Request and Capabilities-Exchange-Answer commands. |
M |
C |
|
|
The Vendor-Id AVP included in Capabilities-Exchange-Request and Capabilities-Exchange-Answer commands that is not included in the Vendor-Specific-Application-Id AVPs as described above shall indicate the manufacturer of the Diameter node as per RFC 3588 . |
M |
C |
5.1.6 Use of the Supported-Features AVP
Compliant
5.2 Initialization and Maintenance of Connection and Session
|
Text |
Qualifier |
Compliance |
Comment |
|---|---|---|---|
|
The Diameter protocol between the PCRF and the OCS, shall always keep the session state, and use the same Session-Id parameter for the lifetime of each Diameter session. |
M |
C |
|
|
Each Diameter session shall identify a Sy session for a given user. In order to indicate that the session state is to be maintained, the Diameter client and server shall not include the Auth-Session-State AVP, either in the request or in the response messages. |
M |
C |
|
|
The PCRF shall link the Gx session(s) or S9 session with the Sy session at Sy session initialization and maintain that until the IP-CAN session(s) for that subscriber are terminated or no IP-CAN session for the same user depends on the spending status information provided over Sy reference point. |
M |
PC |
The SAPC does not support S9 reference point related procedures. |
5.3 Sy Specific AVPs
|
Text |
Qualifier |
Compliance |
Comment |
|---|---|---|---|
|
M |
C |
||
|
Policy-Counter-Identifier |
M |
C |
Although supported, the SAPC only recognizes it as part of the Policy-Counter-Status-Report Grouped AVP reception and never at the command level. |
|
Policy-Counter-Status |
M |
C |
|
|
Policy-Counter-Status-Report |
M |
PC |
The SAPC does not support the Pending-Policy-Counter-Information AVP. |
|
SL-Request-Type |
M |
PC |
INTERMEDIATE_REQUEST (1) value is NOT supported. |
|
Pending-Policy-Counter-Information |
M |
NC |
|
|
Pending-Policy-Counter-Change-Time |
M |
NC |
5.4 Sy Re-Used AVPs
|
Text |
Qualifier |
Compliance |
Comment |
|---|---|---|---|
|
DRMP |
C |
NC |
|
|
Subscription-Id |
M |
C |
|
|
Logical-Access-ID |
C |
NC |
|
|
OC-OLR |
C |
NC |
|
|
OC-Supported-Features |
C |
NC |
|
|
Physical-Access-ID |
C |
NC |
5.5 Sy Specific Experimental-Result-Code AVP Values
5.5.1 General
5.5.2 Permanent Failures
|
Text |
Qualifier |
Compliance |
Comment |
|---|---|---|---|
|
The Result-Code AVP values defined in Diameter base protocol IETF RFC 3588 [3] are applicable. Also, the following Result-Code AVP value defined in IETF RFC 4006 [5] is applicable: DIAMETER_USER_UNKNOWN (5030) |
M |
C |
|
|
The following specific Sy Experimental-Result-Code value is defined for permanent failures: DIAMETER_ERROR_UNKNOWN_POLICY_COUNTERS (5570) |
M |
NC |
Since the SAPC does not specify the policy counter at any case, this error does not apply. |
5.5.3 Transient Failures
|
Text |
Qualifier |
Compliance |
Comment |
|---|---|---|---|
|
The Result-Code AVP values defined in Diameter base protocol IETF RFC 3588 [3] are applicable. Also the following specific Sy Experimental-Result-Code value is defined for transient failures: DIAMETER_ERROR_NO_AVAILABLE_POLICY_COUNTERS (4241) |
M |
C |
DIAMETER_ERROR_UNKNOWN_POLICY_COUNTERS (5570) is not supported since the SAPC does not specify the policy counter at any case, so this error does not apply. |
5.6 Sy Messages
5.6.1 Command-Code Values
|
Text |
Qualifier |
Compliance |
Comment |
|---|---|---|---|
|
Spending-Limit-Request (SLR): Code 8388635 |
M |
C |
|
|
Spending-Limit-Answer (SLA): Code 8388635 |
M |
C |
|
|
Spending-Status-Notification-Request (SNR): Code 8388636 |
M |
C |
|
|
Spending-Status-Notification-Answer (SNA): Code 8388636 |
M |
C |
|
|
Session-Termination-Request (STR) |
M |
C |
|
|
Session-Termination-Answer (STA) |
M |
C |
|
|
For the commands defined in the Sy reference point specification and reused commands, the Application-ID field shall be set to 16777302. |
M |
C |
5.6.2 Spending-Limit-Request (SLR) Command
|
Text |
Qualifier |
Compliance |
Comment |
|---|---|---|---|
|
Spending-Limit-Request (SLR) |
M |
C |
5.6.5 Spending-Status-Notification-Answer (SNA) Command
|
Text |
Qualifier |
Compliance |
Comment |
|---|---|---|---|
|
Spending-Status-Notification-Answer (SNA) |
M |
C |
5.6.6 Session-Termination-Request (STR) Command
|
Text |
Qualifier |
Compliance |
Comment |
|---|---|---|---|
|
Session-Termination-Request (STR) |
M |
C |
5.6.7 Session-Termination-Answer (STA) Command
|
Text |
Qualifier |
Compliance |
Comment |
|---|---|---|---|
|
Session-Termination-Answer (STA) |
M |
C |
7 Annex B (Informative): Change History
No requirement
8 Reference List
-
Diameter Base Protocol - 1/174 02-CRA 119 0019/2 Uen
-
3GPP Technical Specification Group Core Network and Terminals; Policy and Charging Control: Spending Limit Reporting over Sy Reference Point - 29.219

Contents