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.

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

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.

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.

Policy-Counter-Status-Report AVP

C

C

Result-CodeAVP

M

C

Experimental-Result AVP

M

C

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

Policy-Counter-Status-Report.

M

PC

Pending policy counter statuses and activation times are not supported.

Result-Code AVP.

M

C

Experimental-Result AVP

M

NC

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

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

Termination-Cause AVP

M

C

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.

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

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.

Vendor-Id header of all AVPs shall be set to 3GPP (10415).

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

Subscription-Id

M

C

Logical-Access-ID

C

NC

Physical-Access-ID

C

NC

The Experimental-Result-Code AVP (AVP Code 298) is of type Unsigned32 and contains a vendor-assigned value representing the result of processing a request. The Vendor-ID AVP shall be set to 3GPP (10415).

M

C

The Result-Code AVP values defined in Diameter BASE RFC 3588 Reference [1] are applicable. Also the following Result-Code AVP value defined in IETF RFC 4006 Reference [2] 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.

The Result-Code AVP values defined in Diameter BASE RFC 3588 Reference [1] are applicable. Also the following specific Sy Experimental-Result-Codes value is defined for transient failure:

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.

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

Spending-Limit-Request (SLR)

M

C

Spending-Limit-Answer (SLA)

M

C

Note: The SAPC does not recognize changes at the Origin-State-Id sent by the OCS at the Sy Application.

Spending-Status-Notification-Request (SNR)

M

C

Note: The SAPC does not recognize changes at the Origin-State-Id sent by the OCS at the Sy Application.

Spending-Status-Notification-Answer (SNA)

M

C

Session-Termination-Request (STR)

M

C

Session-Termination-Answer (STA)

M

C