A.7 S9a Protocol
29.2153GPPPolicy and Charging Control (PCC) over S9 reference pointRelease 17Stage 3TS
A.7.1 Protocol support
The S9a application is defined as a vendor specific Diameter application, where the vendor is 3GPP and the Application-ID for the S9a Application in the present release is 16777319. The vendor identifier assigned by IANA to 3GPP (http://www.iana.org/assignments/enterprise-numbers) is 10415.
NOTE: A route entry can have a different destination based on the application identification AVP of the message. Therefore, Diameter agents (relay, proxy, redirection, translation agents) must be configured appropriately to identify the 3GPP S9a application within the Auth-Application-Id AVP in order to create suitable routeing tables.
The S9a application identification shall be included in the Auth-Application-Id AVP.
A.7.2 Initialization, maintenance and termination of connection and session
The initialization and maintenance of the connection between each BPCF/(V-)PCRF pair is defined by the underlying protocol. Establishment and maintenance of connections between Diameter nodes is described in IETF RFC 6733 [29].
After establishing the transport connection, the BPCF and the (V-)PCRF shall advertise the support of the S9a specific Application by including the value of the application identifier in the Auth-Application-Id AVP and the value of the 3GPP (10415) in the Vendor-Id AVP of the Vendor-Specific-Application-Id AVP contained in the Capabilities‑Exchange-Request and Capabilities-Exchange-Answer commands. The Capabilities-Exchange-Request and Capabilities-Exchange-Answer commands are specified in the Diameter base protocol (IETF RFC 6733 [29]).
The termination of the Diameter S9a session over S9a reference point can be initiated by the (V-)PCRF, as specified in clause A.5.2.1.1.
A.7.3 S9a specific AVPs
A.7.3.1 General
Table A.7.3.1.1 describes the Diameter AVPs defined for the S9a Diameter application over S9a reference point, their AVP Code values, types, possible flag values, whether or not the AVP may be encrypted, what access types (e.g. 3GPP-GPRS, etc.) the AVP is applicable to, the applicability of the AVPs to charging control, policy control or both, and which supported features the AVP is applicable to. The Vendor-Id header of all AVPs defined in the present document shall be set to 3GPP (10415).
Table A.7.3.1.1: S9a specific Diameter AVPs
|
AVP Flag rules (NOTE 1) |
||||||||||
|
Attribute Name |
AVP Code |
Clause defined |
Value Type (NOTE 2) |
Must |
May |
Should not |
Must not |
May Encr. |
Acc. type (NOTE 3) |
Applicability |
|
PCRF-Address |
2207 |
A.7.3.1.1 |
DiameterIdentity |
V,M |
P |
Y |
PC EPC-routed |
|||
|
NOTE 1: The AVP header bit denoted as ‘M’, indicates whether support of the AVP is required. The AVP header bit denoted as ‘V’, indicates whether the optional Vendor-ID field is present in the AVP header. For further details, see IETF RFC 6733 [29]]. NOTE 2: The value types are defined in IETF RFC 6733 [29]. NOTE 3: S9a protocol applies only when the UE is making use of a fixed broadband access network. |
||||||||||
A.7.3.1.1 PCRF-Address
The PCRF-Address AVP (AVP code 2207) is of type DiameterIdentity and is used by the (V)-PCRF to indicate its own address in the TER command so that the BPCF can address the (V)-PCRF during the S9a session establishment procedure.
NOTE: The value in the Origin-Host AVP of the TER command can be replaced by the proxy agent between the (V)-PCRF and the BPCF.
A.7.4 S9a re-used AVPs
A.7.4.1 General
Table A.7.4.1.1 lists the Diameter AVPs re-used by the S9a reference point from other reference points (e.g. Gx, Gxx, S9 reference points) and other existing Diameter Applications, reference to their respective specifications, short description of their usage within the S9a reference point, the applicability of the AVPs to a specific access, and which supported features the AVP is applicable to. When reused from S9 reference point, the specific clause in the present specification is referred. Other AVPs from existing Diameter Applications, except for the AVPs from Diameter base protocol, do not need to be supported. The AVPs from Diameter base protocol are not included in table A.7.4.1.1, but they are re-used for the S9a reference point. Unless otherwise stated, re-used AVPs shall maintain their ‘M’, ‘P’ and ‘V’ flag settings. Where RADIUS VSAs are re-used, unless otherwise stated, they shall be translated to Diameter AVPs as described in IETF RFC 4005 [25] with the exception that the ‘M’ flag shall be set and the ‘P’ flag may be set.
Table A.7.4.1.1: S9a re-used Diameter AVPs
|
Attribute Name |
Reference |
Description |
Acc. type |
Applicability Note 1 |
|---|---|---|---|---|
|
Called-Station-Id |
IETF RFC 4005 [25] |
The address the user is connected to in the 3GPP network (i.e. the PDN identifier). For EPS the APN. When used to contain the APN, the APN is composed of the APN Network Identifier only, or the APN Network Identifier and the APN Operator Identifier as specified in TS 23.003 [9], clause 9.1. |
Non-3GPP-EPS 3GPP-EPS |
PC |
|
CC-Request-Number |
IETF RFC 4006 [19] |
The number of the request for mapping requests and answers |
Non-3GPP-EPS 3GPP-EPS |
PC |
|
CC-Request-Type |
IETF RFC 4006 [19] |
The type of the request (initial, update, termination) |
Non-3GPP-EPS 3GPP-EPS |
PC |
|
DRMP |
IETF RFC 7944 [27] |
Allows Diameter endpoints to indicate the relative priority of Diameter transactions. |
Non-3GPP-EPS 3GPP-EPS |
PC |
|
Event-Report-Indication |
TS 29.212 [3] |
When sent from the PCRF to the BPCF, it is used to report an event coming from the PCEF or BBERF and the relevant info to the BPCF. The following values for the included Event-Trigger are applicable: UE_LOCAL_IP_ADDRESS_CHANGE (43), H(E)NB_LOCAL_IP_ADDRESS_CHANGE (44). The following AVPs which are included in Event-Report-Indication are applicable to S9a interface: UE-Local-IP-Address, HeNB-Local-IP-Address and UDP-Source-Port. BPCF does not subscribe the notification of following event trigger values: UE_LOCAL_IP_ADDRESS_CHANGE, H(E)NB_LOCAL_IP_ADDRESS_CHANGE. |
Non-3GPP-EPS 3GPP-EPS (NOTE x) |
PC |
|
Load |
IETF RFC 8583 [28] |
The AVP used to convey load information between Diameter nodes. This AVP and all AVPs within this grouped AVP shall have the ‘M’ bit cleared. |
Non-3GPP-EPS 3GPP-EPS |
PC |
|
OC-OLR |
IETF RFC 7683 [24] |
Contains the necessary information to convey an overload report. |
Non-3GPP-EPS 3GPP-EPS |
PC |
|
OC-Supported-Features |
IETFRFC 7683 [24] |
Defines the support for the Diameter overload indication conveyence by the sending node. |
Non-3GPP-EPS 3GPP-EPS |
PC |
|
QoS-Information |
TS 29.212 [3] |
Defines the QoS information that can be accepted by the BPCF. |
Non-3GPP-EPS |
PC |
|
QoS-Rule-Install |
TS 29.212 [3] |
It is used to activate, install or modify QoS rules as instructed from the PCRF to the BPCF. Only QoS-Rule-Definition, QoS-Rule-Name, QoS-Rule-Base-Name , 3GPP-GGSN-Address, 3GPP-GGSN-IPv6-Address, AN-GW-Address and UDP-Source-Port are applicable. |
Non-3GPP-EPS 3GPP-EPS |
PC |
|
QoS-Rule-Remove |
TS 29.212 [3] |
It is used to deactivate or remove QoS rules in the BPCF. |
Non-3GPP-EPS 3GPP-EPS |
PC |
|
QoS-Rule-Report |
TS 29.212 [3] |
It is used to report the status of the QoS Rules. |
Non-3GPP-EPS 3GPP-EPS |
PC |
|
Session-Release-Cause |
TS 29.212 [3] |
Indicate the reason of termination initiated by the PCRF. |
Non-3GPP-EPS 3GPP-EPS |
PC |
|
Subscription-Id |
IETF RFC 4006 [19] |
The identification of the subscription (i.e. IMSI) |
Non-3GPP-EPS |
PC |
|
Supported-Features |
TS 29.229 [7] |
If present, this AVP informs the destination host about the features that the origin host requires to successfully complete this command exchange |
Non-3GPP-EPS 3GPP-EPS |
PC |
|
HeNB-Local-IP-Address |
TS 29.212 [3] |
Contains the H(e)NB local IP address |
3GPP-EPS |
PC |
|
UE-Local-IP-Address |
TS 29.212 [3] |
Contains the UE local IP address |
Non-3GPP-EPS |
PC |
|
UDP-Source-Port |
TS 29.212 [3] |
Contains the UDP source port number in the case that NA(P)T is detected for supporting interworking with Fixed Broadband access network |
Non-3GPP-EPS 3GPP-EPS |
PC |
|
NOTE 1: AVPs marked with “PC” are applicable to policy control. NOTE 2: Event trigger value UE_LOCAL_IP_ADDRESS_CHANGE, UE-Local-IP-Address AVP and UDP-Source-Port AVP are applicable to the Non-3GPP-EPS. Event trigger value H(E)NB_LOCAL_IP_ADDRESS_CHANGE, H(e)NB-Local-IP-Address AVP and UDP-Source-Port AVP are applicable to the 3GPP-EPS. |
||||
A.7.5 S9a specific Experimental-Result-Code AVP values
A.7.5.1 General
IETF RFC 6733 [29] specifies the Experimental-Result AVP containing Vendor-ID AVP and Experimental-Result-Code AVP. 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).
A.7.5.2 Success
Result Codes that fall within the Success category are used to inform a peer that a request has been successfully completed.
The Result-Code AVP values defined in Diameter base protocol, IETF RFC 6733 [29], shall be applied.
A.7.5.3 Permanent Failures
Errors that fall within the Permanent Failures category shall be used to inform the peer that the request failed, and should not be attempted again.
The Result-Code AVP values defined in Diameter base protocol, IETF RFC 6733 [29], and 3GPP TS 29.212 [3] are applicable.
A.7.5.4 Transient Failures
Errors that fall within the transient failures category are used to inform a peer that the request could not be satisfied at the time it was received, but may be able to satisfy the request in the future.
No transient failure is identified in this release.
A.7.6 S9a Messages
A.7.6.1 S9a Application
S9a Messages are carried within the Diameter Application(s) described in clause A.7.1.
Existing Diameter command codes from the Diameter base protocol, IETF RFC 6733 [29], and the Diameter Credit Control Application, IETF RFC 4006 [19], are used with the S9a specific AVPs specified in clause A.7.3. The Diameter Credit Control Application AVPs and AVPs from other Diameter applications that are re-used are defined in clause A.7.4. The S9a application identifier shall be included in the Auth-Application-Id AVP.
NOTE: Some of the AVPs included in the messages formats below are in bold to highlight that these AVPs are used by this specific protocol and do not belong to the original message definition in the DCC Application, IETF RFC 4006 [19], or Diameter base protocol, IETF RFC 6733 [29].
A.7.6.2 CC-Request (CCR) Command
The CCR command, indicated by the Command-Code field set to 272 and the ‘R’ bit set in the Command Flags field, is sent by the BPCF to the PCRF in order to initiate an S9a session establishment and to request QoS rules. The CCR command is also sent by the BPCF to the PCRF in order to indicate QoS rule related events.
Message Format:
<CC-Request> ::= < Diameter Header: 272, REQ, PXY >
< Session-Id >
[ DRMP ]
{ Auth-Application-Id }
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ CC-Request-Type }
{ CC-Request-Number }
[ Destination-Host ]
[ Origin-State-Id ]
[ Subscription-Id ]
[ Called-Station-Id ]
[ OC-Supported-Features ]
*[ Supported-Features ]
[ QoS-Information ]
*[ QoS-Rule-Report ]
[ UE-Local-IP-Address ]
[ HeNB-Local-IP-Address ]
[ Termination-Cause ]
*[ Proxy-Info ]
*[ Route-Record ]
*[ AVP ]
A.7.6.3 CC-Answer (CCA) Command
The CCA command, indicated by the Command-Code field set to 272 and the ‘R’ bit cleared in the Command Flags field, is sent by the PCRF to the BPCF in response to the CCR command. It is used to provision QoS rules for the S9a session
Message Format:
<CC-Answer> ::= < Diameter Header: 272, PXY >
< Session-Id >
[ DRMP ]
{ Auth-Application-Id }
{ Origin-Host }
{ Origin-Realm }
[ Result-Code ]
[ Experimental-Result ]
{ CC-Request-Type }
{ CC-Request-Number }
[ OC-Supported-Features ]
[ OC-OLR ]
*[ Supported-Features]
*[ QoS-Rule-Install ]
*[ QoS-Rule-Remove ]
[ Event-Report-Indication ]
[ Origin-State-Id ]
[ Error-Message ]
[ Error-Reporting-Host ]
[ Failed-AVP ]
*[ Proxy-Info ]
*[ Route-Record ]
*[ Load ]
*[ AVP ]
A.7.6.4 Re-Authorization-Request (RAR) Command
The RAR command, indicated by the Command-Code field set to 258 and the ‘R’ bit set in the Command Flags field, is sent by the PCRF to the BPCF in order to provision QoS rules and address information for the S9a session.
Message Format:
<RA-Request> ::= < Diameter Header: 258, REQ, PXY >
< Session-Id >
[ DRMP ]
{ Auth-Application-Id }
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ Destination-Host }
{ Re-Auth-Request-Type }
[ Origin-State-Id ]
[ OC-Supported-Features ]
*[ QoS-Rule-Install ]
*[ QoS-Rule-Remove ]
[ Event-Report-Indication ]
[ Session-Release-Cause ]
*[ Proxy-Info ]
*[ Route-Record ]
*[ AVP ]
A.7.6.5 Re-Authorization-Answer (RAA) Command
The RAA command, indicated by the Command-Code field set to 258 and the ‘R’ bit cleared in the Command Flags field, is sent by the BPCF to the PCRF in response to the RAR command.
Message Format:
<RA-Answer> ::= < Diameter Header: 258, PXY >
< Session-Id >
[ DRMP ]
{ Origin-Host }
{ Origin-Realm }
[ Result-Code ]
[ Experimental-Result ]
[ Origin-State-Id ]
[ OC-Supported-Features ]
[ OC-OLR ]
[ QoS-Information ]
*[ QoS-Rule-Report ]
[ Error-Message ]
[ Error-Reporting-Host ]
[ Failed-AVP ]
*[ Proxy-Info ]
*[ Load ]
*[ AVP ]
A.7.6.6 Trigger-Establishment-Request (TER) Command
The TER command, indicated by the Command-Code field set to 8388656 and the ‘R’ bit set in the Command Flags field, is sent by the PCRF to the BPCF in order to trigger the S9a Session Establishment.
Message Format:
<TE-Request> ::= < Diameter Header: 8388656, REQ, PXY >
< Session-Id >
[ DRMP ]
{ Auth-Application-Id }
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ Destination-Host }
[ Auth-Session-State ]
[ Origin-State-Id ]
[ OC-Supported-Features ]
[ Subscription-Id ]
[ Called-Station-Id ]
[ PCRF-Address ]
[ UE-Local-IP-Address ]
[ HeNB-Local-IP-Address ]
[ UDP-Source-Port ]
*[ Proxy-Info ]
*[ Route-Record ]
*[ AVP ]
A.7.6.7 Trigger-Establishment-Answer (TEA) Command
The TEA command, indicated by the Command-Code field set to 8388656 and the ‘R’ bit cleared in the Command Flags field, is sent by the BPCF to the PCRF in response to the TER command.
Message Format:
<TE-Answer> ::= < Diameter Header: 8388656, PXY >
< Session-Id >
[ DRMP ]
{ Origin-Host }
{ Origin-Realm }
[ Result-Code ]
[ Experimental-Result ]
[ Origin-State-Id ]
[ OC-Supported-Features ]
[ OC-OLR ]
[ Error-Message ]
[ Error-Reporting-Host ]
[ Failed-AVP ]
*[ Proxy-Info ]
*[ Load ]
*[ AVP ]