6 Protocol Specification
29.3363GPPHome Subscriber Server (HSS) diameter interfaces for interworking with packet data networks and applicationsRelease 18TS
6.1 Introduction
6.1.1 Use of Diameter Base Protocol
The Diameter base protocol as specified in IETF RFC 6733 [23] shall apply except as modified by the defined support of the methods and the defined support of the commands and AVPs, result and error codes as specified in this specification. Unless otherwise specified, the procedures (including error handling and unrecognised information handling) shall be used unmodified.
6.1.2 Securing Diameter Messages
For secure transport of Diameter messages, see 3GPP TS 33.210 [4].
6.1.3 Accounting Functionality
Accounting functionality (Accounting Session State Machine, related command codes and AVPs) shall not be used on the S6m interface.
6.1.4 Use of Sessions
Between the MTC-IWF and the HSS, Diameter sessions shall be implicitly terminated. An implicitly terminated session is one for which the server does not maintain state information. The client shall not send any re-authorization or session termination requests to the server.
The Diameter base protocol as specified in IETF RFC 6733 [23] includes the Auth-Session-State AVP as the mechanism for the implementation of implicitly terminated sessions.
The client (server) shall include in its requests (responses) the Auth-Session-State AVP set to the value NO_STATE_MAINTAINED (1), as described in IETF RFC 6733 [23]. As a consequence, the server shall not maintain any state information about this session and the client shall not send any session termination request. Neither the Authorization-Lifetime AVP nor the Session-Timeout AVP shall be present in requests or responses.
6.1.5 Transport Protocol
Diameter messages over the S6m interface shall make use of SCTP IETF RFC 4960 [5] as transport protocol.
6.1.6 Routing Considerations
This clause specifies the use of the Diameter routing AVPs Destination-Realm and Destination-Host.
The S6m reference point is defined as an intra-operator interface so, both MTC-IWF and HSS shall be located in the same network domain/realm.
If the MTC-IWF knows the address/name of the HSS for a certain user, both the Destination-Realm AVP and the Destination-Host AVP shall be present in the request. Otherwise, only the Destination-Realm AVP shall be present and the command shall be routed to the next Diameter node. Consequently, the Destination-Host AVP is declared as optional in the ABNF for all requests initiated by the MTC-IWF.
Destination-Realm AVP is declared as mandatory in the ABNF for all requests.
I If the Vendor-Specific-Application-ID AVP is received in any of the commands, it shall be ignored by the receiving node, and it shall not be used for routing purposes.
6.1.7 Advertising Application Support
The HSS and the MTC-IWF shall advertise support of the Diameter S6m Application by including the value of the 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.
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.
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].
6.1.8 Diameter Application Identifier
The S6m/S6n interface protocol shall be defined as an IETF vendor specific Diameter application, where the vendor is 3GPP. The vendor identifier assigned by IANA to 3GPP (http://www.iana.org/assignments/enterprise-numbers) is 10415.
The Diameter application identifier assigned to the S6m interface application is 16777310 (allocated by IANA).
6.1.9 Use of the Supported-Features AVP
When new functionality is introduced on the S6m application, it should be defined as optional. If backwards incompatible changes can not be avoided, the new functionality shall be introduced as a new feature and support advertised with the Supported-Features AVP. The usage of the Supported-Features AVP on the S6m application is consistent with the procedures for the dynamic discovery of supported features as defined in clause 7.2 of 3GPP TS 29.229 [7].
When extending the application by adding new AVPs for a feature, the new AVPs shall have the M bit cleared and the AVP shall not be defined mandatory in the command ABNF.
As defined in 3GPP TS 29.229 [7], the Supported-Features AVP is of type grouped and contains the Vendor-Id, Feature-List-ID and Feature-List AVPs. On the all reference points as specified in this specification, the Supported-Features AVP is used to identify features that have been defined by 3GPP and hence, for features defined in this document, the Vendor-Id AVP shall contain the vendor ID of 3GPP (10415). If there are multiple feature lists defined for the reference point, the Feature-List-ID AVP shall differentiate those lists from one another.
6.1.10 User Identity to HSS resolution
The User identity to HSS resolution mechanism enables the MTC-IWF to find the identity of the HSS that holds the subscription data for the target user when multiple and separately addressable HSSs have been deployed in the home network. The resolution mechanism is not required in networks that utilise a single HSS.
This User identity to HSS resolution mechanism may rely on routing capabilities provided by Diameter and be implemented in the home operator network within dedicated Diameter Agents (Redirect Agents or Proxy Agents) responsible for determining the HSS identity based on the provided user identity (e.g., external identifiers provided by the MTC-IWF).
When the Diameter Load Control mechanism is supported (see IETF RFC 8583 [22]), load values from previously received Load AVPs of type HOST may be taken into account when determining the HSS identity.
NOTE: Alternatives to the user identity to HSS resolution Diameter based implementation are outside the scope of this specification.
6.2 Commands
6.2.1 Introduction
This clause defines the Command code values and related ABNF for each command described in this specification.
6.2.2 Command-Code values
This clause defines Command-Code values for the S6m/S6n interface application as allocated by IANA.
Every command is defined by means of the ABNF syntax IETF RFC 5234 [9], according to the Command Code Format (CCF) specification defined in IETF RFC 6733 [23]. When the definition and use of an AVP is not specified in this document, the guidelines in IETF RFC 6733 [23] shall apply.
The Vendor-Specific-Application-Id AVP shall not be included in any command sent by Diameter nodes supporting applications defined in this specification. If the Vendor-Specific-Application-Id AVP is received in any of the commands defined in this specification, it shall be ignored by the receiving node.
NOTE: The Vendor-Specific-Application-Id is included as an optional AVP in all Command Code Format specifications defined in this specification in order to overcome potential interoperability issues with intermediate Diameter agents non-compliant with the IETF RFC 6733 [23].
The following Command Codes are defined in this specification:
Table 6.2.2/1: Command-Code values for S6m/S6n
|
Command-Name |
Abbreviation |
Code |
Clause |
|
Subscriber-Information-Request |
SIR |
8388641 |
6.2.3 |
|
Subscriber-Information-Answer |
SIA |
8388641 |
6.2.4 |
For these commands, the Application-ID field shall be set to 16777310 (application identifier of the S6m/S6n interface application, allocated by IANA).
6.2.3 Subscriber-Information-Request (SIR) Command
The Subscriber-Information-Request (SIR) command, indicated by the Command-Code field set to 8388641 and the "R" bit set in the Command Flags field, is sent from the MTC-IWF to the HSS or from the MTC-AAA to the HSS.
Message Format:
< Subscriber-Information-Request> ::= < Diameter Header: 8388641, REQ, PXY, 16777310 >
< Session-Id >
[ DRMP ]
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
[ Destination-Host ]
{ Destination-Realm }
{ User-Identifier }
[ Service-ID ]
[ SCS-Identity ]
[ Service-Parameters ]
{ SIR-Flags }
[ OC-Supported-Features ]
*[ Supported-Features ]
*[ Proxy-Info ]
*[ Route-Record ]
*[ AVP ]
6.2.4 Subscriber-Information-Answer (SIA) Command
The Subscriber-Information-Answer (SIA) command, indicated by the Command-Code field set to 8388641 and the "R" bit cleared in the Command Flags field, is sent from the HSS to the MTC-IWF or from the HSS to the MTC-AAA.
Message Format:
< Subscriber-Information-Answer> ::= < Diameter Header: 8388641, PXY, 16777310 >
< Session-Id >
[ DRMP ]
[ Result-Code ]
[ Experimental-Result ]
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
[ OC-Supported-Features ]
[ OC-OLR ]
*[ Load ]
*[ Supported-Features ]
*[ User-Identifier ]
[ Service-Data ]
[ Failed-AVP ]
*[ Proxy-Info ]
*[ Route-Record ]
*[ AVP ]
6.3 Result-Code AVP and Experimental-Result AVP Values
6.3.1 General
This clause defines result code values that shall be supported by all Diameter implementations that conform to this specification.
6.3.2 Success
Result codes that fall within the Success category shall be used to inform a peer that a request has been successfully completed. The Result-Code AVP values defined in Diameter base protocol as specified in IETF RFC 6733 [23] shall be applied.
6.3.3 Permanent Failures
Errors that fall within the Permanent Failures category shall be used to inform the peer that the request has failed, and should not be attempted again. The Result-Code AVP values defined in Diameter base protocol as specified in IETF RFC 6733 [23] shall be applied. When one of the result codes defined here is included in a response, it shall be inside an Experimental-Result AVP and the Result-Code AVP shall be absent.
6.3.3.1 DIAMETER_ERROR_USER_UNKNOWN (5001)
This result code shall be sent by the HSS to indicate that the user identified by the IMSI, MSISDN, or External-Identifier is unknown. This error code is defined in 3GPP TS 29.229 [7].
6.3.3.2 DIAMETER_ERROR_UNAUTHORIZED_REQUESTING_ENTITY (5510)
This result code shall be sent by the HSS to indicate that the SCS is not allowed to request control plane services for an UE, to the MTC-IWF.
6.3.3.3 DIAMETER_ERROR_UNAUTHORIZED_SERVICE (5511)
This result code shall be sent by the HSS to indicate that the specific service requested by the SCS is not allowed for an UE, or that it cannot be delivered according to the current subscribed services of the UE.
6.4 AVPs
6.4.1 General
The following table specifies the Diameter AVPs defined for the S6m/S6n interface protocol, their AVP Code values, types, possible flag values and whether or not the AVP may be encrypted. The Vendor-ID header of all AVPs defined in this specification shall be set to 3GPP (10415).
For all AVPs which contain bit masks and are of the type Unsigned32, bit 0 shall be the least significant bit. For example, to get the value of bit 0, a bit mask of 0x00000001 should be used.
Table 6.4.1/1: S6m/S6n specific Diameter AVPs
|
AVP Flag rules |
||||||||
|---|---|---|---|---|---|---|---|---|
|
Attribute Name |
AVP Code |
Clause defined |
Value Type |
Must |
May |
Should not |
Must not |
May Encr. |
|
IP-SM-GW-Number |
3100 |
6.4.14 |
OctetString |
M,V |
No |
|||
|
IP-SM-GW-Name |
3101 |
6.4.15 |
DiameterIdentity |
M,V |
No |
|||
|
User-Identifier |
3102 |
6.4.2 |
Grouped |
M,V |
No |
|||
|
Service-ID |
3103 |
6.4.3 |
Enumerated |
M,V |
No |
|||
|
SCS-Identity |
3104 |
6.4.4 |
OctetString |
M,V |
No |
|||
|
Service-Parameters |
3105 |
6.4.5 |
Grouped |
M,V |
No |
|||
|
T4-Parameters |
3106 |
6.4.6 |
Grouped |
M,V |
No |
|||
|
Service-Data |
3107 |
6.4.7 |
Grouped |
M,V |
No |
|||
|
T4-Data |
3108 |
6.4.8 |
Grouped |
M,V |
No |
|||
|
HSS-Cause |
3109 |
6.4.9 |
Unsigned32 |
M,V |
No |
|||
|
SIR-Flags |
3110 |
6.4.10 |
Unsigned32 |
M,V |
No |
|||
|
External-Identifier |
3111 |
6.4.11 |
UTF8String |
M,V |
No |
|||
|
IP-SM-GW-Realm |
3112 |
6.4.18 |
DiameterIdentity |
M,V |
No |
|||
|
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 [23]. NOTE 2: If the M-bit is set for an AVP and the receiver does not understand the AVP, it shall return a rejection. If the M-bit is not set for an AVP, the receiver shall not return a rejection, whether or not it understands the AVP. If the receiver understands the AVP but the M-bit value does not match with the definition in this table, the receiver shall ignore the M-bit. |
||||||||
The following table specifies the Diameter AVPs re-used by the S6m/S6n interface protocol from existing Diameter Applications, including a reference to their respective specifications and when needed, a short description of their use within S6m/S6n.
Any other AVPs from existing Diameter Applications, except for the AVPs from Diameter base protocol as specified in IETF RFC 6733 [23], do not need to be supported. The AVPs from Diameter base protocol as specified in IETF RFC 6733 [23] are not included in table 6.4.1/2, but they may be re-used for the S6m/S6n protocol.
Table 6.4.1/2: S6m/S6n re-used Diameter AVPs
|
Attribute Name |
Reference |
Comments |
|---|---|---|
|
User-Name |
IETF RFC 6733 [23] |
This AVP shall contain the IMSI of the UE, in the User-Identifier AVP. |
|
MSISDN |
3GPP TS 29.329 [10] |
|
|
LMSI |
3GPP TS 29.173 [8] |
|
|
Serving-Node |
3GPP TS 29.173 [8] |
see 6.4.12 |
|
Additional-Serving-Node |
3GPP TS 29.173 [8] |
see 6.4.13 |
|
Supported-Features |
3GPP TS 29.229 [7] |
|
|
Feature-List-ID |
3GPP TS 29.229 [7] |
|
|
Feature-List |
3GPP TS 29.229 [7] |
|
|
SM-RP-SMEA |
3GPP TS 29.338 [12] |
|
|
Priority-Indication |
3GPP TS 29.368 [13] |
|
|
MME-Number-for-MT-SMS |
3GPP TS 29.272 [14] |
|
|
OC-Supported-Features |
IETF RFC 7683 [15] |
See 6.4.16 |
|
OC-OLR |
IETF RFC 7683 [15] |
See 6.4.17 |
|
DRMP |
IETF RFC 7944 [20] |
see clause 6.4.19 |
|
Application-Port-Identifier |
3GPP TS 29.368 [13] |
|
|
Load |
IETF RFC 8583 [22] |
See 6.4.20 |
6.4.2 User-Identifier
The User-Identifier AVP is of type Grouped and it contains the different identifiers used by the UE.
AVP format:
User-Identifier ::= <AVP header: 3102 10415>
[ User-Name ]
[ MSISDN ]
[ External-Identifier ]
[ LMSI ]
*[AVP]
This AVP shall contain at least one of the identifiers used by the UE, i.e., it shall not be empty. The IMSI of the UE shall be included (when applicable) in the User-Name AVP.
6.4.3 Service-ID
The Service-ID AVP is of type Enumerated and it shall identify the service requested by the SCS. The following values are defined:
DEVICE_TRIGGER (0)
The SCS requests a control plane device triggering to the UE. .
SMS_MO (1)
The UE (identified by IMSI and application port identifier) requests SMS_MO to be delivered to the SCS.
6.4.4 SCS-Identity
The SCS-Identity AVP is of type OctetString and it shall contain the identity of the SCS or UE which originated the service request towards the MTC-IWF, over the Tsp reference point.
The encoding of the SCS-Identity AVP is defined per SCS service.
For the device triggering service, the SCS-Identity AVP shall contain the ISDN number of the SCS in international ISDN number format as described in ITU-T Rec E.164 [41]. It shall be encoded as a TBCD-string. See 3GPP TS 29.002 [24] for encoding of TBCD-strings. This AVP shall not include leading indicators for the nature of address and the numbering plan.
6.4.5 Service-Parameters
The Service-Parameters AVP is of type Grouped, and it contains the service-specific parameters related to the requested service.
AVP format:
Service-Parameters ::= <AVP header: 3105 10415>
[ T4-Parameters ]
[ Application-Port-Identifier ]
*[AVP]
6.4.6 T4-Parameters
The T4-Parameters AVP is of type Grouped.
AVP format:
T4-Parameters ::= <AVP header: 3106 10415>
[ Priority-Indication ]
[ SM-RP-SMEA ]
*[AVP]
6.4.7 Service-Data
The Service-Data AVP is of type Grouped, and it contains the service-specific data related to the device triggering request handled by the MTC-IWF.
Service-Data ::= <AVP header: 3107 10415>
[ T4-Data ]
*[AVP]
6.4.8 T4-Data
The T4-Data AVP is of type Grouped and it shall contain information about the network node(s) serving the targeted user for SMS, i.e. the names/numbers of the serving nodes (MSC or MME, SGSN, IP-SM-GW) which allow the trigger delivery. AVP format:
T4-Data ::= <AVP header: 3108 10415>
[ HSS-Cause ]
[ Serving-Node ]
*[ Additional-Serving-Node ]
*[AVP]
When the HSS-Cause indicates Absent Subscriber, via the corresponding flag in the bit mask, the Serving-Node and Additional-Serving-Node AVPs shall not be present. When the HSS-Cause indicates Teleservice Not Provisioned or Call Barred, via the corresponding flag in the bit mask, the Serving-Node and Additional-Serving-Node AVPs should not be present. Additional-Serving-Node AVP shall be absent if Serving-Node AVP is absent.
6.4.9 HSS-Cause
The HSS-Cause AVP is of type Unsigned32 and it contains a bit mask. The meaning of the bits is defined in table 6.4.9/1:
Table 6.4.9/1: HSS-Cause
|
Bit |
Name |
Description |
|
0 |
Absent Subscriber |
This bit, when set, indicates that there is no serving node registered in the HSS over which the corresponding triggering method should be immediately attempted for the user. NOTE 1. |
|
1 |
Teleservice Not Provisioned |
This bit, when set, indicates that the required teleservice(s) for the corresponding triggering method are not provisioned in the HSS/HLR for the user. |
|
2 |
Call Barred |
This bit, when set, indicates that the user has an active barring condition which makes it impossible to deliver the corresponding triggering method. |
|
NOTE 1: This may be caused because there is not any serving node currently registered in HSS for the user, or because the user is known to be absent in all suitable registered serving nodes (based on MNRF, MNRG and UNRI flags) and the trigger delivery is requested with "non-priority". NOTE 2: Bits not defined in this table shall be cleared by the HSS and discarded by the receiving node, MTC-IWF. |
||
6.4.10 SIR-Flags
The SIR-Flags AVP is of type Unsigned32 and it contains a bit mask. The meaning of the bits is defined in table 6.4.10/1:
Table 6.4.10/1: SIR-Flags
|
bit |
name |
Description |
|
0 |
S6m/S6n Indicator |
This bit, when set, indicates that the SIR message is sent on the S6m interface, i.e. the source node is an MTC-IWF. This bit, when cleared, indicates that the SIR message is sent on the S6n interface, i.e. the source node is an MTC-AAA. |
|
Note: Bits not defined in this table shall be cleared by the sending node, MTC-IWF or MTC-AAA, and discarded by the receiving HSS. |
||
6.4.11 External-Identifier
The External-Identifier AVP is of type UTF8String. For S6m/S6n interface it shall contain an external identifier of the UE. See 3GPP TS 23.003 [11] for the definition and formatting of the External Identifier. For S6t interface, it shall contain an external identifier for an individual UE or a group of UEs, as indicated by Type-Of-External-Identifier AVP. See 3GPP TS 23.003 [11] for the definition and formatting of the External Group Identifier.
6.4.12 Serving-Node
The Serving-Node AVP is of type Grouped and it shall contain the name/number of the serving node to be used for T4-triggering. It is originally defined in 3GPP TS 29.173 [8].
Serving-Node ::= <AVP header: 2401 10415>
[ SGSN-Name ]
[ SGSN-Realm ]
[ SGSN-Number ]
[ MME-Name ]
[ MME-Realm ]
[ MME-Number-for-MT-SMS ]
[ MSC-Number ]
[ IP-SM-GW-Number ]
[ IP-SM-GW-Name ]
[ IP-SM-GW-Realm ]
*[AVP]
The following combinations are allowed:
a) SGSN-Number
b) SGSN-Name & SGSN-Realm & SGSN-Number if the HSS supports the "Gdd in SGSN" feature and has received the "Gdd in SGSN" indication over S6a or Gr interface from the SGSN (cf. 3GPP TS 29.272 [4] and 3GPP TS 29.002 [9])
c) MME-Name & MME-Realm & MME-Number-for-MT-SMS
d) MSC-Number
e) MSC-Number & MME-Name & MME-Realm
f) IP-SM-GW-Number
g) IP-SM-GW-Number & IP-SM-GW-Name & IP-SM-GW-Realm
6.4.13 Additional-Serving-Node
The Additional-Serving-Node AVP is of type Grouped and when present it shall contain the name/number of an additional serving node to be used for T4-triggering. It is originally defined in 3GPP TS 29.173 [8],
Additional-Serving-Node ::= <AVP header: 2406 10415>
[ SGSN-Name ]
[ SGSN-Realm ]
[ SGSN-Number ]
[ MME-Name ]
[ MME-Realm ]
[ MME-Number-for-MT-SMS ]
[ MSC-Number ]
*[AVP]
The following combinations are allowed:
a) SGSN-Number
b) SGSN-Name & SGSN-Realm & SGSN-Number if the HSS supports the "Gdd in SGSN" feature and has received the "Gdd in SGSN" indication over S6a or Gr interface from the SGSN (cf. 3GPP TS 29.272 [4] and 3GPP TS 29.002 [9])
c) MME-Name & MME-Realm & MME-Number-for-MT-SMS
d) MSC-Number
e) MSC-Number & MME-Name & MME-Realm
6.4.14 IP-SM-GW-Number
The IP-SM-GW-Number AVP is of type OctetString and it shall contain the ISDN number of the IP-SM-GW in international number format as described in ITU-T Rec E.164 [41]. It shall be encoded as a TBCD-string. See 3GPP TS 29.002 [24] for encoding of TBCD-strings. This AVP shall not include leading indicators for the nature of address and the numbering plan.
6.4.15 IP-SM-GW-Name
The IP-SM-GW-Name AVP is of type DiameterIdentity and it shall contain the Diameter identity of the registered IP-SM-GW. For further details on the encoding of this AVP, see IETF RFC 3588 [5].
6.4.16 OC-Supported-Features
The OC-Supported-Features AVP is of type Grouped and it is defined in IETF RFC 7683 [15]. This AVP is used to support Diameter overload control mechanism, see Annex A for more information.
6.4.17 OC-OLR
The OC-OLR AVP is of type Grouped and it is defined in IETF RFC 7683 [15]. This AVP is used to support Diameter overload control mechanism, see Annex A for more information.
6.4.18 IP-SM-GW-Realm
The IP-SM-GW-Realm AVP is of type DiameterIdentity and it shall contain the Diameter identity of the registered IP-SM-GW’s realm. For further details on the encoding of this AVP, see IETF RFC 3588 [5].
6.4.19 DRMP
The DRMP AVP is of type Enumerated and it is defined in IETF RFC 7944 [20]. This AVP allows the HSS and the MTC-IWF over the S6m interface and the HSS and the MTC-AAA over the S6n interface to indicate the relative priority of Diameter messages. The DRMP AVP may be used to set the DSCP marking for transport of the associated Diameter message.
6.4.20 Load
The Load AVP is of type Grouped and it is defined in IETF RFC 8583 [22]. This AVP is used to support the Diameter load control mechanism.