4 Sy reference point

29.2193GPPPolicy and charging control: Spending limit reporting over Sy reference pointRelease 17TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

4.1 Overview

The Sy reference point is located between the Policy and Charging Rules Function (PCRF) and the Online Charging System (OCS). The Sy reference point enables transfer of policy counter status information relating to subscriber spending from OCS to PCRF and supports the following functions:

– Request of policy counter status reporting from PCRF to OCS and subscribe to or unsubscribe from spending limit reports (i.e. notifications of policy counter status changes).

– Notification of spending limit reports from OCS to PCRF.

– Cancellation of spending limit reporting from PCRF to OCS.

Since the Sy reference point resides between the PCRF and OCS in the HPLMN, roaming with home routed or visited access as well as non-roaming scenarios are supported in the same manner.

The stage 2 level requirements for the Sy reference point are defined in 3GPP TS 23.203 [2].

Signalling flows related to the Sy interface are specified in 3GPP TS 29.213 [8].

Refer to Annex G of 3GPP TS 29.213 [8] for Diameter overload control procedures over the Sy interface.

Refer to Annex J of 3GPP TS 29.213 [8] for Diameter message priority mechanism procedures over the Sy interface.

Refer to Annex K of 3GPP TS 29.213 [8] for Diameter load control procedures over the Sy interface.

4.2 Sy Reference model

The Sy reference point is defined between the PCRF and the OCS. The relationships between the involved functional entities are depicted in figure 4.2.1. The overall PCC architecture is depicted in clause 3a of 3GPP TS 29.213 [8]

Figure 4.2.1: Sy reference model

.Figure 4.2.2: Void

4.3 Subscriber Spending Limits

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.

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. The PCRF may request specific or all policy counter statuses to be reported by the OCS for the user. The OCS provides the status to the PCRF of the requested policy counters, and will notify the PCRF of any changes in the status of those policy counters. 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.

NOTE 1: The mechanism for provisioning the policy counters in the OCS is out of scope of this document.

NOTE 2: A policy counter in the OCS can represent the spending for one or more services, one or more devices, one or more subscribers, etc. The representation is operator dependent. There is no explicit relationship between Charging-Key and policy counter.

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. The PCRF may cancel spending limit reporting for all policy counter(s) using the Final Spending Limit Report Request.

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). If spending limit reporting for a policy counter is enabled, the OCS shall notify the PCRF of changes in the status of this policy counter (e.g. daily spending limit of $2 reached) and optionally pending statuses of this policy counter with the activation time (e.g. due to a billing period that will expire at midnight).

4.4 Functional elements

4.4.1 PCRF

The Policy Control and Charging Rules Function (PCRF) is a functional element that encompasses policy control decision and flow based charging control functionalities.

The PCRF may take information on the subscriber’s spending status into account in its policy decisions. 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. 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.

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. 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.

The PCRF may use the status of each relevant policy counter as input to its policy decision as required by the decision logic.

4.4.2 OCS

The Online Charging System (OCS), for the purpose of policy decisions based on the subscriber’s spending, shall:

– maintain the policy counter statuses applicable for a subscriber.

– report the policy counter status values for the subscriber when requested to the PCRF.

– when a policy counter status changes, report the change to the PCRF.

4.5 Spending Limits procedures over Sy reference point

4.5.1 Initial/Intermediate Spending Limit Report Request

4.5.1.1 General

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.

This procedure is mapped to the Spending-Limit-Request/Answer commands specified in clause 5.6.

Table 4.5.1.1/1: Initial/Intermediate Spending Limit Report Request

Information element name	Mapping to Diameter AVP	Cat.	Description
User Identity	Subscription-Id, Logical-Access-ID AVP, Physical-Access-ID (NOTE 1)	C	This IE shall contain the identity of the user. It shall be present in the initial request when the SL-Request-Type=INITIAL_REQUEST.
Request Type	SL-Request-Type	M	This IE shall indicate whether this is the initial or a subsequent request for the user.
Subscribed Policy Counter Identifier List	Policy-Counter-Identifier	O	This IE shall indicate the list of policy counter identifiers to be subscribed to. In the intermediate spending limit report request procedure, this list overrides a previously provisioned list. If omitted in either the Initial or Intermediate Spending Limit Report Request procedures the PCRF requests subscription to all available policy counters.
NOTE 1: The Logical-Access-ID AVP and Physical-Access-ID AVP are only applicable to Fixed Broadband Access network convergence as defined in annex A.

Table 4.5.1.1/2: Initial/Intermediate Spending Limit Report Response

Information element name	Mapping to Diameter AVP	Cat.	Description
Policy Counter Status Report	Policy-Counter-Status-Report	O	If present, this information element shall contain a policy counter identifier, the current status value and if applicable pending policy counter statuses with the activation times.
Result	Result-Code or Experimental-Result	M	This IE shall contain the result of the operation.

4.5.1.2 Detailed behaviour of the PCRF

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.

– 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.

NOTE: The Final Spending Limit Request procedure in clause 4.5.3 is used to remove all subscriptions.

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). For subsequent requests for the same Subscriber, the PCRF shall set the SL-Request-Type AVP to INTERMEDIATE_REQUEST (1).

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. Alternatively, 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.

4.5.1.3 The behaviour of the OCS

Upon reception of the request from the PCRF, the OCS shall check if there is an ongoing Sy session associated with the received Session-Id AVP. If there is no Sy session and the SL-Request-Type AVP is set to INITIAL_REQUEST (0), an Sy session is created on the OCS. If there is an Sy session and the SL-Request-Type AVP is not set to INTERMEDIATE_REQUEST (1), the OCS shall return a response with the Result-Code set to DIAMETER_INVALID_AVP_VALUE and with the Failed-AVP AVP containing the SL-Request-Type AVP. If there is no Sy session and the SL-Request-Type AVP is not set to INITIAL_REQUEST (0), the OCS shall return a response with the Result-Code AVP set to DIAMETER_UNKNOWN_SESSION_ID.

Upon reception of the request from the PCRF provided with explicit Policy Counter Identifier(s):

If all the policy counter identifiers are known to the OCS, the OCS shall be able to subsequently notify the PCRF of any policy counter state changes and/or additions, removal or changes of pending policy counter statuses along with their activation time.

If a policy counter identifier is known by the OCS, but is not applicable to the subscriber (e.g. not provisioned), the OCS may use an operator configured policy counter status to indicate this to the PCRF.

If the OCS is configured to accept the request provided with unknown policy counter identifier(s) , and if the OCS determines that one or more policy counter identifiers are unknown, an operator configured policy counter status may be used to indicate the policy counter identifier(s) determined as unknown by OCS. The status of known policy counter identifier(s) shall be returned to the PCRF in the same procedure in this case.

Alternatively, if the OCS is configured to reject the request provided with unknown policy counter identifier(s), and if the OCS determines that one or more policy counter identifiers are unknown, the OCS shall return a response with the Experimental-Result-Code AVP set to DIAMETER_ERROR_UNKNOWN POLICY_COUNTERS and with the Failed-AVP AVP indicating the unknown policy counter identifiers. When this failure occurs, if the SL-Request-Type AVP is set to:

– INITIAL_REQUEST (0), then the Sy session is not created.

– INTERMEDIATE_REQUEST (1), then none of the changes in the request take effect but the Sy session is maintained.

NOTE 1: In order to avoid misbehaviors due to the policy counters maintained in the Sy session, the PCRF can terminate the Sy session invoking the Final Spending Limit Request procedure in clause 4.5.3.

When the PCRF provides a new subscribed policy counter identifier list, the OCS shall remove any policy counter identifiers no longer in the list from association with the Sy session such that the OCS will no longer notify the PCRF of those policy counter state changes.

If an initial or intermediate request contains no policy counter identifiers, the OCS shall subsequently notify the PCRF of all available policy counter state changes and optionally the pending policy counter statuses with the activation times. If the OCS has no available policy counters for that subscriber during the Initial Spending Limit Report Request procedure, it sets the Experimental-Result-Code to DIAMETER_ERROR_NO_AVAILABLE_POLICY_COUNTERS. When this failure occurs, if the SL-Request-Type AVP is set to:

– INITIAL_REQUEST (0), then the Sy session is not created.

– INTERMEDIATE_REQUEST (1), then none of the changes in the request take effect but the Sy session is maintained.

NOTE 2: The PCRF can terminate the Sy session invoking the Final Spending Limit Request procedure in clause 4.5.3, or maintain the Sy session assuming that further available policy counters will be notified.

If the user identified in an initial request is not known to the OCS, the OCS shall reject the Spending Limit Report Request by including the result code of DIAMETER_USER_UNKNOWN in the Spending Limit Report Answer. In this case, the Sy session is not created.

Upon successful creation of an Sy session, the OCS shall include the current status of all subscribed policy counters (if any) in the response and set the Result-Code to DIAMETER_SUCCESS.

4.5.2 Spending Limit Report

4.5.2.1 General

This procedure shall be used by the OCS to notify the PCRF of changes in the status of subscribed policy counter(s).

This procedure is mapped to the Spending-Status-Notification-Request /Answer commands specified commands specified in clause 5.6.

Table 4.5.2.1/1: Spending Limit Report Request

Information element name	Mapping to Diameter AVP	Cat.	Description
Policy Counter Status Report	Policy-Counter-Status-Report	M	If present, this information element shall contain a policy counter identifier, the current status value and if applicable pending policy counter statuses with the activation times.

Table 4.5.2.1/2: Spending Limit Report Response

Information element name	Mapping to Diameter AVP	Cat.	Description
Result	Result-Code or Experimental-Result	M	This IE shall contain the result of the operation.

4.5.2.2 The behaviour of the OCS

When the status of a specific policy counter changes or when pending statuses associated with the policy counter are added, removed or changed, the OCS shall determine the Sy sessions impacted by the change (i.e. those Sy sessions that have subscribed to status change notifications for the changed policy counter) and send a Spending-Status-Notification-Request command including the current policy counter status, and if applicable pending policy counter statuses with the activation times to the PCRF associated with each affected Sy session. The OCS shall not send the policy counter status for the same policy counter until it received the response of the previous status report of the policy counter.

If several policy counters change status at the same time, the OCS may group the status change notifications into a single Spending-Status-Notification-Request command to the PCRF by sending multiple Policy-Counter-Status-Report AVPs in the request.

4.5.2.3 Detailed behaviour of the PCRF

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.

NOTE: The values related to the status of a policy counter (e.g. valid, invalid or any other status) are not specified. The interpretation and actions related to the values are out of scope of 3GPP.

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.

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. 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.

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. 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.

4.5.3 Final Spending Limit Report Request

4.5.3.1 General

This procedure shall be used by the PCRF to unsubscribe to any future updates of policy counters for a given subscriber by the OCS.

This procedure is mapped to the Session-Termination-Request/Answer commands specified in IETF RFC 6733 [23].

Table 4.5.3.1/1: Final Spending Limit Report Request

Information element name	Mapping to Diameter AVP	Cat.	Description
Termination Cause	Termination-Cause	M	This IE shall contain the reason why the session was terminated. It shall be set to "DIAMETER_LOGOUT".

Table 4.5.3.1/2: Final Spending Limit Report Response

Information element name	Mapping to Diameter AVP	Cat.	Description
Result	Result-Code	M	This IE shall contain the result of the operation.

4.5.3.2 Detailed behaviour of the PCRF

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.

4.5.3.3 The behaviour of the OCS

Upon reception of the request from the PCRF, the OCS shall check that there is an ongoing Sy session associated with the received Session-Id AVP. If there is no Sy session, the OCS shall return a response with the Result-Code AVP set to DIAMETER_UNKNOWN_SESSION_ID.

The OCS shall remove all policy counter subscriptions associated with the Sy session such that the OCS will no longer notify the PCRF of policy counter state changes and close the session by returning a response with the Result-Code AVP set to DIAMETER_SUCCESS.

4.5.4 Sy Session Termination by the OCS

If the ASR feature is supported, and the OCS decides that the Sy session for a subscriber needs to be terminated (e.g. because subscriber is removed from an OCS system), the OCS shall send the Spending-Status-Notification-Request (SNR) conaining the SN-Request-Type AVP with bit 1 (Abort Session Request) set to the PCRF.

Upon receipt of the SNR containing the SN-Request-Type AVP with bit 1 set, the PCRF shall acknowledge the receipt of the SNR by sending the Spending-Status-Notification-Answer (SNA) and shall then send a Final Spending Limit Report Request as specified in clause 4.5.3.

NOTE: The termination of the Sy session causes the H-PCRF to make the applicable policy decision and act accordingly, i.e. sessions on other interfaces such as the Rx or Gx interface will remain established, unless the policy decision causes their termination.