Statement of Compliance 15/174 02-AXB 901 33/7 -V3 Uen A

Statement of Compliance towards 3GPP Technical Specification 29.219 (Release 14)
Ericsson Service-Aware Policy Controller

Contents


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 V14.2.0 (2017-06) 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 V14.2.0 (2017-06).

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

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

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

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

Table 4   Initial/Intermediate Spending Limit Report Request: Mapping Information Element to Diameter AVP

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.

Table 5   Initial/Intermediate Spending Limit Report Response: Mapping Information Element to Diameter AVP

AVP

Qualifier

Compliance

Comment

Policy-Counter-Status-Report AVP

C

C

 

Result-Code AVP

M

C

 

Experimental-Result AVP

M

C

 

4.5.1.2 Detailed Behaviour of the PCRF

Table 6   Detailed behaviour of the PCRF for the Initial/Intermediate Spending Limit Report Procedure

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

Table 7   Spending Limit Report Request: Mapping Information Element to Diameter AVP

Text

Qualifier

Compliance

Comment

Policy-Counter-Status-Report AVP

M

PC

Pending policy counter statuses and activation times are not supported.

Table 8   Spending Limit Report Response: Mapping Information Element to Diameter AVP

Text

Qualifier

Compliance

Comment

Result-Code AVP

M

C

 

Experimental-Result AVP

M

NC

 

4.5.2.2 The Behaviour of the OCS

No requirement

4.5.2.3 Detailed Behaviour of the PCRF

Table 9   Detailed Behaviour of the PCRF for the Spending Limit Report Procedure

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

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

 
Table 11   Final Spending Limit Report Request: Mapping Information Element to Diameter AVP

AVP

Qualifier

Compliance

Comment

Termination-Cause AVP

M

C

 

4.5.3.2 Detailed Behaviour of the PCRF

Table 12   Detailed Behaviour of the PCRF for the Final Spending Limit Report Procedure

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

No requirement

5.1.3 Accounting Functionality

Compliant

5.1.4 Transport Protocol

Compliant

5.1.5 Advertising Application Support

Table 13   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 IETF RFC 6733 [23].

M

C

 

5.2 Initialization and Maintenance of Connection and Session

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

Table 15   Sy Specific Diameter AVPs

Text

Qualifier

Compliance

Comment

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

 

5.4 Sy Re-Used AVPs

Table 16   Sy Re-Used AVPs

Text

Qualifier

Compliance

Comment

DRMP

C

NC

 

Subscription-Id

M

C

 

Load

C

NC

 

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

Table 17   General

Text

Qualifier

Compliance

Comment

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

 

5.5.2 Permanent Failures

Table 18   General

Text

Qualifier

Compliance

Comment

The Result-Code AVP values defined in Diameter base protocol IETF RFC 6733 [23] 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

Table 19   General

Text

Qualifier

Compliance

Comment

The Result-Code AVP values defined in Diameter base protocol IETF RFC 6733 [23] 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

Table 20   Command-Code Values for Sy

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

Table 21   Spending-Limit-Request (SLR) Command

Text

Qualifier

Compliance

Comment

Spending-Limit-Request (SLR)

M

C

 

5.6.3 Spending-Limit-Answer (SLA) Command

Table 22   Spending-Limit-Answer (SLR) Command

Text

Qualifier

Compliance

Comment

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.

5.6.4 Spending-Status-Notification-Request (SNR) Command

Table 23   Spending-Status-Notification-Request (SNR) Command

Text

Qualifier

Compliance

Comment

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.

5.6.5 Spending-Status-Notification-Answer (SNA) Command

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

Table 25   Session-Termination-Request (STR) Command

Text

Qualifier

Compliance

Comment

Session-Termination-Request (STR)

M

C

 

5.6.7 Session-Termination-Answer (STA) Command

Table 26   Session-Termination-Request (STA) Command

Text

Qualifier

Compliance

Comment

Session-Termination-Answer (STA)

M

C

 

6 Annex A (Normative): User Identity for Fixed Broadband Access Network Convergence

Not compliant

7 Annex B (Informative): Change History

No requirement

8 Reference List

Ericsson Documents

  1. Diameter Base Protocol - 1/174 02-CRA 119 0019/2 Uen

Standard

  1. 3GPP Technical Specification Group Core Network and Terminals; Policy and Charging Control: Spending Limit Reporting over Sy Reference Point - 29.219