5 Diameter based S6c interface between HSS and central SMS functions
29.3383GPPDiameter based protocols to support Short Message Service (SMS) capable Mobile Management Entities (MMEs)Release 18TS
5.1 Introduction
The S6c interface enables the retrieval of routing information for the transfer of short messages, the report of status of the delivery status of a short message and the alerting of the SMS-SC between the HSS, the SMS-GMSC and the SMS Router as described in 3GPP TS 23.040 [3].
5.2 Procedures description
5.2.1 Send Routing Info for SM procedure
5.2.1.1 General
This procedure shall be used between the SMS-GMSC or the IP-SM-GW and the HSS to retrieve the routing information needed for routing the short message to the serving MSC or MME or SGSN or SMSF. This procedure is also used between the SMS-GMSC and the SMS Router or the IP-SM-GW, and between the HSS and the SMS Router or the IP-SM-GW in order to enforce routing of the SM delivery via the HPLMN of the receiving MS.
This procedure is applicable to an IP-SM-GW for its SMS Router function when using the S6c interface.
This procedure is used according to the call flows described in 3GPP TS 23.040 [2] clause 10.
Table 5.2.1.1-1 specifies the involved information elements for the request.
Table 5.2.1.1-2 specifies the involved information elements for the answer.
This procedure is mapped to the commands Send-Routing-Info-for-SM-Request/Answer (SRR/SRA) in the Diameter application specified in clause 5.3.2.
Table 5.2.1.1-1: Send Routing Info for SM Request
|
Information element name |
Mapping to Diameter AVP |
Cat. |
Description |
|
MSISDN |
MSISDN |
C |
This information element shall be present when the MSISDN exists and shall contain the MSISDN of the user. |
|
IMSI |
User-Name (See IETF RFC 6733 [20]) |
C |
This information element shall be present when the MSISDN does not exist and shall contain – the IMSI of the user in the context of T4 device triggering (see 3GPP TS 23.682 [18]; – or the HSS ID value in the context of MSISDN-less SMS delivery in IMS (see 3GPP TS 23.204 [17]),. |
|
SMSMI Correlation ID |
SMSMI-Correlation-ID |
C |
This information element indicates by its presence that the request is sent in the context of MSISDN-less SMS delivery in IMS (see 3GPP TS 23.204 [17]). This information element shall contain the SIP-URI of the (MSISDN-less) destination user. The SIP-URI of the originating user and the HSS-ID shall be absent from this information element. |
|
Service Centre Address |
SC-Address |
M |
This information element shall contain the Service Centre address. |
|
SM-RP-MTI |
SM-RP-MTI |
C |
This information element shall contain the RP-Message Type Indicator of the Short Message. It is used to distinguish a SM sent to the mobile station in order to acknowledge an MO-SM initiated by the mobile from a normal MT-SM. |
|
SM-RP-SMEA |
SM-RP-SMEA |
C |
This information element shall contain the RP-Originating SME-address of the Short Message Entity that has originated the SM. This information element shall be present if the SMS-GMSC supports receiving of the two numbers from the HSS. Used by the short message service relay sub-layer protocol it shall be formatted according to the formatting rules of address fields as described in 3GPP TS 23 040 [2]. |
|
SRR Flags |
SRR-Flags |
C |
This Information Element contains a bit mask. See 5.3.3.4 for the meaning of the bits and the condition for each bit to be set or not. |
|
SM-Delivery Not Intended |
SM-Delivery-Not-Intended |
O |
This information element, when present, shall indicate that delivery of a short message is not intended. It further indicates whether only IMSI or only MCC+MNC are requested. This information element may be set by entities that request the service without intending to deliver a short message, and shall be evaluated by the SMS Router and may be evaluated by the HSS. |
|
Supported Features |
Supported-Features (See 3GPP TS 29.229 [5]) |
O |
If present, this Information Element shall contain the list of features supported by the origin host. |
Table 5.2.1.1-2: Send Routing Info for SM Answer
|
Information element name |
Mapping to Diameter AVP |
Cat. |
Description |
|
Result |
Result-Code / Experimental-Result |
M |
Result of the request. Result-Code AVP shall be used for errors defined in the Diameter base protocol (see IETF RFC 6733 [20]). Experimental-Result AVP shall be used for S6c errors. This is a grouped AVP which contains the 3GPP Vendor ID in the Vendor-Id AVP, and the error code in the Experimental-Result-Code AVP. This information element shall contain the result of the operation with an indication of the success / errors. The following errors are applicable in this case: – Unknown User; – Service Barred; – Teleservice Not Provisioned; – Absent User; – Facility Not Supported. |
|
IMSI |
User-Name (See IETF RFC 6733 [20]) |
C |
This information element:
This information element shall be present in a successful answer. This information element shall be present in an answer from the HSS to the IP-SM-GW, if an Absent User result is returned and the UNRI is not set. |
|
Serving-Node |
Serving-Node |
C |
If the "SM-Delivery-Not-Intended" Information Element was not present in the request, this information element shall contain the identity of one serving node on which the user is registered. This identity shall either be:
If the "SM-Delivery-Not-Intended" Information Element was present in the request, this information element may be absent. This information element shall be present in a successful answer. See NOTE. |
|
LMSI |
LMSI |
C |
The HSS shall include the LMSI in a successful response, if the VLR has used the LMSI and if there is the ISDN number of an MSC in the answer. |
|
Additional Serving Node |
Additional-Serving-Node |
C |
This information element, when present shall either contain:
It shall not contain information delivered in the Serving Node information element. See NOTE. |
|
User Identifier Alert |
User-Identifier |
C |
This information element shall contain the MSISDN stored in the HSS, when available. |
|
MWD Status |
MWD-Status |
C |
This Information Element is sent when appropriate and shall contain a bit mask. See 5.3.3.8 for the meaning of the bits. |
|
MME Absent User Diagnostic SM |
MME-Absent-User-Diagnostic-SM |
C |
This information element shall contain the reason of the absence of the user when given by the MME and stored in the HSS |
|
MSC Absent User Diagnostic SM |
MSC-Absent-User-Diagnostic-SM |
C |
This information element shall contain the reason of the absence of the user when given by the MSC and stored in the HSS |
|
SGSN Absent User Diagnostic SM |
SGSN-Absent-User-Diagnostic-SM |
C |
This information element shall contain the reason of the absence of the user when given by the SGSN and stored in the HSS |
|
Supported Features |
Supported-Features (See 3GPP TS 29.229 [5]) |
O |
If present, this information element shall contain the list of features supported by the origin host. |
|
SMSF 3GPP Address |
SMSF-3GPP-Address |
C |
If the "SM-Delivery-Not-Intended" Information Element was not present in the request, this information element shall contain the identity of the registered SMSF for 3GPP access. If the "SM-Delivery-Not-Intended" Information Element was present in the request, this information element may be absent. See NOTE. |
|
SMSF Non 3GPP Address |
SMSF-Non-3GPP-Address |
C |
If the "SM-Delivery-Not-Intended" Information Element was not present in the request, this information element shall contain the identity of the registered SMSF or Non-3GPP access. If the "SM-Delivery-Not-Intended" Information Element was present in the request, this information element may be absent. See NOTE. |
|
SMSF 3GPP Absent User Diagnostic SM |
SMSF-3GPP-Absent-User-Diagnostic-SM |
C |
This information element shall contain the reason of the absence of the user when given by the SMSF registered for 3GPP access. See NOTE |
|
SMSF Non 3GPP Absent User Diagnostic SM |
SMSF-Non-3GPP-Absent-User-Diagnostic-SM |
C |
This information element shall contain the reason of the absence of the user when given by the SMSF registered for Non-3GPP access. See NOTE |
|
NOTE: If the feature "SMSF-Support" is not supported by the SMS-GMSC, IP-SM-GW, or SMS Router, the AVPs SMSF-3GPP-Address, SMSF-Non-3GPP-Address, SMSF-3GPP-Absent-User-Diagnostic and SMSF-Non-3GPP-Absent-User-Diagnostic shall not be present. In this case the SMSF 3GPP Address and/or the SMSF Non 3GPP Address may be populated in the existing Serving-Node and Additional-Serving-Node AVPs as applicable. |
|||
5.2.1.2 Detailed behaviour of the SMS-GMSC
The SMS-GMSC shall make use of this procedure to retrieve the routing information needed for routing the short message to the serving MSC or MME or SGSN or SMSF registered for 3GPP access or SMSF registered for non-3GPP access for enforcing routing of the SM delivery via the SMS Router of HPLMN.
It shall populate the information elements in the Send Routing Info for SM request according to the table 5.2.1.1-1.
When the Send Routing Info for SM Request is sent by the SMS-GMSC to the HSS in a retry context of SMS for IMS UE to IMS UE without MSISDN (see 3GPP TS 23.204 [17]), IMSI may not be available. In this case the IMSI information element shall be populated with the HSS-ID value.
When receiving the Send Routing Info for-SM Answer, the SMS-GMSC or the SMS Router shall use the received Diameter address if the SMS-GMSC or the SMS Router transfers the terminating short message over the SGd or the Gdd interface.
5.2.1.3 Detailed behaviour of the HSS
This clause describes the HSS behaviour when the HSS receives a Send Routing Info for SM request which is not forwarded to an SMS Router or an IP-SM-GW.
The HSS shall check if the user identified by the MSISDN is known; otherwise, the HSS shall return an Experimental-Result-Code set to DIAMETER_ERROR_USER_UNKNOWN.
The HSS shall check if a MT SMS Teleservice subscription exists; otherwise, the HSS shall return an Experimental-Result-Code set to DIAMETER_ERROR_SERVICE_NOT_SUBSCRIBED.
The HSS shall check if the user is not barred for receiving MT short messages; otherwise, the HSS shall return an Experimental-Result-Code set to DIAMETER_ SERVICE _ERROR_BARRED.
The HSS shall check if one or more serving nodes (not marked with the mobile not reachable flag) are registered for MT SMS; otherwise, the HSS shall return an Experimental-Result-Code set to DIAMETER_ERROR_ABSENT_USER and update the MWD list and MNRF/MNRG. If there is no serving node being registered for MT SMS and the Single-Attempt-Delivery flag in SRR-Flags AVP is set, the HSS shall not add the SC address into the MWD list.
The HSS shall then return a Send Routing Info for SM answer with a Result-Code set to DIAMETER_SUCCESSFUL that shall contain the addresses of the serving nodes that are registered for MT SMS according the following rules:
– if the GPRS indicator is not set, only one serving node address shall be returned according to the SM transfer option where MME is considered as a MSC. The address of the MME, if returned, shall comprise the MME Diameter address and the MME Number for MT SMS. The address of the SMSF, if returned, shall comprise the SMSF Diameter address and the SMSF Number.
– if the GPRS indicator is set, two serving node addresses may be returned of which
– the Diameter address of the SGSN if available and the SGSN number,
– either the number of the MSC or the Diameter address and the number of the MME for MT SMS.
– when two serving g nodes addresses are returned, the HSS selects which serving node it will populate in the Serving Node information element and in the Additional Serving Node information elements.
– if the feature SMSF-Support is commonly supported, the HSS includes addresses of the registered SMSFs (if any) in the response, regardless of the GPRS indicator.
NOTE: MSC and MME cannot be both registered as serving nodes for MT SMS at a given time (cf 3GPP TS 23.272 [2])
If the stored MSISDN number is not the same as the one received in the Send Routing Info for SM request service, the stored MSISDN number shall be included in the message.
In the context of MSISDN-less SMS delivery in IMS (see 3GPP TS 23.204 [17]), if the HSS receives an SMSMI correlation ID, the HSS shall return the IP-SM-GW number and shall not forward the request to an IP-SM-GW.
5.2.1.4 Detailed behaviour of the SMS Router
When receiving a Send Routing Info for SM request, the SMS Router shall:
– send a Send Routing Info for SM request to the HSS to retrieve the routing information needed for routing the short message to the serving MSC or MME or SGSN or SMSF;
– if the Send Routing Info for SM answer received from HSS is successful, the SMS Router shall send a Send Routing Info for SM answer to the SMS-GMSC where
– the SMS router shall populate the same Serving Node and Additional Serving Node fields (i.e AVPs) as the ones it received in the Send Routing Info for SM answer from HSS, but with its own SMS Router number and its own SMS Router Diameter address;
– if the Send Routing Info for SM answer received from HSS is not successful, the SMS Router shall send a Send Routing Info for SM answer to the SMS-GMSC with the same Diameter error result code.
If the SMS Router receives some of the following information elements, User Identifier Alert, MWD Status, MSC Absent User Diagnostic SM, MME Absent User Diagnostic SM, SGSN Absent User Diagnostic SM, it shall transfer them in the Send-Routing Info for SM answer to the SMS-GMSC.
5.2.2 Alert Service Centre procedure
5.2.2.1 General
This procedure shall be used between the HSS and the SMS-IWMSC to indicate that the MS is now recognized by the PLMN to have recovered its operation to allow for an MT SMS delivery. This procedure is used according to the call flows described in 3GPP TS 23.040 [2] clause 10.
Table 5.2.2.1-1 specifies the involved information elements for the request.
Table 5.2.2.1-2 specifies the involved information elements for the answer.
This procedure is mapped to the commands Alert-Service-Centre-Request/Answer (ALR/ALA) in the Diameter application specified in clause 5.3.2.
Table 5.2.2.1-1: Alert Service Centre Request
|
Information element name |
Mapping to Diameter AVP |
Cat. |
Description |
|
Service Centre Address |
SC-Address |
M |
This information element shall contain the Service Centre address received from the mobile station. |
|
User Identifier Alert |
User-Identifier |
M |
This information element shall contain:
|
|
SMSMI Correlation ID |
SMSMI-Correlation-ID |
C |
This information shall contain the SIP-URI of the destination user which is stored in the Message Waiting Data list in a retry context of SMS for IMS UE to IMS UE without MSISDN (see 3GPP TS 23.204 [17]). The HSS-ID and the Originating SIP-URI shall be absent. |
|
Maximum UE Availability Time |
Maximum-UE-Availability-Time |
C |
This information element shall be included, if available. When present, it shall indicate the timestamp (in UTC) until which a UE using a power saving mechanism (such as extended idle mode DRX) is expected to be reachable for SM Delivery. This information may be used by the SMS Center to prioritize the retransmission of Short Message to UEs using a power saving mechanism. |
|
Supported Features |
Supported-Features (See 3GPP TS 29.229 [5]) |
O |
If present, this information element shall contain the list of features supported by the origin host. |
Table 5.2.2.1-2: Alert Service Centre Answer
|
Information element name |
Mapping to Diameter AVP |
Cat. |
Description |
|
Result |
Result-Code / Experimental-Result |
M |
This information element shall contain the result of the request. The Result-Code AVP shall be used for errors defined in the Diameter base protocol see IETF RFC 6733 [20]). The Experimental-Result AVP shall be used for S6c errors. This is a grouped AVP which contains the 3GPP Vendor ID in the Vendor-Id AVP, and the error code in the Experimental-Result-Code AVP. This information element shall contain the result of the operation with an indication of the success / errors. No errors are defined for this case. |
|
Supported Features |
Supported-Features (See 3GPP TS 29.229 [5]) |
O |
If present, this information element shall contain the list of features supported by the origin host. |
5.2.2.2 Detailed behaviour of the HSS
The HSS shall make use of this procedure to alert the service centre when the mobile user is active after a short message transfer has failed because the mobile user is not reachable, or when the UE has indicated that it has memory capacity to accept a short message.
It is an operator option to resend an Alert Service Centre request to the SMS-IWMSC if the alert is unsuccessful. The number of repeat attempts and the interval between them is also an operator option. The service centre address should be purged from the MWD list if the alert is consistently unsuccessful.
5.2.2.3 Detailed behaviour of the SMS-IWMSC
When receiving an Alert Service Centre request the SMS-IWMSC shall check whether the service centre address is known. If the service centre address is not valid, then no further action shall be taken.
If the service centre address is valid, the SMS-IW-MSC generates an Alert Service Centre message towards the SMS Centre.
5.2.3 Report SM Delivery Status procedure
5.2.3.1 General
This procedure shall be used between the SMS-GMSC or the IP-SM-GW and the HSS to update the Message Waiting Data in the HSS or to inform the HSS of a successful SM transfer after polling. This procedure is invoked by the SMS-GMSC or the IP-SM-GW.
This procedure is applicable to an IP-SM-GW for its SMS Router function when using the S6c interface.
This procedure is used according to the call flows described in 3GPP TS 23.040 [2] clause 10.
Table 5.2.3.1-1 specifies the involved information elements for the request.
Table 5.2.3.1-2 specifies the involved information elements for the answer.
This procedure is mapped to the commands Report-SM-Delivery-Status-Request/Answer (RDR/RDA) in the Diameter application specified in clause 5.3.2.
Table 5.2.3.1-1: Report SM Delivery Status Request
|
Information element name |
Mapping to Diameter AVP |
Cat. |
Description |
|
User Identifier |
User-Identifier |
M |
This information element shall contain:
|
|
SMSMI-Correlation ID |
SMSMI-Correlation-ID |
C |
In a retry context of SMS for IMS UE to IMS UE without MSISDN (see 3GPP TS 23.204 [17]), this information element shall contain the SIP-URI of the (MSISDN-less) destination user. The originating SIP-URI and the HSS-ID shall be absent from this information element. |
|
Service Centre Address |
SC-Address |
M |
This information element shall contain the Service Centre address. |
|
SM Delivery Outcome |
SM-Delivery-Outcome |
M |
This information element shall contain the causes for setting the message waiting data in the HSS according to the network node(s) used for the SM delivery:
At least one cause shall be present. A cause originated from a MSC and a cause originated from a MME shall not be both present. When the cause is Absent User, the Absent User Diagnostic, if available, shall be associated to the cause. |
|
RDR Flags |
RDR-Flags |
O |
This Information Element contains a bit mask. See 5.3.3.21 for the meaning of the bits and the condition for each bit to be set or not. |
|
Supported Features |
Supported-Features (See 3GPP TS 29.229 [5]) |
O |
If present, this Information Element shall contain the list of features supported by the origin host. |
Table 5.2.3.1-2: Report SM Delivery Status Answer
|
Information element name |
Mapping to Diameter AVP |
Cat. |
Description |
|
Result |
Result-Code / Experimental-Result |
M |
This information element shall contain the Result of the request. The Result-Code AVP shall be used for errors defined in the Diameter base protocol (see IETF RFC 6733 [20]). The Experimental-Result AVP shall be used for S6c errors. This is a grouped AVP which contains the 3GPP Vendor ID in the Vendor-Id AVP, and the error code in the Experimental-Result-Code AVP. This information element shall contain the result of the operation with an indication of the success / errors. The following errors are applicable: – Unknown User; – Message Waiting List Full. |
|
MSISDN- Alert |
User-Identifier |
C |
This information element shall contain the Alert MSISDN of the user if it is different from the MSISDN received in the request. |
|
Supported Features |
Supported-Features (See 3GPP TS 29.229 [5]) |
O |
If present, this information element shall contain the list of features supported by the origin host. |
5.2.3.2 Detailed behaviour of the SMS-GMSC
The SMS-GMSC shall make use of this procedure if:
– the reason received from the serving node for failure to deliver the message is absent user, unidentified user or SM delivery failure with error cause "UE memory capacity exceeded", and the SC address is not yet included in the MWD set, and the serving node did not request the SMS-GMSC to retransmit the Short Message at a later requested retransmission time, or
– the reason received from the serving node for failure to deliver the message is absent user, unidentified user or SM delivery failure with error cause "UE memory capacity exceeded", and the corresponding flag in the HSS (as indicated in the information received from HSS) is not set, or
– the reason received from the serving node (MSC/MME, SGSN or SMSF) for failure to deliver the message is absent user and the absent user diagnostic is different from the absent user diagnostic received from the HSS.
If absent user diagnostic information (see 3GPP TS 23.040 [3]) is received with the absent user error indication then the SMS-GMSC shall relay this information to the HSS.
5.2.3.3 Detailed behaviour of IP-SM-GW
The IP-SM-GW shall make use of this procedure if:
– the reason for failure to deliver the message is absent user, unidentified user or SM delivery failure with error cause "UE memory capacity exceeded", and the SC address is not yet included in the MWD set, or
– the reason for failure to deliver the message is absent user, unidentified user or SM delivery failure with error cause "UE memory capacity exceeded", and the corresponding flag in the HSS (as indicated in the information received in the MAP_INFORM_SERVICE_CENTRE) is not set, or
– the reason for failure to deliver the message is absent user and the absent user diagnostic is different from the absent user diagnostic received from the HSS.
5.2.3.4 Detailed behaviour of the HSS
When receiving a Report SM Delivery Status request the HSS shall check if the user is known.
If the user is not known, the HSS shall return an Experimental-Result-Code set to DIAMETER_ERROR_USER_UNKNOWN.
If it is known, the HSS shall update the Message Waiting data as described in 3GPP TS 23.040 [3]. If the Single-Attempt-Delivery flag in RDR-Flags AVP is set, the HSS shall not add the SC address into the MWD list.
If the message waiting data is full, the HSS shall return an Experimental-Result-Code set to DIAMETER_ERROR_MWD_LIST_FULL.
If the received MSISDN is different from the stored MSISDN, the HSS shall return the Alert MSISDN.
5.3 Protocol specification
5.3.1 Routing considerations
5.3.1.1 Requests from the SMS-GMSC or the SMS router
5.3.1.1.1 Introduction
The clauses in 5.3.1.1 specify the use of the Diameter routing AVPs Destination-Realm and Destination-Host over the S6c interface for Diameter command requests from the SMS-GMSC or the SMS router or the IP-SM-GW (i.e. for the Send Routing Info for SM and the Report SM Delivery Status procedures) The clause 5.3.1.1 also applies for the Report SM Delivery Status request generated by a SMS-SC in a retry context of SMS for IMS UE to IMS UE without MSISDN (see 3GPP TS 23.204 [17]) .
5.3.1.1.2 Routing from the originating PLMN
If the SMS-GMSC or the SMS router has stored or can obtain the address/name and the home network domain name of the HSS identified by the MSISDN or the IMSI, both the Destination-Realm and Destination-Host AVPs shall be present in the request.
The SMS Router shall use the MCC/MNC values of the PLMN to which it belongs, to build the MCC/MNC based network domain as described in clause 19.2 of 3GPP TS 23.003 [16] and include it in the Destination-Realm AVP of the request. The request shall then be routed to the next Diameter node.
If the SMS-GMSC can only obtain the MCC/MNC values from the MSISDN or the IMSI, the SMS-GMSC shall use them to build the MCC/MNC based network domain as described in clause 19.2 of 3GPP TS 23.003 [16] and include it in the Destination-Realm AVP of the request. The request shall then be routed to the next Diameter node.
If the SMS-GMSC cannot obtain the MCC/MNC values from the MSISDN of the user, the SMS-GMSC may forward the request to a Diameter node within the same PLMN, the Destination Realm content being left to the PLMN operator choice. Then:
– if a Diameter node in the routing path insides the PLMN of the SMS-GSMC can obtain the MCC/MNC values of the PLMN to which the user is subscribed to (i.e. when the number portability is resolved in the network of the SMS-GMSC), or
– if, otherwise, the Diameter node can obtain the MCC/MNC values of the PLMN associated to the CC and NDC codes of the MSISDN of the user, then
– the Diameter node shall use them to build the MCC/MNC based network domain as described in clause 19.2 of 3GPP TS 23.003 [16] and include it in the Destination-Realm AVP of the request. The request shall then be routed to the next Diameter node.
If the MCC/MNC values of the PLMN associated to the CC and NDC codes of the MSISDN or the MCC/MNC values of the PLMN to which the user is subscribed to cannot be obtained in the PLMN of the SMS-GMSC, the request shall be replaced in the PLMN of the SMS-GMSC by an equivalent request routed through a MAP interface (e.g. via an IWF).
NOTE 1: The inter PLMN routing principle is to reuse the routing based on a MCC/MNC based domain name as used by other Diameter applications such as S6a/d. It is assumed that obtaining the relevant MCC/MNC values from the MSISDN can be achieved in the PLMN to which the SMS-GMSC belongs. Otherwise MAP based routing is used. This routing principle may be completed with other routing solutions in the future.
NOTE 2: The Number portability resolution in the PLMN of the SMS-GMSC can be handled by an intermediate Diameter agent consulting a Number Portability Database of the Network Portability domain to which the PLMN of the SMS-GMSC belongs.
If the SMS-SC or the SMS-GMSC, in a retry context of SMS for IMS UE to IMS UE without MSISDN (see 3GPP TS 23.204 [17]), has stored or can obtain the address/name and the home network domain name of the HSS identified by the HSS ID, both the Destination-Realm and Destination-Host AVPs shall be present in the request.
If the SMS-SC or the SMS-GMSC, in a retry context of SMS for IMS UE to IMS UE without MSISDN (see 3GPP TS 23.204 [17]), can only obtain the MCC/MNC values from the HSS ID, the SMS-SC shall use them to build the MCC/MNC based network domain as described in clause 19.2 of 3GPP TS 23.003 [16] and include it in the Destination-Realm AVP of the request. The request shall then be routed to the next Diameter node.
NOTE: In a retry context of MSISDN-less SMS delivery in IMS (see 3GPP TS 23.204 [17]), the SMS-SC gets the HSS-ID from the MO Forward Short Message request as described in clause 6.2.1.
5.3.1.1.3 Routing in the HPLMN
When the request reaches a Diameter node in the home PLMN of the user and when multiple and separately addressable HSSs have been deployed in the home PLMN, the identity of the HSS that holds the subscriber data for a given user identified by its MSISDN may be retrieved by a user identity to HSS resolution mechanism as described in clause 5.4.
When the request (i.e Send Routing Info for SM or Report SM Delivery Status) for SM occurs in the retry context of SMS for IMS UE to IMS UE without MSISDN (see 3GPP TS 23.204 [17]), the Diameter identity of the HSS that holds the subscriber data for a given user may be retrieved by a user identity to HSS resolution mechanism as described in clause 5.4, where the HSS ID conveyed in the request is considered as a user identity.
Consequently, the Destination-Host AVP is declared as optional in the ABNF for all requests initiated by an SMS-GMSC or a SMS Router.
The HSS, when receiving a Send Routing Info for SM request, checks if an SMS Router is configured in the home network or if an IP-SM-GW has been registered for the user. If yes, the HSS shall act as a Diameter proxy and forward the request to the SMS Router or to the IP-SM-GW, by inserting the Diameter address of the SMS Router or of the IP-SM-GW as the Diameter destination address. If the Send Routing Info for SM request occurs in the retry context of SMS for IMS UE to IMS UE without MSISDN (see 3GPP TS 23.204 [17]), the HSS shall return the IP-SM-GW address and shall not forward the request to an IP-SM-GW.
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, and it shall not be used for routing purposes.
5.3.1.2 Requests from the HSS
This clause specifies the use of the Diameter routing AVPs Destination-Realm and Destination-Host over the S6c interface for Diameter command requests from the HSS (i.e. for the Alert SC procedure).
If the HSS has stored the address/name of the SMS-SC and the associated home network domain name in the Message Waiting Data of the user, both the Destination-Realm and Destination-Host AVPs shall be present in the Diameter request. Otherwise the routing shall use MAP.
5.3.2 Commands
5.3.2.1 Introduction
This clause defines the Command code values and related ABNF for each command described for the S6c interface.
5.3.2.2 Command-Code values
This clause defines the Command-Code values for the S6c interface application as allocated by IANA in the IETF RFC 5516 [8].
Every command is defined by means of the ABNF syntax IETF RFC 2234 [6], according to the Command Code Format (CCF) specification defined in IETF RFC 6733 [20]. In the case, the definition and use of an AVP is not specified in this document, the guidelines in IETF RFC 6733 [20] 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 IETF RFC 6733 [20].
The following Command Codes are defined in this specification:
Table 5.3.2.2/1: Command-Code values for S6c
|
Command-Name |
Abbreviation |
Code |
Clause |
|
Send-Routing-Info-for-SM-Request |
SRR |
8388647 |
5.3.2.3 |
|
Send-Routing-Info-for-SM-Answer |
SRA |
8388647 |
5.3.2.4 |
|
Alert-Service-Centre-Request |
ALR |
8388648 |
5.3.2.5 |
|
Alert-Service-Centre-Answer |
ALA |
8388648 |
5.3.2.6 |
|
Report-SM-Delivery-Status-Request |
RDR |
8388649 |
5.3.2.7 |
|
Report-SM-Delivery-Status-Answer |
RDA |
8388649 |
5.3.2.8 |
For these commands, the Application-ID field shall be set to 16777312 (application identifier of the S6c interface application allocated by IANA).
5.3.2.3 Send-Routing-Info-for-SM-Request (SRR) Command
The Send-Routing-Info-for-SM-Request (SRR) command, indicated by the Command-Code field set to 8388647 and the "R" bit set in the Command Flags field, is sent from SMS-GMSC to HSS or SMS Router or from SMS Router to HSS.
Message Format:
< Send-Routing-Info-for-SM-Request > ::= < Diameter Header: 8388647, REQ, PXY, 16777312 >
< Session-Id >
[ DRMP ]
[ Vendor-Specific-Application-Id ]
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
[ Destination-Host ]
{ Destination-Realm }
[ MSISDN ]
[ User-Name ]
[ SMSMI-Correlation-ID ]
*[ Supported-Features ]
[ SC-Address ]
[ SM-RP-MTI ]
[ SM-RP-SMEA ]
[ SRR-Flags ]
[ SM-Delivery-Not-Intended ]
*[ AVP ]
*[ Proxy-Info ]
*[ Route-Record ]
5.3.2.4 Send-Routing-info-for-SM-Answer (SRA) Command
The Send-Routing-Info-for-SM-Answer command (SRA) command, indicated by the Command-Code field set to 8388647 and the ‘R’ bit cleared in the Command Flags field, is sent from HSS to SMS-GMSC or SMS Router or from SMS Router to SMS-GMSC.
Message Format
< Send-Routing-info-for-SM-Answer > ::= < Diameter Header: 8388647, PXY, 16777312 >
< Session-Id >
[ DRMP ]
[ Vendor-Specific-Application-Id ]
[ Result-Code ]
[ Experimental-Result ]
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
[ User-Name ]
*[ Supported-Features ]
[ Serving-Node ]
[ Additional-Serving-Node ]
[ SMSF-3GPP-Address ]
[ SMSF-Non-3GPP-Address ]
[ LMSI ]
[ User-Identifier ]
[ MWD-Status ]
[ MME-Absent-User-Diagnostic-SM ]
[ MSC-Absent-User-Diagnostic-SM ]
[ SGSN-Absent-User-Diagnostic-SM ]
[ SMSF-3GPP-Absent-User-Diagnostic-SM ]
[ SMSF-Non-3GPP-Absent-User-Diagnostic-SM ]
*[ AVP ]
[ Failed-AVP ]
*[ Proxy-Info ]
*[ Route-Record ]
5.3.2.5 Alert-Service-Centre-Request (ALR) Command
The Alert-Service-Centre-Request (ALR) command, indicated by the Command-Code field set to 8388648 and the "R" bit set in the Command Flags field, is sent from the HSS to the SMS-IWMSC and from the MME or SGSN to the SMS-GMSC (possibly via an SMS Router).
Message Format:
< Alert-Service-Centre-Request > ::= < Diameter Header: 8388648, REQ, PXY, 16777312 >
< Session-Id >
[ DRMP ]
[ Vendor-Specific-Application-Id ]
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
[ Destination-Host ]
{ Destination-Realm }
{ SC-Address }
{ User-Identifier }
[ SMSMI-Correlation-ID ]
[ Maximum-UE-Availability-Time ]
[ SMS-GMSC-Alert-Event ]
[ Serving-Node ]
*[ Supported-Features ]
*[ AVP ]
*[ Proxy-Info ]
*[ Route-Record ]
5.3.2.6 Alert-Service-Centre-Answer (ALA) Command
The Alert-Service-Centre-Answer (ALA) command, indicated by the Command-Code field set to 8388648 and the ‘R’ bit cleared in the Command Flags field, is sent from the SMS-IWMSC to the HSS and from the SMS-GMSC to the MME or SGSN (possibly via an SMS Router).
Message Format
< Alert-Service-Centre-Answer > ::= < Diameter Header: 8388648, PXY, 16777312 >
< Session-Id >
[ DRMP ]
[ Vendor-Specific-Application-Id ]
[ Result-Code ]
[ Experimental-Result ]
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
*[ Supported-Features ]
*[ AVP ]
[ Failed-AVP ]
*[ Proxy-Info ]
*[ Route-Record ]
5.3.2.7 Report-SM-Delivery-Status-Request (RDR) Command
The Report-SM-Delivery-Status-Request (RDR) command, indicated by the Command-Code field set to 8388649 and the "R" bit set in the Command Flags field, is sent from SMS-GMSC or IP-SM-GW to HSS.
Message Format:
< Report-SM-Delivery-Status-Request > ::= < Diameter Header: 8388649, REQ, PXY, 16777312 >
< Session-Id >
[ DRMP ]
[ Vendor-Specific-Application-Id ]
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
[ Destination-Host ]
{ Destination-Realm }
*[ Supported-Features ]
{ User-Identifier }
[ SMSMI-Correlation-ID ]
{ SC-Address }
{ SM-Delivery-Outcome }
[ RDR-Flags ]
*[ AVP ]
*[ Proxy-Info ]
*[ Route-Record ]
5.3.2.8 Report-SM-Delivery-Status-Answer (RDA) Command
The Report-SM-Delivery-Status-Answer (RDA) command, indicated by the Command-Code field set to 8388649 and the ‘R’ bit cleared in the Command Flags field, is sent from HSS to SMS-GMSC or IP-SM-GW.
Message Format
< Report-SM-Delivery-Status-Answer > ::= < Diameter Header: 8388649, PXY, 16777312 >
< Session-Id >
[ DRMP ]
[ Vendor-Specific-Application-Id ]
[ Result-Code ]
[ Experimental-Result ]
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
*[ Supported-Features ]
[ User-Identifier ]
*[ AVP ]
[ Failed-AVP ]
*[ Proxy-Info ]
*[ Route-Record ]
5.3.3 AVPs
5.3.3.1 General
The following table specifies the Diameter AVPs defined for the S6c 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, e.g. TFR-Flags, bit 0 shall be the least significant bit. For example, to get the value of bit 0, a bit mask of 0x0001 should be used.
Table 5.3.3.1/1: S6c specific Diameter AVPs
|
AVP Flag rules |
||||||||
|---|---|---|---|---|---|---|---|---|
|
Attribute Name |
AVP Code |
Clause defined |
Value Type |
Must |
May |
Should not |
Must not |
May Encr. |
|
SM-RP-MTI |
3308 |
5.3.3.2 |
Enumerated |
M, V |
No |
|||
|
SM-RP-SMEA |
3309 |
5.3.3.3 |
OctetString |
M, V |
No |
|||
|
SRR-Flags |
3310 |
5.3.3.4 |
Unsigned32 |
M, V |
No |
|||
|
SM-Delivery-Not-Intended |
3311 |
5.3.3.5 |
Enumerated |
M, V |
No |
|||
|
MWD-Status |
3312 |
5.3.3.8 |
Unsigned32 |
M, V |
No |
|||
|
MME-Absent-User-Diagnostic-SM |
3313 |
5.3.3.9 |
Unsigned32 |
M, V |
No |
|||
|
MSC-Absent-User-Diagnostic-SM |
3314 |
5.3.3.10 |
Unsigned32 |
M, V |
No |
|||
|
SGSN-Absent-User-Diagnostic SM |
3315 |
5.3.3.11 |
Unsigned32 |
M, V |
No |
|||
|
SM-Delivery-Outcome |
3316 |
5.3.3.14 |
Grouped |
M, V |
No |
|||
|
MME-SM-Delivery-Outcome |
3317 |
5.3.3.15 |
Grouped |
M, V |
No |
|||
|
MSC-SM-Delivery-Outcome |
3318 |
5.3.3.16 |
Grouped |
M, V |
No |
|||
|
SGSN-SM-Delivery-Outcome |
3319 |
5.3.3.17 |
Grouped |
M, V |
No |
|||
|
IP-SM-GW-SM-Delivery-Outcome |
3320 |
5.3.3.18 |
Grouped |
M, V |
No |
|||
|
SM-Delivery-Cause |
3321 |
5.3.3.19 |
Enumerated |
M, V |
No |
|||
|
Absent-User-Diagnostic-SM |
3322 |
5.3.3.20 |
Unsigned32 |
M, V |
No |
|||
|
RDR-Flags |
3323 |
5.3.3.21 |
Unsigned32 |
V |
M |
No |
||
|
Maximum-UE-Availability-Time |
3329 |
5.3.3.22 |
Time |
V |
M |
No |
||
|
SMS-GMSC-Alert-Event |
3333 |
5.3.3.23 |
Unsigned32 |
V |
M |
No |
||
|
SMSF-3GPP-Absent-User-Diagnostic-SM |
3334 |
5.3.3.25 |
Unsigned32 |
V |
M |
No |
||
|
SMSF-Non-3GPP-Absent-User-Diagnostic-SM |
3335 |
5.3.3.26 |
Unsigned32 |
V |
M |
No |
||
|
SMSF-3GPP-SM-Delivery-Outcome |
3336 |
5.3.3.27 |
Grouped |
V |
M |
No |
||
|
SMSF-Non-3GPP-SM-Delivery-Outcome |
3337 |
5.3.3.28 |
Grouped |
V |
M |
No |
||
|
SMSF-3GPP-Number |
3338 |
5.3.3.29 |
OctetString |
V |
M |
No |
||
|
SMSF-Non-3GPP-Number |
3339 |
5.3.3.30 |
OctetString |
V |
M |
No |
||
|
SMSF-3GPP-Name |
3340 |
5.3.3.31 |
DiameterIdentity |
V |
M |
No |
||
|
SMSF-Non-3GPP-Name |
3341 |
5.3.3.32 |
DiameterIdentity |
V |
M |
No |
||
|
SMSF-3GPP-Realm |
3342 |
5.3.3.33 |
DiameterIdentity |
V |
M |
No |
||
|
SMSF-Non-3GPP-Realm |
3343 |
5.3.3.34 |
DiameterIdentity |
V |
M |
No |
||
|
SMSF-3GPP-Address |
3344 |
5.3.3.35 |
Grouped |
V |
M |
No |
||
|
SMSF-Non-3GPP-Address |
3345 |
5.3.3.36 |
Grouped |
V |
M |
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 [20]. 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 from existing Diameter Applications, including a reference to their respective specifications and when needed, a short description of their use within this interface.
Any other AVPs from existing Diameter Applications, except for the AVPs from Diameter Base Protocol specified in IETF RFC 6733 [20], do not need to be supported. The AVPs from Diameter base protocol specified in IETF RFC 6733 [20] are not included in table 5.3.3.1/2, but they may be re-used for this interface.
Table 5.3.3.1/2: S6c re-used Diameter AVPs
|
Attribute Name |
Reference |
Comments |
M-bit |
|---|---|---|---|
|
User-Name |
IETF RFC 6733 [20] |
Must |
|
|
MSISDN |
3GPP TS 23.329 [14] |
||
|
SC-Address |
3GPP TS 29.338 |
It is defined for the SGd/Gdd interface, see clause 6.3.3.2 |
|
|
LMSI |
3GPP TS 29.173 [10] |
||
|
Serving-Node |
3GPP TS 29.173 [10] |
See clause 5.3.3.6 |
|
|
MSC-Number |
3GPP TS 29.173 [10] |
||
|
MME-Name |
3GPP TS 29.173 [10] |
||
|
MME-Realm |
3GPP TS 29.173 [10] |
Must |
|
|
MME-Number-for-MT-SMS |
3GPP TS 29.272 [4] |
Must |
|
|
SGSN-Number |
3GPP TS 29.272 [4] |
||
|
SGSN-Name |
3GPP TS 29.173 [10] |
||
|
SGSN-Realm |
3GPP TS 29.173[10] |
||
|
Additional-Serving-Node |
3GPP TS 29.173 [10] |
See clause 5.3.3.7 |
|
|
User-Identifier |
3GPP TS 29.336 [15] |
||
|
SM-Delivery-Failure-Cause |
3GPP TS 29.338 |
It is defined for the SGd/Gdd interface, see clause 6.3.3.5 |
|
|
IP-SM-GW-Name |
3GPP TS 29.336 [15] |
||
|
IP-SM-GW-Number |
3GPP TS 29.336 [15] |
||
|
SMSMI-Correlation-ID |
3GPP TS 29.338 |
It is defined for the SGd/Gdd interface, see clause 6.3.3.2 |
|
|
Destination-SIP-URI |
3GPP TS 29.338 |
It is defined for the SGd/Gdd interface, see clause 6.3.3.2 |
|
|
Supported-Features |
3GPP TS 29.229 [5] |
||
|
Feature-List-ID |
3GPP TS 29.229 [5] |
See clause 5.3.3.12 |
|
|
Feature-List |
3GPP TS 29.229 [5] |
See clause 5.3.3.13 |
|
|
DRMP |
IETF RFC 7944 [19] |
see clause 5.3.3.24 |
Must not set |
|
NOTE 1: The M-bit settings for re-used AVPs override those of the defining specifications that are referenced. Values include: "Must set", "Must not set". If the M-bit setting is blank, then the defining specification applies. 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. |
|||
5.3.3.2 SM-RP-MTI
The SM-RP-MTI AVP is of type Enumerated and shall contain the RP-Message Type Indicator of the Short Message. The following values are defined:
– SM_DELIVER (0)
– SM_STATUS_REPORT (1)
5.3.3.3 SM-RP-SMEA
The SM-RP-SMEA AVP is of type OctetString and shall contain the RP-Originating SME-address of the Short Message Entity that has originated the SM. It shall be formatted according to the formatting rules of the address fields described in 3GPP TS 23.040 [3].
5.3.3.4 SRR-Flags
The SRR-Flags AVP is of type Unsigned32 and it shall contain a bit mask. The meaning of the bits shall be as defined in table 5.3.3.4./1:
Table 5.3.3.4/1: SRR-Flags
|
Bit |
Name |
Description |
|
0 |
GPRS-Indicator |
This bit shall be set if the SMS-GMSC supports receiving of two serving nodes addresses from the HSS. |
|
1 |
SM-RP-PRI |
This bit shall be set if the delivery of the short message shall be attempted when a service centre address is already contained in the Message Waiting Data file |
|
2 |
Single-Attempt-Delivery |
This bit if set indicates that only one delivery attempt shall be performed for this particular SM. |
|
NOTE 1: Bits not defined in this table shall be cleared by the sending entity and discarded by the receiving entity. |
||
5.3.3.5 SM-Delivery-Not-Intended
The SM-Delivery-Not-Intended AVP is of type Enumerated and shall indicate by its presence that delivery of a short message is not intended. It further indicates whether only IMSI or only MCC+MNC with the following values:
– ONLY_IMSI_REQUESTED (0),
– ONLY_MCC_MNC_REQUESTED (1).
5.3.3.6 Serving-Node
The Serving-Node AVP is of type Grouped. This AVP shall contain the information about the network node serving the targeted SMS user. It is originally defined in 3GPP TS 29.173 [10].
AVP format
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.
5.3.3.7 Additional-Serving-Node
The Additional-Serving-Node AVP is of type Grouped. This AVP shall contain the information about the network node serving the targeted user. It is originally defined in 3GPP TS 29.173 [10].
AVP format
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
5.3.3.8 MWD-Status
The MWD-Status AVP is of type Unsigned32 and it shall contain a bit mask. The meaning of the bits shall be as defined in table 5.3.3.8/1:
Table 5.3.3.8/1: MWD Status
|
bit |
name |
Description |
|
0 |
SC-Address Not included |
This bit when set shall indicate that the SC Address has not been added to the Message Waiting Data in the HSS. |
|
1 |
MNRF-Set |
This bit, when set, shall indicate that the MNRF flag is set in the HSS |
|
2 |
MCEF-Set |
This bit, when set, shall indicate that the MCEF flag is set in the HSS. |
|
3 |
MNRG-Set |
This bit, when set, shall indicate that the MNRG flag is set in the HSS |
|
4 |
MNR5G-Set |
This bit, when set, shall indicate that the HSS/UDM is waiting for a reachability notification / registration from 5G serving nodes. |
|
NOTE: Bits not defined in this table shall be cleared by the sending HSS and discarded by the receiving MME. |
||
5.3.3.9 MME-Absent-User-Diagnostic-SM
The MME-Absent-User-Diagnostic-SM AVP is of type Unsigned32 and shall indicate the diagnostic explaining the absence of the user given by the MME. The values are defined in 3GPP TS 23.040 [3] clause 3.3.2.
5.3.3.10 MSC-Absent-User-Diagnostic-SM
The MSC-Absent-User-Diagnostic-SM AVP is of type Unsigned32 and shall indicate the diagnostic explaining the absence of the user given by the MSC. The values are defined in 3GPP TS 23.040 [3] clause 3.3.2.
5.3.3.11 SGSN-Absent-Subscriber-Diagnostic-SM
The SGSN-Absent-User-Diagnostic-SM AVP is of type Unsigned32 and shall indicate the diagnostic explaining the absence of the user given by the SGSN. The values are defined in 3GPP TS 23.040 [3] clause 3.3.2.
5.3.3.12 Feature-List-ID AVP
The syntax of this AVP is defined in 3GPP TS 29.229 [5]. For this release, the Feature-List-ID AVP value shall be set to 1.
5.3.3.13 Feature-List AVP
The syntax of this AVP is defined in 3GPP TS 29.229 [5]. A null value indicates that there is no feature used by the application.
For the S6c application, the meaning of the bits shall be as defined in table 5.3.3.13/1 for the Feature-List-ID 1.
Table 5.3.3.13/1: Features of Feature-List-ID 1 used in S6c
|
Feature bit |
Feature |
M/O |
Description |
|
0 |
SMSF-Support |
O |
SMSF-Support This feature is applicable for the SRR/SRA command pair. If the SMS-GMSC or IP-SM-GW or SMS-Router does not support this feature, the HSS shall not return SMSF related AVPs (SMSF-3GPP-Address, SMSF-Non-3GPP-Address, SMSF-3GPP-Absent-User-Diagnostic-SM, SMSF-Non-3GPP-Absent-User-Diagnostic-SM) in SRA, and when the UE is known not to be reachable for SMS via MSC/MME and/or SGSN, the HSS may populate AVPs within the Serving-Node AVP and within the Additional-Serving-Node AVP with available SMSF address information. |
|
Feature bit: The order number of the bit within the Supported-Features AVP, e.g. "1". Feature: A short name that can be used to refer to the bit and to the feature, e.g. "SMSF-Support". M/O: Defines if the implementation of the feature is mandatory ("M") or optional ("O"). Description: A clear textual description of the feature. |
|||
5.3.3.14 SM-Delivery-Outcome
The SM-Delivery-Outcome AVP is of type Grouped. This AVP contains the result of the SM delivery.
AVP format:
SM-Delivery-Outcome::= <AVP header: 3316 10415>
[ MME-SM-Delivery-Outcome ]
[ MSC-SM-Delivery-Outcome ]
[ SGSN-SM-Delivery-Outcome ]
[ IP-SM-GW-SM-Delivery-Outcome ]
[ SMSF-3GPP-SM-Delivery-Outcome ]
[ SMSF-Non-3GPP-SM-Delivery-Outcome ]
*[AVP]
5.3.3.15 MME-SM-Delivery-Outcome
The MME-Delivery-Outcome AVP is of type grouped and shall indicate the outcome of the SM delivery for setting the message waiting data in the HSS when the SM delivery is with an MME.
AVP format:
MME-SM-Delivery-Outcome::= <AVP header: 3317 10415>>
[ SM-Delivery-Cause ]
[ Absent-User-Diagnostic-SM ]
5.3.3.16 MSC-SM-Delivery-Outcome
The MSC-Delivery-Outcome AVP is of type grouped and shall indicate the outcome of the SM delivery for setting the message waiting data in the HSS when the SM delivery is with an MSC.
AVP format:
MSC-SM-Delivery-Outcome::= <AVP header: 3318 10415>
[ SM-Delivery-Cause ]
[ Absent-User-Diagnostic-SM ]
5.3.3.17 SGSN-SM-Delivery-Outcome
The SGSN-Delivery-Outcome AVP is of type grouped and shall indicate the outcome of the SM delivery for setting the message waiting data in the HSS when the SM delivery is with an SGSN.
AVP format:
SGSN-SM-Delivery-Outcome::= <AVP header: 3319 10415>
[ SM-Delivery-Cause ]
[ Absent-User-Diagnostic-SM ]
5.3.3.18 IP-SM-GW-SM-Delivery-Outcome
The IP-SM-GW-SM-Delivery-Outcome AVP is of type grouped and shall indicate the outcome of the SM delivery for setting the message waiting data when the SM delivery is with an IP-SM-GW. The following values are defined.
AVP format:
IP-SM-GW-SM-Delivery-Outcome::= <AVP header: 3320 10415>
[ SM-Delivery-Cause ]
[ Absent-User-Diagnostic-SM ]
5.3.3.19 SM-Delivery-Cause
The SM-Delivery-Cause AVP is of type Enumerated and shall indicate the cause of the SMP delivery result. The following values are defined:
– UE_ MEMORY_CAPACITY_EXCEEDED (0)
– ABSENT_USER (1)
– SUCCESSFUL_TRANSFER (2)
5.3.3.20 Absent-User-Diagnostic-SM
The Absent-User-Diagnostic-SM AVP is of type Unsigned32 and shall indicate the diagnostic explaining the absence of the subscriber. The values are defined in 3GPP TS 23.040 [3] clause 3.3.2.
5.3.3.21 RDR-Flags
The RDR-Flags AVP is of type Unsigned32 and it shall contain a bit mask. The meaning of the bits shall be as defined in table 5.3.3.21/1:
Table 5.3.3.21/1: RDR-Flags
|
Bit |
Name |
Description |
|
0 |
Single-Attempt-Delivery |
This bit if set indicates that only one delivery attempt shall be performed for this particular SM. |
|
NOTE 1: Bits not defined in this table shall be cleared by the sending entity and discarded by the receiving entity. |
||
5.3.3.22 Maximum-UE-Availability-Time
The Maximum-UE-Availability-Time is of type Time and in shall contain the timestamp (in UTC) until which a UE using a power saving mechanism (such as extended idle mode DRX) is expected to be reachable for SM Delivery.
5.3.3.23 SMS-GMSC-Alert-Event
The SMS-GMSC-Alert-Event AVP is of type Unsigned32 and it shall contain a bit mask. The meaning of the bits shall be as defined in table 5.3.3.23/1:
Table 5.3.3.23/1: SMS-GMSC-Alert-Event
|
Bit |
Name |
Description |
|
0 |
UE-Available-For-MT-SMS |
This bit, when set, shall indicate that the UE is now available for MT SMS |
|
1 |
UE-Under-New-Serving-Node |
This bit, when set, shall indicate that the UE has moved under the coverage of another MME or SGSN. |
|
NOTE 1: Bits not defined in this table shall be cleared by the sending entity and discarded by the receiving entity. |
||
5.3.3.24 DRMP
The DRMP AVP is of type Enumerated and it is defined in IETF RFC 7944 [19]. This AVP allows the HSS, the SMS-GMSC, the SMS-Router and the IP-SM-GW to indicate the relative priority of Diameter messages over the S6c interface. The DRMP AVP may be used to set the DSCP marking for transport of the associated Diameter message.
5.3.3.25 SMSF-3GPP-Absent-User-Diagnostic-SM
The SMSF-3GPP-Absent-User-Diagnostic-SM AVP is of type Unsigned32 and shall indicate the diagnostic explaining the absence of the user given by the SMSF registered for 3GPP access. The values are defined in 3GPP TS 23.040 [3] clause 3.3.2.
5.3.3.26 SMSF-Non-3GPP-Absent-User-Diagnostic-SM
The SMSF-Non-3GPP-Absent-User-Diagnostic-SM AVP is of type Unsigned32 and shall indicate the diagnostic explaining the absence of the user given by the SMSF registered for Non-3GPP access. The values are defined in 3GPP TS 23.040 [3] clause 3.3.2.
5.3.3.27 SMSF-3GPP-SM-Delivery-Outcome
The SMSF-3GPP-SM-Delivery-Outcome AVP is of type grouped and shall indicate the outcome of the SM delivery for setting the message waiting data in the HSS when the SM delivery is with an SMSF registered for 3GPP access.
AVP format:
SMSF-3GPP-SM-Delivery-Outcome::= <AVP header: 3336 10415>>
[ SM-Delivery-Cause ]
[ Absent-User-Diagnostic-SM ]
5.3.3.28 SMSF-Non-3GPP-SM-Delivery-Outcome
The SMSF-Non-3GPP-SM-Delivery-Outcome AVP is of type grouped and shall indicate the outcome of the SM delivery for setting the message waiting data in the HSS when the SM delivery is with an SMSF registered for Non-3GPP access.
AVP format:
SMSF-Non-3GPP-SM-Delivery-Outcome::= <AVP header: 3337 10415>>
[ SM-Delivery-Cause ]
[ Absent-User-Diagnostic-SM ]
5.3.3.29 SMSF-3GPP-Number
The SMSF-3GPP-Number AVP is of type OctetString and it shall contain the ISDN number of the SMSF registered for 3GPP access. For further details on the definition of this AVP, see 3GPP TS 23.003 [3]. This AVP contains an SMSF-3GPP-Number in international number format as described in ITU-T Rec E.164 [13] and shall be encoded as a TBCD-string. See 3GPP TS 29.002 [9] for encoding of TBCD-strings. This AVP shall not include leading indicators for the nature of address and the numbering plan; it shall contain only the TBCD-encoded digits of the address.
5.3.3.30 SMSF-Non-3GPP-Number
The SMSF-Non-3GPP-Number AVP is of type OctetString and it shall contain the ISDN number of the SMSF registered for Non-3GPP access. For further details on the definition of this AVP, see 3GPP TS 23.003 [3]. This AVP contains an SMSF-Non-3GPP-Number in international number format as described in ITU-T Rec E.164 [13] and shall be encoded as a TBCD-string. See 3GPP TS 29.002 [9] for encoding of TBCD-strings. This AVP shall not include leading indicators for the nature of address and the numbering plan; it shall contain only the TBCD-encoded digits of the address.
5.3.3.31 SMSF-3GPP-Name
The SMSF-3GPP-Name AVP is of type DiameterIdentity and it shall contain the Diameter identity of the serving SMSF registered for 3GPP access. For further details on the encoding of this AVP, see IETF RFC 6733 [20].
5.3.3.32 SMSF-Non-3GPP-Name
The SMSF-Non-3GPP-Name AVP is of type DiameterIdentity and it shall contain the Diameter identity of the serving SMSF registered for Non-3GPP access. For further details on the encoding of this AVP, see IETF RFC 6733 [20].
5.3.3.33 SMSF-3GPP-Realm
The SMSF-3GPP-Realm AVP is of type DiameterIdentity and it shall contain the Diameter Realm Identity of the serving SMSF registered for 3GPP access. For further details on the encoding of this AVP, see IETF RFC 6733 [20].
5.3.3.34 SMSF-Non-3GPP-Realm
The SMSF-Non-3GPP-Realm AVP is of type DiameterIdentity and it shall contain the Diameter Realm Identity of the serving SMSF registered for Non-3GPP access. For further details on the encoding of this AVP, see IETF RFC 6733 [20].
5.3.3.35 SMSF-3GPP-Address
The SMSF-3GPP-Address AVP is of type Grouped. This AVP shall contain the information about the SMSF serving the targeted user for 3GPP access.
AVP format
SMSF-3GPP-Address ::= <AVP header: 3344 10415>
[ SMSF-3GPP-Number ]
[ SMSF-3GPP-Name ]
[ SMSF-3GPP-Realm ]
*[AVP]
5.3.3.36 SMSF-Non-3GPP-Address
The SMSF-Non-3GPP-Address AVP is of type Grouped. This AVP shall contain the information about the SMSF serving the targeted user for Non-3GPP access.
AVP format
SMSF-Non-3GPP-Address ::= <AVP header: 3345 10415>
[ SMSF-Non-3GPP-Number ]
[ SMSF-Non-3GPP-Name ]
[ SMSF-Non-3GPP-Realm ]
*[AVP]
5.4 User identity to HSS resolution
The User identity to HSS resolution mechanism enables the SMS-GMSC or SMS Router in the home PLMN or Diameter proxy agents in the home PLMN to find the identity of the HSS that holds the subscriber data for a given user identified by its MSISDN or by its IMSI when multiple and separately addressable HSSs have been deployed in the home PLMN. The resolution mechanism is not required in PLMNs 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 PLMN within dedicated Diameter Agents (Proxy Agents) responsible for determining the HSS identity based on the provided user identity. If this Diameter based implementation is selected by the home PLMN operator, the principles described below shall apply.
When more than one independently addressable HSS are deployed in the home PLMN, each SMS-GMSC or SMS-Router network of the home PLMN shall be configured with the address/identity of a Diameter Agent (Proxy Agent) implementing this resolution mechanism.
Diameter Relay agents and/or Diameter Proxy agents in the home PLMN receiving the Diameter signalling from SMS-GMSC located in other PLMNs shall be configured with the address/identity of a Diameter Agent (Proxy Agent) implementing this resolution mechanism.
To get the HSS identity that holds the subscriber data for a given user identity in the home network, the Diameter request normally destined to the HSS shall be sent to the pre-configured address/identity of a Diameter Proxy agent supporting the User identity to HSS resolution mechanism.
– If this Diameter request is received by a Diameter Redirect Agent, the Diameter Redirect Agent shall determine the HSS identity based on the provided user identity (i.e. MSISDN or IMSI) and shall return a notification of redirection towards the HSS identity, in response to the Diameter request. Multiple HSS identities may be included in the response, as specified in IETF RFC 6733 [20]. In such a case, the requesting Diameter entity shall send the Diameter request to the first HSS identity in the ordered list received in the Diameter response from the Diameter Redirect Agent. If no successful response to the Diameter request is received, the requesting Diameter entity shall send a Diameter request to the next HSS identity in the ordered list. This procedure shall be repeated until a successful response from an HSS is received. After the user identity to HSS resolution, the MME or the SGSN shall store the determined HSS identity/name/Realm and shall use it in further Diameter requests to the same user identity.
– If this Diameter request is received by a Diameter Proxy Agent, the Diameter Proxy Agent shall determine the HSS identity based on the provided user identity (i.e. MSISDN or IMSI) and shall forward the Diameter request directly to the HSS. In this case, the user identity to HSS resolution decision is communicated to the SMS-GMSC in the Origin-Host/Origin-Realm AVPs of the response.
NOTE: Alternatives to the user identity to HSS resolution Diameter based implementation are outside the scope of this specification.
The User identity to HSS resolution mechanism, in a retry context of SMS for IMS UE to IMS UE without MSISDN (see 3GPP TS 23.204 [17]), applies as described in this clause for requests issued by the SMS-SC to a HSS and where the IMSI of the user is replaced by the HSS ID of the HSS storing the subscription data of the user.