Sy Interface Description

Ericsson Service-Aware Policy Controller

1	Introduction
1.1	Document Purpose and Scope
1.2	Concepts
1.3	Typographic Conventions
2	Overview
3	Message Exchange
4	Diameter Base Protocol Messages
4.1	Sy Capability Negotiation
4.2	Device Watchdog
4.3	Disconnect Peer
5	Sy Interface Messages Format
5.1	Spending-Limit-Request (SLR)
5.2	Spending-Limit-Answer (SLA)
5.3	Spending-Status-Notification-Request (SNR)
5.4	Spending-Status-Notification-Answer (SNA)
5.5	Session-Termination-Request (STR)
5.6	Session-Termination-Answer (STA)
6	Ericsson Sy Messages Format
6.1	Ericsson Spending-Limit-Request (SLR)
6.2	Ericsson Spending-Limit-Answer (SLA)
6.3	Ericsson Spending-Status-Notification-Request (SNR)
6.4	Ericsson Spending-Status-Notification-Answer (SNA)
6.5	Ericsson Session-Termination-Request (STR)
6.6	Ericsson Session-Termination-Answer (STA)
7	Error Handling
7.1	Protocol Errors
7.2	Application Errors
Glossary
Reference List

Abstract

This document describes the standard 3GPP Sy interface used for spending limit reporting delivery between the SAPC and an Online Charging System (OCS).

This document also describes the (not standard) Ericsson Sy interface used for spending limit reporting and subscription information delivery between the SAPC and the Ericsson Charging System.

1 Introduction

1.1 Document Purpose and Scope

This document describes the standard 3GPP Sy interface used for spending limit reporting delivery between the SAPC and an Online Charging System (OCS).

This document also describes the (not standard) Ericsson Sy interface used for spending limit reporting and subscription information delivery between the SAPC and the Ericsson Charging System.

1.1.1 Document Content Conventions

This document contains the specific details supported by the SAPC implementation.

This document does not repeat information that can be found in 3GPP Technical Specifications or Diameter Base Protocol RFC.

For detailed information about Statement of Compliance towards different 3GPP Release versions (for example Rel9, Rel10 and so on), see the corresponding SoCs documents.

Each message is described with the list of parameters (AVPs) exchanged between the Diameter peers.

For incoming messages received in the SAPC, this document only indicates the AVPs that the SAPC reads to perform the corresponding business logic or evaluation inside policy conditions.
The SAPC can receive other AVPs (but does not use them) that can be found in 3GPP Technical Specifications, but are not stated in this document. This is possible because the SAPC uses a dictionary that specifies the format of messages and AVPs. The SAPC behaves in the following way (standard Diameter Base Protocol behavior):
1. If the SAPC receives in a message an AVP with M bit set to 1, and that AVP is not included in the dictionary, the SAPC rejects the message indicating DIAMETER_AVP_UNSUPPORTED.
2. If the SAPC receives in a message an AVP defined in the dictionary, but with different values in the flag bits, the SAPC rejects the message indicating DIAMETER_INVALID_AVP_BITs.
3. If the SAPC receives in a message an AVP with M bit set to 0, ant that AVP is not defined in the dictionary, the SAPC does not reject the message, but ignores the AVP value.
For outgoing messages (and AVPs) sent by the SAPC, this document indicates only the AVPs that the SAPC fills.

Note:: When the SAPC does not support a message or AVP for all 3GPP Release versions (for example Rel9, Rel10 and so on), it is explicitly indicated in this document.

1.2 Concepts

AVP	Attribute Value Pair. The Diameter protocol consists of a header followed by one or more Attribute Value Pairs (AVP). The AVP includes a header and is used to encapsulate protocol-specific data (for example routing information) as well as authentication, authorization, or accounting information.

Configured data related to an AVP	Within this document, whenever a data related to an AVP is described as configured in the SAPC. It refers to static configuration (for example, as part of the subscriber profile data or as part of the service description) and/or configuration based on policies.

1.3 Typographic Conventions

This document uses the following typographic conventions:

Table 1 Typographic Conventions
Convention	Description	Example
AVPs and parameters presence in a message	Indicates the presence conditions of the AVPs and the parameters in a message: `< name >`: Always included in the message in a fixed position. `{ name }`: Always included in the message in any position. `[ name ]`: Optional in the message. `[min][max]`: Indicates the minimum and maximum number of times the element can be present. A preceding “” (for example *[name]) means that multiple instances of the parameter can occur. The default value of `min` is 0. The default value of `max` is infinity.	The `Spending—Limit-` `Request` (SLR) has `Command-Code` 8388635

2 Overview

The SAPC performs Policy Control functions through Gx interface using the information about Policy Counters received in Sy interface.

3GPP Sy (Reference [1]) is built over Diameter Base Protocol RFC (Reference [2]). The SAPC supports 3GPP Sy from Rel11 onwards.

For detailed support about 3GPP Release versions of Reference [1], see the corresponding Statement of Compliance documents.

Ericsson has developed a proprietary Sy Interface. This Ericsson Sy interface can be used for spending limit reporting and subscription information delivery between the SAPC and the Ericsson Charging System.

3 Message Exchange

As an example of the Diameter messages exchange in a communication between the OCS and the SAPC, see next figure:

Figure 1 Sy Interface Messages Flow

The SAPC sends the Spending-Limit-Report request command to the OCS to get information about the status of stored spending limits. This information is used to determine the answer to the Gx CCR initial request. The SAPC builds the Gx CCA Initial using the response from the OCS with other subscriber data.

The SAPC considers the information stored in the Sy session to process subsequent Gx Updates, being not necessary to contact again the OCS.

The OCS sends the Spending-Status-Notification command to the SAPC when there is an update in spending limits. The SAPC uses the updated received information with other subscriber data to determine if the active IP-CAN sessions must be reauthorized.

The SAPC sends the Session-Termination command to the OCS when the Gx session is terminated for the subscriber.

The SAPC sends Capabilities-Exchange Request when a Sy connection is configured, and Disconnect-Peer Request when it is removed from the configuration.

4 Diameter Base Protocol Messages

4.1 Sy Capability Negotiation

Table 2 lists the AVPs that the SAPC sends in a CER message.

Table 2 CER AVPs
AVP Name	AVP Code	Comment	Reference
[Firmware-Revision]	367	-	RFC 6733
1* { Host-IP-Address }	257	-	RFC 6733
{ Origin-Host }	264	-	RFC 6733
{ Origin-Realm }	296	-	RFC 6733
[ Product-Name ]	269	-	RFC 6733
* [Supported-Vendor-Id ]	265	The SAPC sends the values assigned to other supported vendors, different than the vendor device (Ericsson): `10415(3GPP)`	RFC 6733
Vendor-Id	266	The SAPC sets it to value 193 (Ericsson).	RFC 6733
*[ Vendor-Specific- Application-Id ]	260	The SAPC sends the following AVP values: For 3GPP Sy: `Vendor-Id=10415(3GPP)` `Auth-Application-Id= 16777302(3GPP Sy)` For Ericsson Sy: `Vendor-Id= 193 (Ericsson)` `Auth-Application-Id= 16777304`	RFC 6733

Table 3 lists the AVPs that the SAPC support in a CEA message.

Table 3 CEA AVPs
AVP Name	AVP Code	Comment	Reference
`{Auth-` `Application-Id}`	258	-	RFC 6733
`[Error-Message]`	281	-	RFC 6733
`[Failed-AVP]`	279		RFC 6733
`[Firmware-` `Revision]`	367	-	RFC 6733
`1*{Host-IP-` `Address}`	257	-	RFC 6733
`{Origin-` `Host}`	264	-	RFC 6733
`{Origin-` `Realm}`	296	-	RFC 6733
`[Product-` `Name]`	269	-	RFC 6733
`[Result-Code]`	268	-	RFC 6733
`* [Supported-` `Vendor-Id ]`	265	-	RFC 6733
`Vendor-Id`	266	-	RFC 6733
`*[ Vendor-` `Specific-` `Application-Id ]`	260	-	RFC 6733

Note:: The SAPC does not handle Origin-State-Id AVP in CEA message.

4.2 Device Watchdog

Table 4 lists the AVPs that the SAPC can receive or send in a DWR message.

Table 4 DWR AVPs
AVP Name	AVP Code	Comment	Reference
`{ Origin-Host }`	264	-	RFC 6733
`{ Origin-Realm }`	296	-	RFC 6733
`[ Origin-State-Id ]`	278	-	RFC 6733

Note:: The SAPC does not include Origin-State-Id AVP when it sends an outgoing DWR message.

Table 5 lists the AVPs that the SAPC can receive or send in a DWA message.

Table 5 DWA AVPs
AVP Name	AVP Code	Comment	Reference
`[Error-Message]`	281	-	RFC 6733
`[Failed-AVP]`	279	-	RFC 6733
`{ Origin-Host }`	264	-	RFC 6733
`{ Origin-Realm }`	296	-	RFC 6733
`[ Origin-State-Id ]`	278	-	RFC 6733

Note:: The SAPC does not include Origin-State-Id AVP when it sends an outgoing DWA message.

4.3 Disconnect Peer

Table 6 lists the AVPs that the SAPC supports in a DPR message.

Table 6 DPR AVPs
AVP Name	AVP Code	Comment	Reference
`{ Origin-Host }`	264	-	RFC 6733
`{ Origin-Realm }`	296	-	RFC 6733
`{Disconnect-Cause}`	273	-	RFC 6733

Table 7 lists the AVPs that the SAPC supports in a DPA message.

Table 7 DPA AVPs
AVP Name	AVP Code	Comment	Reference
`[Error-Message]`	281	-	RFC 6733
`[Failed-AVP]`	279	-	RFC 6733
`{ Origin-Host }`	264	-	RFC 6733
`{ Origin-Realm }`	296	-	RFC 6733
`[Result-Code]`	268	-	RFC 6733

5 Sy Interface Messages Format

5.1 Spending-Limit-Request (SLR)

Table 8 lists the AVPs that the SAPC sends in an SLR message.

Table 8 SLR AVPs
AVP Name	AVP Code	Comment	Reference
`<Session-Id>`	263	-	RFC 6733
`{Auth-` `Application-Id}`	258	-	3GPP TS 29.219
`{Destination-` `Realm}`	283	-	RFC 6733
`{Origin-Host}`	264	-	RFC 6733
`{Origin-Realm}`	296	-	RFC 6733
`[Origin-State-Id]`	278	The SAPC increments its value in standalone mode after restart. In geographical redundancy, the SAPC does not increment its value unless both SAPC peers are down. This MUST never happen, as the SAPC does a transparent switch-over (the Diameter peer always sees an operative node, the one in active state).	RFC 6733
`{SL-Request-` `Type}`	2904	The SAPC supports the following values: INITIAL_REQUEST (0)	3GPP TS 29.219
`*[Subscription-Id]`	443	The SAPC sends a single instance of this AVP, including inside the same Subscription-Type as the one considered for Gx traffic.	RFC 4006

5.2 Spending-Limit-Answer (SLA)

Table 9 lists the AVPs that the SAPC supports in a SLA message.

Table 9 SLA AVPs
AVP Name	AVP Code	Comment	Reference
`<Session-Id>`	263	-	RFC 6733
`{Auth-` `Application-Id}`	258	-	3GPP TS 29.219
`[Experimental-` `Result]`	297	-	RFC 6733
`*[Failed-AVP]`	279	-	RFC 6733
`{Origin-Host}`	264	-	RFC 6733
`{Origin-Realm}`	296	-	RFC 6733
`*[Policy-Counter-` `Status-Report]`	2903	The SAPC supports the following AVPs: `{Policy-Counter-Identifier}` `{Policy-Counter-Status}`	3GPP TS 29.219
`[Result-Code]`	268	-	RFC 6733

5.3 Spending-Status-Notification-Request (SNR)

Table 10 lists the AVPs that the SAPC supports in a SNR message.

Table 10 SNR AVPs
AVP Name	AVP Code	Comment	Reference
`<Session-Id>`	263	-	RFC 6733
`{Auth-` `Application-Id}`	258	-	3GPP TS 29.219
`{Destination-` `Host}`	293	-	RFC 6733
`{Destination-` `Realm}`	283	-	RFC 6733
`[Experimental-` `Result]`	297	-	RFC 6733

`{Origin-Host}`	264	-	RFC 6733
`{Origin-Realm}`	296	-	RFC 6733
`*[Policy-Counter-` `Status-Report]`	2903	See Policy-Counter-Status-Report.	3GPP TS 29.219

5.4 Spending-Status-Notification-Answer (SNA)

Table 11 lists the AVPs that the SAPC sends in a SNA message.

Table 11 SNA AVPs
AVP Name	AVP Code	Comment	Reference
`<Session-Id>`	263	-	RFC 6733
`*[Failed-AVP]`	279	-	RFC 6733
`{Origin-Host}`	264	-	RFC 6733
`{Origin-Realm}`	296	-	RFC 6733
`[Origin-State-Id]`	278	See Origin-State-Id	RFC 6733
`[Result-Code]`	268	-	RFC 6733

5.5 Session-Termination-Request (STR)

Table 12 lists the AVPs that the SAPC sends in a STR message.

Table 12 STR AVPs
AVP Name	AVP Code	Comment	Reference
`<Session-Id>`	263	-	RFC 6733
`{Auth-` `Application-Id}`	258	-	3GPP TS 29.219
`{Destination-` `Realm}`	283	-	RFC 6733
`{Origin-Host}`	264	-	RFC 6733
`{Origin-Realm}`	296	-	RFC 6733
`[Origin-State-Id]`	278	See Origin-State-Id	RFC 6733
`[Termination-` `Cause]`	295	The SAPC supports the following values: DIAMETER_LOGOUT (1)	RFC 6733

5.6 Session-Termination-Answer (STA)

The SAPC does not read any AVPs received in STA, except Session-Id and Result-Code AVP.

6 Ericsson Sy Messages Format

This section contains the information about Ericsson Sy interface.

6.1 Ericsson Spending-Limit-Request (SLR)

The Ericsson SLR command, indicated by the Command-Code field set to 8388633 and the 'R' bit set in the Command Flags field, is sent by the SAPC to the OCS to request balance information and subscription information to be used for Policy and Charging control.

Table 13 lists the AVPs that the SAPC sends in an Ericsson SLR message.

Table 13 SLR AVPs
AVP Name	AVP Code	Comment	Reference
`<Session-Id>`	263	-	RFC 6733
`{Auth-` `Application-Id}`	258	-	3GPP TS 29.219
`{Destination-` `Realm}`	283	-	RFC 6733
`{Ericsson-SL-Request-` `Type}`	1356	The SAPC supports the following values: INITIAL_REQUEST (0)	-
`{Origin-Host}`	264	-	RFC 6733
`{Origin-Realm}`	296	-	RFC 6733
`[Origin-State-Id]`	278	See Origin-State-Id	RFC 6733
`*[Subscription-Id]`	443	The SAPC sends a single instance of this AVP, including inside the same Subscription-Type as the one considered for Gx traffic.	RFC 4006

6.2 Ericsson Spending-Limit-Answer (SLA)

The Ericsson SLA command, indicated by the Command-Code field set to 8388633 and the 'R' bit cleared in the Command Flags field, is sent by the OCS to the SAPC in response to the SLR command.

It is used to return balance information (threshold states conveyed in counter states) and subscription information (conveyed in Policy Groups).

Table 14 lists the AVPs that the SAPC supports in an Ericsson SLA message.

Table 14 SLA AVPs
AVP Name	AVP Code	Comment	Reference
`<Session-Id>`	263	-	RFC 6733
`{Auth-` `Application-Id}`	258	-	3GPP TS 29.219
`*[Ericsson-` `Policy-Counter-` `Status-Report]`	1355	Grouped. It is used to indicate the status of the policy counters assigned to a subscriber. To indicate that the conveyed `{Ericsson-Policy-Counter-Identifier}` belongs to an specific Policy Group Policy-Counter-Policy-Group-Name AVP is included. The SAPC supports the following AVPs inside it: `{Ericsson-Policy-Counter-Identifier}`: AVP code 1354. It is of type UTF8String. It contains the name of the counter. `{Ericsson-Policy-Counter-Status}`: AVP code 1352. It is of type UTF8String. It contains the value of the counter. `[Policy-Counter-Policy-Group-Name]`: AVP Code 1353. It is of type UTF8String and contains the name of the related policy group.	-
`[Experimental-` `Result]`	297	-	RFC 6733
`*[Failed-AVP]`	279	-	RFC 6733
`{Origin-Host}`	264	-	RFC 6733
`{Origin-Realm}`	296	-	RFC 6733
`*[Policy-Group]`	1347	Grouped. It indicates what services and conditions are applicable for the subscriber based on subscription information. The Policy Group definition is implemented and realized in the SAPC as a Subscriber Group. The Policy Group name is derived in the Ericsson Charging System from the subscribed products and other subscription information. The SAPC supports the following AVPs inside it: `{Policy-Group-Name}`: AVP Code 1348. It is of type UTF8String and contains the name of the policy group. `[Policy-Group-Priority]`: AVP Code 1349. It is of type Unsigned32 and contains the priority of the policy group, compared to other policy groups for the subscriber. Values 0 to 4294967295 are defined, with value 0 as the highest priority. This is the default value applicable if this AVP is not included. `[Policy-Group-Activation-Time]`: AVP code 1350. It is of type Time. It indicates the NTP time when the Policy Group gets active. If not specified, the group is activated immediately. `[Policy-Group-Deactivation-Time]`: AVP code 1351. It is of type Time. It indicates the NTP time when the Policy Group gets inactive. If not specified, the Policy Group is permanently active.	-
`[Result-Code]`	268	-	RFC 6733

Note:: For [Policy-Group-Activation-Time]and [Policy-Group-Deactivation-Time]AVPs, the SAPC misunderstands NTP timestamp values greater than 4294967295 (corresponding to 6h 28m 15s, 7 February 2036 GMT).

6.3 Ericsson Spending-Status-Notification-Request (SNR)

The Ericsson SNR command, indicated by the Command-Code field set to 8388634 and the 'R' bit set in the Command Flags field, is sent by the Ericsson Charging System to the SAPC to inform about changes in the thresholds state or about changes in the subscriber subscription.

Table 15 lists the AVPs that the SAPC supports in a Ericsson SNR.

Table 15 SNR AVPs
AVP Name	AVP Code	Comment	Reference
`<Session-Id>`	263	-	RFC 6733
`{Auth-` `Application-Id}`	258	-	3GPP TS 29.219
`{Destination-` `Host}`	293	-	RFC 6733
`{Destination-` `Realm}`	283	-	RFC 6733
`*[Ericsson-` `Policy-Counter-` `Status-Report]`	1355	See Eric-Policy-Counter-Status-Report.	-
`[Experimental-` `Result]`	297	-	RFC 6733
`{Origin-Host}`	264	-	RFC 6733
`{Origin-Realm}`	296	-	RFC 6733
`*[Policy-Group]`	1347	See Policy-Group	-

6.4 Ericsson Spending-Status-Notification-Answer (SNA)

The SNA command, indicated by the Command-Code field set to 8388634 and the 'R' bit cleared in the Command Flags field, is sent by the SAPC to the OCS as part of the Spending Limit Report procedure. The Ericsson SNA message header contains Application-Id field set to 16777304 value.

Table 11 lists the AVPs that the SAPC sends in an Ericsson SNA message.

6.5 Ericsson Session-Termination-Request (STR)

The only difference in the content of Ericsson STR compared to standard STR (see Section 5.5) is that the message header contains Application-Id field set to 16777304 value.

6.6 Ericsson Session-Termination-Answer (STA)

The only difference in the content of Ericsson STA compared to standard STA (see Section Section 5.6) is that the message header contains Application-Id field set to 16777304 value.

7 Error Handling

When the SAPC detects an error at protocol or application level, it returns a response including the Result-Code AVP with an error code specifying the error.

7.1 Protocol Errors

The SAPC handles the following Diameter Base Protocol result codes:

Table 16 The SAPC Diameter Base Result Codes
Diameter Result Code	Value	Description
DIAMETER_SUCCESS	2001	A request is successfully completed.
DIAMETER_COMMAND_UNSUPPORTED	3001	A request contains a `Command-Code` that the SAPC does not recognized or support.
DIAMETER_UNABLE_TO_DELIVER	3002	An answer is received indicating that the OCS is not reachable.
DIAMETER_REALM_NOT_SERVED	3003	A request contains a destination realm not recognized.
DIAMETER_TOO_BUSY	3004	An answer is received indicating that the OCS cannot handle the request due to overload.
DIAMETER_LOOP_DETECTED	3005	A loop was detected while trying to get the received answer from the OCS.
DIAMETER_APPLICATION_UNSUPPORTED	3007	A request is received for an unsupported application.
DIAMETER_INVALID_HDR_BITS	3008	A request is received with a Diameter header whose bits are set to an invalid combination or to a value that is inconsistent with the `Command-Code` definition.
DIAMETER_INVALID_AVP_BITS	3009	A request is received with an AVP whose flag bits are set to an unrecognized value or are inconsistent with the AVPs definition.

7.2 Application Errors

The SAPC handles the following Gx Interface Application errors:

Table 17
Diameter Result Code	Value	Description
ELECTION_LOST	4003	The peer has determined that it has lost the election process and has therefore disconnected the transport connection.
DIAMETER_AVP_UNSUPPORTED	5001	A request is received with an AVP that is not recognized or supported (not included in the SAPC Diameter dictionary) and was marked with the Mandatory bit. A Diameter message with this error must contain one or more `Failed-AVP` AVP containing the AVPs that caused the failure.
DIAMETER_UNKNOWN_SESSION_ID	5002	Returned if the session does not exist for the UE IP address at session modification/termination.
DIAMETER_INVALID_AVP_VALUE	5004	A request is received with an AVP with an invalid value in its data portion. A Diameter message with this error must contain one or more `Failed-AVP` AVP containing the AVPs that caused the failure.
DIAMETER_MISSING_AVP	5005	When a request is received including an AVP that is not required to process that request, that AVP is ignored and the request is processed as usual. On the contrary, when a request does not include an AVP that is required to process such request, the SAPC returns a response including `Result-Code` DIAMETER_MISSING_AVP and the `Failed-AVP` AVP.
DIAMETER_AVP_NOT_ALLOWED	5008	A request is received with an AVP that must not be present. A Diameter message with this error must contain a `Failed-AVP` AVP with a copy of the offending AVP.
DIAMETER_AVP_OCCURS_TOO_MANY_TIMES	5009	A request is received with an AVP that appears more often than permitted in the message definition. A Diameter message with this error must contain a `Failed-AVP` AVP with a copy of the first instance of the offending AVP that exceeded the maximum number of occurrences.
DIAMETER_UNSUPPORTED_VERSION	5011	A request is received with an unsupported version number.
DIAMETER_UNABLE_TO_COMPLY	5012	This error is returned when the SAPC receives a request and detects an internal error which does not allow to continue processing a request.
DIAMATER_INVALID_BIT_IN_HEADER	5013	A request is received with an unrecognized bit in the Diameter header is set to one.
DIAMETER_INVALID_AVP_LENGTH	5014	A request is received containing an AVP with an invalid length. A Diameter message with this error must contain a `Failed-AVP` AVP containing the offending AVP.
DIAMETER_INVALID_MESSAGE_LENGTH	5015	A request is received with an invalid message length.
DIAMETER_INVALID_AVP_BIT_COMBO	5016	A request is received with an AVP which is not allowed to have the received value in the `AVP Flags` field. A Diameter message with this error must contain a `Failed-AVP` AVP containing the offending AVP.
DIAMETER_USER_UNKNOWN	5030	This error is used by the OCS in SLA, to indicate to the SAPC that the OCS does not known the subscriber specified in `Subscription-Id` AVP.

The SAPC handles the following Sy Interface Application errors, using Experimental-Result-Code AVP (where Vendor-IdAVP is set to 10415):

Table 18
Experimental-Result-Code within Experimental-Result	Value	Description
DIAMETER_ERROR_NO_AVAILABLE_POLICY_COUNTERS	4241	Used by the OCS to indicate to the SAPC that the OCS has no available policy counters for the subscriber.

Glossary

ABNF

Augmented Backus-Naur Form

AVP

Attribute Value Pair

IANA

Internet Assigned Numbers Authority

IETF

Internet Engineering Task Force

NTP

Network Time Protocol

OCS

Online Charging System

SAPC

Ericsson Service-Aware Policy Controller

SLA

Spending Limit Answer

SLR

Spending Limit Request

SNA

Spending-status Notification Answer

SNR

Spending-status Notification Request

STA

Session Termination Answer

STR

Session Termination Request

URI

Uniform Resource Identifiers

Reference List

Standard References
[1] Policy and Charging Control: Spending Limit Reporting over Sy reference point, 3GPP TS 29.219

Online References
[2] Diameter Base Protocol. http://www.ietf.org/rfc/rfc6733.txt?number=6733