Sy Interface Description

Ericsson Service-Aware Policy Controller

1 Sy Interface Overview

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

3GPP Sy is built over Diameter Base Protocol RFC. The SAPC supports 3GPP Sy from Rel11 onwards.

For detailed support about 3GPP Release versions of Policy and Charging Control: Spending Limit Reporting over Sy reference point - 3GPP TS 29.219, 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.

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 Rel13, Rel14 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, it is explicitly indicated in this document.

2 Sy Interface Message Exchange

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

Figure 1 Sy Interface Message 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, so it is not necessary to contact the OCS again.

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.

3 Diameter Base Protocol Messages

3.1 Sy Capability Negotiation

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

Table 1 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	According to configuration, 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	According to configuration, 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 2 lists the AVPs that the SAPC support in a CEA message.

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

3.2 Device Watchdog

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

Table 3 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 4 lists the AVPs that the SAPC can receive or send in a DWA message.

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

3.3 Disconnect Peer

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

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

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

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

4 Sy Interface Message Format

4.1 Sy Spending-Limit-Request (SLR)

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

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

4.2 Sy Spending-Limit-Answer (SLA)

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

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

4.3 Sy Spending-Status-Notification-Request (SNR)

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

Table 9 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
`{ Origin-Host }`	264	-	RFC 6733
`{ Origin-Realm }`	296	-	RFC 6733
`* [ Policy-Counter-Status-Report ]`	2903	See Policy-Counter-Status-Report.	3GPP TS 29.219

4.4 Sy Spending-Status-Notification-Answer (SNA)

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

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

4.5 Sy Session-Termination-Request (STR)

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

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

4.6 Sy Session-Termination-Answer (STA)

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

5 Ericsson Sy Message Format

This section contains the information about Ericsson Sy interface.

5.1 Ericsson Sy 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 12 lists the AVPs that the SAPC sends in an Ericsson SLR message.

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

5.2 Ericsson Sy 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 13 lists the AVPs that the SAPC supports in an Ericsson SLA message.

Table 13 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 a specific Policy Group, the `Ericsson-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. `[ Ericsson-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).

5.3 Ericsson Sy 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 14 lists the AVPs that the SAPC supports in an Ericsson SNR.

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

5.4 Ericsson Sy 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 10 lists the AVPs that the SAPC sends in an Ericsson SNA message.

5.5 Ericsson Sy Session-Termination-Request (STR)

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

5.6 Ericsson Sy Session-Termination-Answer (STA)

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

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

6.1 Sy Protocol Errors

The SAPC handles the following Diameter Base Protocol result codes:

Table 15 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. A notification is received when the SAPC is overloaded.
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.

6.2 Sy Application Errors

The SAPC handles the following Gx Interface Application errors:

Table 16 Gx Interface Application Errors
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 a `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 a `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-Id AVP is set to 10415):

Table 17 Sy Interface Application Errors
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.

7 Reference List

Standard References

Policy and Charging Control: Spending Limit Reporting over Sy reference point, 3GPP TS 29.219

Online References

Diameter Base Protocol, IETF RFC 6733

Copyright	© Ericsson AB 2018. All rights reserved. No part of this document may be reproduced in any form without the written permission of the copyright owner.
Disclaimer	The contents of this document are subject to revision without notice due to continued progress in methodology, design and manufacturing. Ericsson shall have no liability for any error or damage of any kind resulting from the use of this document.
Trademarks	All trademarks mentioned herein are the property of their respective owners. These are shown in the document Trademark Information.