6 Diameter based SGd/Gdd interfaces between MME/SGSN and central SMS functions
29.3383GPPDiameter based protocols to support Short Message Service (SMS) capable Mobile Management Entities (MMEs)Release 18TS
6.1 Introduction
The SGd interface enables the transfer of short messages between the MME, the SMS-IWMSC, the SMS-GMSC and the SMS Router, and the alerting of the SMS-GMSC by the MME (possibly via an SMS Router), as described in 3GPP TS 23.040 [3].
The Gdd interface enables the transfer of short messages between the SGSN, the SMS-IWMSC, the SMS-GMSC and the SMS Router, and the alerting of the SMS-GMSC by the SGSN (possibly via an SMS Router) as described in 3GPP TS 23.040 [3].
6.2 Procedures description
6.2.1 MO Forward Short Message procedure
6.2.1.1 General
This procedure shall be used between the serving MME or SGSN or IP-SM-GW and the SMS-IWMSC to forward mobile originated short messages from a mobile user to a Service Centre.
This procedure is used according to the call flows described in 3GPP TS 23.040 [3] clause 10.
This procedure may also be used between the SMS-IWMSC and the MTC-IWF to forward mobile originated short messages from a mobile user to an MTC-IWF; see 3GPP TS 23.682 [18].
Table 6.2.1.1/1 specifies the involved information elements for the request.
Table 6.2.1.1/2 specifies the involved information elements for the answer.
This procedure is mapped to the commands MO-Forward-Short-Message-Request/Answer (OFR/OFA) in the Diameter application specified in clause 6.3.2.
Table 6.2.1.1/1: MO Forward Short Message Request
|
Information element name |
Mapping to Diameter AVP |
Cat. |
Description |
|
SM RP DA |
SC-Address |
M |
When used between MME or SGSN or IP-SM-GW and SMS-IWMSC, this information element shall contain the Service Centre address received from the mobile station. |
|
SM RP OA |
User-Identifier |
M |
This information element shall contain: – the IMSI if it is available; – the MSISDN of the user when it exists. – a dummy MSISDN value in the context of MSISDN-less SMS delivery in IMS (see 3GPP TS 23.204 [17]), if IMSI is not available. In this case the originating user is identified by the Originating SIP-URI (see SMSMI-Correlation ID). |
|
SM RP UI |
SM-RP-UI |
M |
This information element shall contain the short message transfer protocol data unit |
|
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]). When present, this information element shall contain an HSS-ID identifying the destination user’s HSS, a Destination SIP-URI identifying the MSISDN-less destination user, and an Originating SIP-URI identifying the MSISDN-less originating user. |
|
OFR Flags |
OFR-Flags |
C |
This information element shall contain a bit mask. See 6.3.3.12 for the meaning of the bits. |
|
EPS-Location-Information |
EPS-Location-Information |
O |
When present, this Information Element shall contain the EPS-Location Information (as defined in TS 29.272, clause 7.3.111) indicating the serving cell where the UE is originating the SMS from. |
|
SM Delivery Outcome |
SM-Delivery-Outcome |
C |
This information element shall be present if the SMSMI Correlation ID is present and shall contain the IP-SM-GW SM Delivery Outcome with the causes for setting the message waiting data in the HSS. |
|
Supported Features |
Supported-Features |
O |
If present, this information element shall contain the list of features supported by the origin host. |
NOTE: In the context of MSISDN-less SMS delivery in IMS (see 3GPP TS 23.204 [17]), the IP-SM-GW gets the HSS-ID and the SM Delivery Outcome from the SIP message coming from the IMS network of the destination user and indicating a temporary SMS delivery failure.
Table 6.2.1.1/2: MO-Forward Short Message 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 operation. The Result-Code AVP shall be used to indicate success / errors as defined in the Diameter base protocol (see IETF RFC 6733 [20]). The Experimental-Result AVP shall be used for SGd/Gdd/T4 errors. This is a grouped AVP which shall contain the 3GPP Vendor ID in the Vendor-Id AVP, and the error code in the Experimental-Result-Code AVP. The following errors are applicable:
|
|
SM Delivery Failure Cause |
SM-Delivery-Failure-Cause |
C |
If the Experimental-Result-Code is set to DIAMETER_ERROR_SM_DELIVERY_FAILURE, this information element shall be present and indicate one of the following:
It may be completed with a Diagnostic information element. |
|
SM RP UI |
SM-RP-UI |
O |
If present, this information element shall contain a short message transfer protocol data unit in the message delivery acknowledgement from the SMS-IWMSC to the MME or SGSN |
|
Supported Features |
Supported-Features |
O |
If present, this information element shall contain the list of features supported by the origin host. |
|
External-Identifier |
External-Identifier |
C |
This information element shall contain the External Identifier identifying the sender of the short message. Shall be present when the answer is sent over T4 to the SMS-IWMSC for charging. |
6.2.1.2 Detailed behaviour of the MME, the SGSN and the IP-SM-GW
When the "SMS in MME" feature is applied for the UE, the MME shall make use of this procedure to forward mobile originated short messages received from the UE to the SMS-IWMSC associated to the SMS-SC indicated by the UE.
When the SGSN supports the SMS service for the UE, the SGSN shall make use of this procedure to forward mobile originated short messages received from the UE to the SMS-IWMSC associated to the SMS-SC indicated by the UE.
The IP-SM-GW shall make use of this procedure to forward mobile originated short messages received from the UE to the SMS-IWMSC associated to the SMS-SC indicated by the UE. This procedure shall be also used in the context of MSISDN-less SMS delivery in IMS (see 3GPP TS 23.204 [17]), when the direct SMS delivery has failed,
The MME or the SGSN shall check if the SMS related subscription data (e.g. ODB data and Call Barring) allows forwarding the short message.
6.2.1.3 Detailed behaviour of the SMS-IWMSC
When receiving the MO Forward Short Message Request, the SMS-IWMSC shall check if the SMS-SC is known, if it is not, an Experimental-Result-Code set to DIAMETER_ERROR_SM_DELIVERY_FAILURE and a SM Delivery Failure Cause indicating "unknown Service Centre address" shall be returned to the MME or the SGSN.
The SMS IWMSC shall then pass the short message to the addressed SMS-SC, or, if the destination user identity maps to an MTC-IWF based on a pre-configured mapping table, forward it to the appropriate MTC-IWF.
If the SMS-SC or MTC-IWF returns a negative acknowledgement, an Experimental-Result-Code set to DIAMETER_ERROR_SM_DELIVERY_FAILURE and a SM Delivery Failure Cause indicating the cause given by the SMC-SC or MTC-IWF shall be returned to the MME or the SGSN.
If the SMS-SC or MTC-IWF returns a positive acknowledgement to the SMS IWMSC, a Result-Code set to DIAMETER_SUCCESS shall be returned to the MME or the SGSN.
If a requested facility is not supported, an Experimental-Result-Code set to DIAMETER_ERROR_FACILITY_NOT_SUPPORTED shall be returned.
6.2.2 MT Forward Short Message procedure
6.2.2.1 General
This procedure shall be used between the SMS-GMSC and the serving MME or SGSN (transiting an SMS Router, if present) or IP-SM-GW to forward mobile terminated short messages.
This procedure is used according to the call flows described in 3GPP TS 23.040 [3] clause 10.
Table 6.2.2.1/1 specifies the involved information elements for the request.
Table 6.2.2.1/2 specifies the involved information elements for the answer.
This procedure is mapped to the commands MT-Forward-Short-Message-Request/Answer (TFR/TFA) in the Diameter application specified in clause 6.3.2.
Table 6.2.2.1/1: MT Forward Short Message Request
|
Information element name |
Mapping to Diameter AVP |
Cat. |
Description |
|
SM RP DA |
User-Name (See IETF RFC 6733 [20]) |
M |
This information element shall contain – either an IMSI – or a HSS ID value if an SMSMI-Correlation ID is present, the destination user being identified by the Destination SIP-URI within the SMSMI Correlation ID. |
|
SM RP OA |
SC-Address |
M |
This information element shall contain the Service Centre address. |
|
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]). When present, this information element shall contain the Destination SIP-URI identifying the (MSISDN-less) destination user and the Originating SIP-URI identifying the (MSISDN-less) originating user. The HSS-ID shall be absent from this information element. |
|
SM RP UI |
SM-RP-UI |
M |
This information element shall contain the short message transfer protocol data unit. |
|
MME Number for MT SMS |
MME-Number-for-MT-SMS |
C |
This Information Element contains the ISDN number of the MME (see 3GPP TS 23.003 [3]) and shall be present when the request is sent to a MME. |
|
SGSN Number |
SGSN-Number |
C |
This Information Element contains the ISDN number of the SGSN (see 3GPP TS 23.003 [3]) and shall be present when the request is sent to a SGSN. |
|
TFR-Flags |
TFR-Flags |
C |
This information element shall contain a bit mask. Bit 0 indicates when set if the Service Centre has more messages to send |
|
SM Delivery Timer |
SM-Delivery-Timer |
C |
This information element should be included. When present, it shall indicate the SM Delivery Timer value set in the SMS-GMSC to the IP-SM-GW, MME or S4-SGSN. |
|
SM Delivery Start Time |
SM-Delivery- Start-Time |
C |
This information element should be included. When present, it shall indicate the timestamp (in UTC) at which the SM Delivery Supervision Timer was started in the SMS-GMSC. |
|
Maximum Retransmission Time |
Maximum-Retransmission-Time |
O |
This information element, when present, shall indicate the maximum retransmission time (in UTC) until which the SMS-GMSC is capable to retransmit the MT Short Message. |
|
SMS-GMSC Address |
SMS-GMSC-Address |
C |
This IE shall be present if the Maximum Retransmission Time IE is present in the message. When present, this IE shall contain the E.164 number of the SMS-GMSC in the request sent by the SMS-GMSC or the E.164 number of the SMS Router in the request sent by the SMS Router. |
|
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 6.2.2.1/2: MT Forward Short Message 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 operation. The Result-Code AVP shall be used to indicate success / errors as defined in the Diameter base protocol (see IETF RFC 6733 [20]). The Experimental-Result AVP shall be used for SGd/Gdd errors. This is a grouped AVP which shall contain the 3GPP Vendor ID in the Vendor-Id AVP, and the error code in the Experimental-Result-Code AVP. The following errors are applicable:
|
|
Absent User Diagnostic SM |
Absent-User-Diagnostic-SM |
O |
This information element may be present when Experimental-Result-Code is set to DIAMETER_ERROR_ABSENT_USER and it shall contain the reason of the absence of the user given by the MME or the SGSN. |
|
SM Delivery Failure Cause |
SM-Delivery-Failure-Cause |
C |
If Experimental-Result-Code is set to DIAMETER_ERROR_SM_DELIVERY_FAILURE, this information element shall be present and indicate one of the following:
It may be completed with a Diagnostic information element |
|
SM RP UI |
SM-RP-UI |
O |
If present, this information element shall contain a short message transfer protocol data unit in the message delivery acknowledgement from the MME to the Service Centre. |
|
Requested Retransmission Time |
Requested-Retransmission-Time |
O |
This information element may only be present if the Experimental-Result-Code is set to DIAMETER_ERROR_ABSENT_USER and if the Maximum Retransmission Time information element is present in the MT Forward Short Message Request. It may be included if the UE is using a power saving mechanism (such as extended idle mode DRX) and the UE is currently not reachable. When present, this shall indicate the retransmission time (in UTC) at which the SMS-GMSC is requested to retransmit the MT Short Message. The Requested Retransmission Time shall not exceed the Maximum Retransmission Time received from the SMS-GMSC. |
|
User Identifier Alert |
User-Identifier |
C |
This IE shall be present in the message from the SMS Router to the SMS-GMSC, if the Requested Retransmission Time IE is present in the message. |
|
EPS-Location-Information |
EPS-Location-Information |
O |
When present, this Information Element shall contain the EPS-Location Information (as defined in TS 29.272, clause 7.3.111) indicating the serving cell where the MT UE is located. |
|
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. |
6.2.2.2 Detailed behaviour of the MME and the SGSN
When receiving a MT Forward Short Message Request, the MME or the SGSN shall check if the IMSI is known,
If it is not known, an Experimental-Result-Code set to DIAMETER_ERROR_USER_UNKNOWN shall be returned.
The MME or the SGSN shall attempt to deliver the short message to the UE.
If the delivery of the short message to the UE is successful, the MME or the SGSN shall return a Result-Code set to DIAMETER_SUCCESS.
If the UE is not reachable via the MME, the MME shall set the MNRF flag and shall return an Experimental-Result-Code set to DIAMETER_ERROR_ABSENT_USER.
If the UE is not reachable via the SGSN, the SGSN shall set the MNRG flag and shall return an Experimental-Result-Code set to DIAMETER_ERROR_ABSENT_USER.
If the UE is using extended idle mode DRX (as defined in 3GPP TS 23.682 [18]) and the UE is expected to not respond to paging shortly or within the time frame indicated by the SM-Delivery-Timer and SM-Delivery-Start-Time IEs, the MME or SGSN may behave as specified above for a UE that is not reachachable, while still paging the UE.
NOTE 1: This mechanism is not intended for UEs which are known to wake up shortly (e.g. within the next 10 seconds) as enough time needs to elapse, between the sending of the MT Forward Short Message Answer and the subsequent Notification procedure towards the HSS when the UE becomes reachable, to enable the Report SM Delivery Status procedure to take place beforehand from the SMS-GMSC to the HSS.
If the UE is using extended idle mode DRX (as defined in 3GPP TS 23.682 [18]) and the UE is expected to respond to paging shortly or within the time frame indicated by the SM-Delivery-Timer and SM-Delivery-Start-Time IEs, the MME or SGSN should page the UE and attempt to deliver the short message to the UE.
If the UE is using a power saving mechanism such as extended idle mode DRX (see 3GPP TS 23.682 [18]), and if the MT Forward Short Message Request includes the Maximum-Retransmission-Time AVP, the MME or SGSN may return an MT Forward Short Message Answer with the Experimental-Result-Code set to DIAMETER_ERROR_ABSENT_USER and with the Requested-Retransmission-Time AVP requesting the SMS-GMSC to retransmit the Short Message at a later time prior to the Maximum Retransmission Time. In that case, the MME or SGSN shall store (if not already done) the Origin-Host, the Origin-Realm and the SMS-GMSC address received in request and shall not set the MNRF or MNRG flag.
NOTE 2: This mechanism does not cause additional signalling at the HSS to retransmit the Short Message.
If the delivery of the mobile terminated short message failed because of memory capacity exceeded or UE error or UE not SM equipped, the MME or the SGSN shall return an Experimental-Result-Code set to DIAMETER_ERROR_SM_DELIVERY_FAILURE complemented with a SM Delivery Failure Cause indication.
If a requested facility is not supported, the MME or the SGSN shall return an Experimental-Result-Code set to DIAMETER_ERROR_FACILITY_NOT_SUPPORTED.
If the user is busy for MT SMS, i.e. the mobile terminated short message transfer cannot be completed because:
– another mobile terminated short message transfer is going on and the delivery node does not support message buffering; or
– another mobile terminated short message transfer is going on and it is not possible to buffer the message for later delivery; or
– the message was buffered but it is not possible to deliver the message before the expiry of the buffering time defined in 3GPP TS 23.040 [3],
the MME or the SGSN shall return an Experimental-Result-Code set to DIAMETER_ERROR_USER_BUSY_FOR_MT_SMS.
If the delivery of the mobile terminated short message failed because the mobile station failed authentication, the MME or the SGSN shall return an Experimental-Result-Code set to DIAMETER_ERROR_ILLEGAL_USER.
If the delivery of the mobile terminated short message failed because an IMEI check failed, i.e. the IMEI was prohibite-listed or not permitted-listed, the MME or the SGSN shall return an Experimental-Result-Code set to DIAMETER_ERROR_ILLEGAL_EQUIPMENT.
6.2.2.3 Detailed behaviour of the SMS-GMSC
The SMS-GMSC shall make use of this procedure over the SGd interface or over the Gdd interface for the delivery of a MT short message when it has selected the serving node of which it obtained the Diameter Identity from the answer of the Send Routing Info for SM procedure.
NOTE: The SMS-GMSC is not aware that the MT Forward Short Message Request may be routed to a SMS router.
The SMS-GMSC may include the Maximum-Retransmission-Time AVP in the MT Forward Short Request to indicate that it is capable to retransmit the Short Message until the indicated maximum retransmission time, if the following conditions are fulfilled:
– the destination user pertains to the PLMN of the SMS-GMSC; and
– if an SMS Router is used for MT SMS sent to destination users pertaining to the PLMN of the SMS-GMSC, the SMS Router is known to support the Alert Service Centre procedure specified in clause 6.2.3.
The SMS-GMSC shall include its E.164 number in the SMS-GMSC address in the request if it also includes the Maximum-Retransmission-Time AVP.
When the SMS router has received a MT Forward Short Message from the SMS-GMSC and the SMS Router has selected the MME or the SGSN for delivery, the SMS Router shall forward it to the MME or the SGSN.
If the MT Forward Short Message Request includes the Maximum-Retransmission-Time AVP, the SMS Router shall store the SMS-GMSC Diameter Identity (received in the Origin-Host and Origin-Realm AVPs) and the SMS-GMSC address received in the request and replace them by its SMS Router Diameter Identity (in the Origin-Host and Origin-Realm AVPs) and SMS Router address (E.164 number) when forwarding the request to the MME or SGSN.
When a MT Forward Short Message Answer is received from the MME, the SMS Router shall forward it to the SMS-GMSC.
If the MT Forward Short Message Answer includes the Requested-Retransmission-Time AVP, the SMS Router shall include a User Identifier Alert AVP when forwarding the answer to the SMS-GMSC.
NOTE: The User Identifier Alert is further used in the Alert Service Centre procedure specified in clause 6.2.3 to enable the SMS-GMSC to identify and retransmit all pending MT SMS messages towards the destination user.
6.2.3 Alert Service Centre procedure
6.2.3.1 General
This procedure shall be used between the MME or SGSN and the SMS-GMSC, possibly via an SMS Router, to indicate that a UE, for which one or more MT SMS have been requested to be retransmitted at a later time, is now available for MT SMS delivery or that it has moved under the coverage of another MME or SGSN. This procedure is used according to the call flows described in 3GPP TS 23.040 [2] clause 10.
Table 6.2.3.1-1 specifies the involved information elements for the request.
Table 6.2.3.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 6.2.3.1-1: Alert Service Centre Request
|
Information element name |
Mapping to Diameter AVP |
Cat. |
Description |
|
Service Centre Address |
SC-Address |
M |
This IE shall contain the E.164 number of the SMS-GMSC (or SMS Router) previously received in the SMS-GMSC Address IE in the MT Forward Short Message Request. |
|
User Identifier Alert |
User-Identifier |
M |
This IE shall contain:
encoded in the User-Name AVP. |
|
SMS-GMSC Alert Event |
SMS-GMSC-Alert-Event |
M |
This IE shall contain the type of event that caused the Alert Service Centre Request to the SMS-GMSC:
|
|
New Serving Node Identity |
Serving-Node |
C |
This IE shall be present if available and if the SMS-GMSC Alert Event indicates that the UE has moved under the coverage of another MME or SGSN. When present, this IE shall contain the Diameter Identity and/or the E.164 number of the new serving node of the UE. It shall be encoded as:
|
|
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 6.2.3.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. |
6.2.3.2 Detailed behaviour of the MME and the SGSN
The MME or SGSN shall make use of this procedure to alert the SMS-GMSC when the UE, for which one or more MT SMS have been requested to be retransmitted at a later time, becomes available for MT SMS delivery or moves under the coverage of another MME or SGSN prior to the requested SM retransmission time.
The MME or SGSN shall delete the stored SMS-GMSC Diameter Identity (i.e. Origin-Host and Origin-Realm) and address after the Alert Service Centre procedure is completed.
6.2.3.3 Detailed behaviour of the SMS-GMSC
When receiving an Alert Service Centre request, the SMS-GMSC shall retransmit pending MT SMS(s) for the destination user identified by the User Identifier Alert, to the same serving node if the SMS-GMSC Alert Event indicates that the UE is available for MT SMS, or to the new serving node if the SMS-GMSC Alert Event indicates that the UE has moved under the coverage of another MME or SGSN. In the latter case, if no New Serving Node Identity is received in the Alert Service Centre request, the SMS-GMSC shall initiate a Send Routing Info for SM procedure to retrieve the new serving node ‘s address from the HSS.
6.2.3.4 Detailed behaviour of the SMS-Router
When receiving an Alert Service Centre request, the SMS-Router shall replace the IMSI received in the User Identifier Alert by the User Identifier Alert previously sent in the MT Forward Short Message Answer, and forward that request to the SMS-GMSC.
6.3 Protocol specification
6.3.1 Routing considerations
6.3.1.1 Routing for MO Forward SM messages:
This clause specifies the use of the Diameter routing AVPs Destination-Realm and Destination-Host over the SGd or Gdd interfaces for the Diameter command requests from the MME or from the SGSN (i.e. for the MO forward SM procedure).
Also, this clause specifies the use of the Diameter routing AVPs Destination-Realm and Destination-Host over the T4 interface for the Diameter command requests from the SMS-IWMSC (i.e. for the MO forward SM procedure).
This clause also applies for the Diameter command MO forward SM request from the IP-SM-GW towards an SMS-SC/SMS-IWMSC, including the case where the MO forward SM request occurs in the retry context of SMS for IMS UE to IMS UE without MSISDN (see 3GPP TS 23.204 [17]). MME or SGSN is replaced by IP-SM-GW in the text of this clause.
If the MME or the SGSN, from the SMS-SC E.164 number received from the UE, can obtain the address/name of the SMS-IWMSC and the associated home network domain name (e.g. by local configuration), both the Destination-Realm and Destination-Host AVPs shall be present in the request.
If the MME or the SGSN, from the SMS-SC E.164 number received from the UE, can only obtain the MCC/MNC values of the PLMN to which the SMS-SC belongs, the MME or the SGSN 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 MME or the SGSN cannot obtain the MCC/MNC values from the SMS-SC E.164 number, the MME or the SGSN shall 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 MME can obtain the MCC/MNC values of the PLMN to which the SMS-SC belongs,
– it 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 to which the SMS-SC belongs cannot be obtained in the PLMN of the MME or the SGSN, the request shall be replaced in the PLMN of the MME or the SGSN 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 E.164 number of the SMS-SC can be achieved in the PLMN which the MME belongs to. Otherwise a MAP based routing is used. This routing principle may be completed with other routing solutions in the future.
Consequently, the Destination-Host AVP is declared as optional in the ABNF for all requests initiated by an MME or a SGSN.
The SMS-IWMSC shall be able to obtain the address/name of the MTC-IWF and the associated home network domain name from the destination SME address included in the MO TPDU (e.g. by local configuration); therefore both the Destination-Realm and Destination-Host AVPs shall be present in the request.
6.3.1.2 Routing for MT Forward SM messages:
This clause specifies the use of the Diameter routing AVPs Destination-Realm and Destination-Host for the Diameter command requests from the SMS-GMSC or the SMS Router (i.e. for the MT forward SM procedure).
– if the SMS-GMSC has received the Diameter address/name of an MME or of the SGSN in the answer to its interrogation to the HSS/HLR for retrieving routing information and if it selects this serving node, it shall use it to populate the Destination-Realm and Destination-Host AVPs.
– If the SMS Router has received the Diameter address/name of the MME or of the SGSN in the answer to its interrogation to the HSS/HLR for retrieving routing information and if it selects this serving node, it shall use this Diameter address/name to populate the Destination-Realm and Destination-Host AVPs.
Consequently, the Destination-Host AVP is declared as mandatory in the ABNF for all requests initiated by an SMS-GMSC or a SMS router.
6.3.2 Commands
6.3.2.1 Introduction
This clause defines the Command code values and related ABNF for each command described for the SGd interface.
6.3.2.2 Command-Code values
This clause defines the Command-Code values for the SGd interface application as allocated by IANA in the IETF RFC 5516 [8], the SGd interface application being used over the SGd and Gdd interfaces. The Alert Service Centre procedure used over the SGd and Gdd interfaces also uses commands of the S6c interface application.
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 ensure potential interoperability issues with Diameter agents non-compliant with IETF RFC 6733 [20].
The following Command Codes are defined in this specification:
Table 6.3.2.2/1: Command-Code values for SGd/Gdd
|
Command-Name |
Abbreviation |
Code |
Clause |
|
MO-Forward-Short-Message Request |
OFR |
8388645 |
6.3.2.3 |
|
MO-Forward-Short-Message Answer |
OFA |
8388645 |
6.3.2.4 |
|
MT-Forward-Short-Message Request |
TFR |
8388646 |
6.3.2.5 |
|
MT-Forward-Short-Message Answer |
TFA |
8388646 |
6.3.2.6 |
|
Alert-Service-Centre-Request |
ALR |
8388648 |
5.3.2.5 |
|
Alert-Service-Centre-Answer |
ALA |
8388648 |
5.3.2.6 |
For these commands, the Application-ID field shall be set to 16777313 (application identifier of the SGd interface application, allocated by IANA), except for the ALR/ALA commands for which the Application-ID field shall be set to 16777312 (application identifier of the S6c interface application, allocated by IANA).
6.3.2.3 MO-Forward-Short-Message-Request (OFR) Command
The MO-Forward-Short-Message-Request (OFR) command, indicated by the Command-Code field set to 8388645 and the "R" bit set in the Command Flags field, is sent from the MME / SGSN to the SMS-IWMSC and it is also sent from the SMS-IWMSC to the MTC-IWF.
Message Format
< MO-Forward-Short-Message-Request > ::= < Diameter Header: 8388645, REQ, PXY, 16777313 >
< Session-Id >
[ DRMP ]
[ Vendor-Specific-Application-Id ]
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
[ Destination-Host ]
{ Destination-Realm }
{ SC-Address }
[ OFR-Flags ]
*[ Supported-Features ]
{ User-Identifier }
[ EPS-Location-Information ]
{ SM-RP-UI }
[ SMSMI-Correlation-ID ]
[ SM-Delivery-Outcome ]
*[ AVP ]
*[ Proxy-Info ]
*[ Route-Record ]
6.3.2.4 MO-Forward-Short-Message-Answer (OFA) Command
The MO-Forward-Short-Message-Answer Command (OFA) command, indicated by the Command-Code field set to 8388645 and the ‘R’ bit cleared in the Command Flags field, is sent from the SMS-IWMSC to the MME / SGSN and it is also sent from the MTC-IWF to the SMS-IWMSC.
Message Format
< MO-Forward-Short-Message-Answer > ::= < Diameter Header: 8388645, PXY, 16777313 >
< Session-Id >
[ DRMP ]
[ Vendor-Specific-Application-Id ]
[ Result-Code ]
[ Experimental-Result ]
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
*[ Supported-Features ]
[ SM-Delivery-Failure-Cause ]
[ SM-RP-UI ]
[ External-Identifier ]
*[ AVP ]
[ Failed-AVP ]
*[ Proxy-Info ]
*[ Route-Record ]
6.3.2.5 MT-Forward-Short-Message-Request (TFR) Command
The MT-Forward-Short-Message-Request (TFR) command, indicated by the Command-Code field set to 8388646 and the "R" bit set in the Command Flags field, is sent from the SMS-GMSC to the MME / SGSN (transiting an SMS Router, if present).
Message Format
< MT-Forward-Short-Message-Request > ::= < Diameter Header: 8388646, REQ, PXY, 16777313 >
< Session-Id >
[ DRMP ]
[ Vendor-Specific-Application-Id ]
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
{ Destination-Host }
{ Destination-Realm }
{ User-Name }
*[ Supported-Features ]
[ SMSMI-Correlation-ID ]
{ SC-Address }
{ SM-RP-UI }
[ MME-Number-for-MT-SMS ]
[ SGSN-Number ]
[ TFR-Flags ]
[ SM-Delivery-Timer ]
[ SM-Delivery-Start-Time ]
[ Maximum-Retransmission-Time ]
[ SMS-GMSC-Address ]
*[ AVP ]
*[ Proxy-Info ]
*[ Route-Record ]
6.3.2.6 MT-Forward-Short-Message-Answer (TFA) Command
The MT-Forward-Short-Message-Answer Command (TFA) command, indicated by the Command-Code field set to 8388646 and the ‘R’ bit cleared in the Command Flags field, is sent from the MME / SGSN to the SMS-GMSC (transiting an SMS Router, if present).
Message Format
< MT-Forward-Short-Message-Answer > ::= < Diameter Header: 8388646, PXY, 16777313 >
< Session-Id >
[ DRMP ]
[ Vendor-Specific-Application-Id ]
[ Result-Code ]
[ Experimental-Result ]
{ Auth-Session-State }
{ Origin-Host }
{ Origin-Realm }
*[ Supported-Features ]
[ Absent-User-Diagnostic-SM ]
[ SM-Delivery-Failure-Cause ]
[ SM-RP-UI ]
[ Requested-Retransmission-Time ]
[ User-Identifier ]
[ EPS-Location-Information ]
*[ AVP ]
[ Failed-AVP ]
*[ Proxy-Info ]
*[ Route-Record ]
6.3.3 AVPs
6.3.3.1 General
The following table specifies the Diameter AVPs defined for the SGd/Gdd 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 6.3.3.1/1: SGd/Gdd specific Diameter AVPs
|
AVP Flag rules |
||||||||
|---|---|---|---|---|---|---|---|---|
|
Attribute Name |
AVP Code |
Clause defined |
Value Type |
Must |
May |
Should not |
Must not |
May Encr. |
|
SC-Address |
3300 |
6.3.3.2 |
OctetString |
M, V |
No |
|||
|
SM-RP-UI |
3301 |
6.3.3.3 |
OctetString |
M, V |
No |
|||
|
TFR-Flags |
3302 |
6.3.3.4 |
Unsigned32 |
M, V |
No |
|||
|
SM-Delivery-Failure-Cause |
3303 |
6.3.3.5 |
Grouped |
M, V |
No |
|||
|
SM-Enumerated-Delivery-Failure-Cause |
3304 |
6.3.3.6 |
Enumerated |
M, V |
No |
|||
|
SM-Diagnostic-Info |
3305 |
6.3.3.7 |
OctetString |
M, V |
No |
|||
|
SM-Delivery-Timer |
3306 |
6.3.3.10 |
Unsigned32 |
M, V |
No |
|||
|
SM-Delivery-Start-Time |
3307 |
6.3.3.11 |
Time |
M, V |
No |
|||
|
SMSMI-Correlation-ID |
3324 |
6.3.3.13 |
Grouped |
V |
M |
No |
||
|
HSS-ID |
3325 |
6.3.3.14 |
OctetString |
V |
M |
No |
||
|
Originating-SIP-URI |
3326 |
6.3.3.15 |
UTF8String |
V |
M |
No |
||
|
Destination-SIP-URI |
3327 |
6.3.3.16 |
UTF8String |
V |
M |
No |
||
|
OFR-Flags |
3328 |
6.3.3.12 |
Unsigned32 |
V |
M |
No |
||
|
Maximum-Retransmission-Time |
3330 |
6.3.3.17 |
Time |
V |
M |
No |
||
|
Requested-Retransmission-Time |
3331 |
6.3.3.18 |
Time |
V |
M |
No |
||
|
SMS-GMSC-Address |
3332 |
6.3.3.19 |
OctetString |
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 6.3.3.1/2, but they may be re-used for this interface.
Table 6.3.3.1/2: SGd/Gdd re-used Diameter AVPs
|
Attribute Name |
Reference |
Comments |
M-bit |
|---|---|---|---|
|
User-Name |
IETF RFC 6733 [20] |
Must |
|
|
User-Identifier |
3GPP TS 29.336 [15] |
||
|
MME-Number-for-MT-SMS |
3GPP TS 29.272 [4] |
||
|
SGSN-Number |
3GPP TS 29.272 [4] |
Must not |
|
|
EPS-Location-Information |
3GPP TS 29.272 [4] |
Must not set |
|
|
Absent-User-Diagnostic-SM |
3GPP TS 29.338 |
It is defined for the S6c interface, see clause 5.3.3.20 |
|
|
Supported-Features |
3GPP TS 29.229 [5] |
||
|
Feature-List-ID |
3GPP TS 29.229 [5] |
See clause 6.3.3.8 |
|
|
Feature-List |
3GPP TS 29.229 [5] |
See clause 6.3.3.9 |
|
|
DRMP |
IETF RFC 7944 [19] |
see clause 6.3.3.20 |
Must not set |
|
External-Identifier |
3GPP TS 29.336 [15] |
Must not |
|
|
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. |
|||
6.3.3.2 SC-Address
The SC-Address AVP is of type OctetString and it shall contain the E.164 number of the SMS-SC or MTC-IWF, in international number format as described in ITU-T Recommendation E.164 [13] and 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.
6.3.3.3 SM-RP-UI
The SM-RP-UI is of type OctetString and it shall contain a short message transfer protocol data unit (TPDU) which is defined in 3GPP TS 23.040 [3] and represents the user data field carried by the short message service relay sub-layer protocol. Its maximum length is of 200 octets.
6.3.3.4 TFR-Flags
The TFR-Flags AVP is of type Unsigned32 and it shall contain a bit mask. The meaning of the bits shall be as defined in table 6.3.3.4/1:
Table 6.3.3.4/1: TFR-Flags
|
Bit |
Name |
Description |
|
0 |
More-Messages-To-Send |
This bit, when set, shall indicate that the service centre has more short messages to send. |
|
NOTE 1: Bits not defined in this table shall be cleared by the sending entity and discarded by the receiving entity. |
||
6.3.3.5 SM-Delivery-Failure-Cause
The SM-Delivery-Failure-Cause AVP is of type Grouped. It shall contain information about the cause of the failure of a SM delivery with an optional Diagnostic information.
The AVP format shall conform to:
SM-Delivery-Failure-Cause ::= <AVP header: 3304 10415>
{ SM-Enumerated-Delivery-Failure-Cause }
[ SM-Diagnostic-Info ]
*[ AVP ]
6.3.3.6 SM-Enumerated-Delivery-Failure-Cause
The SM-Enumerated-Delivery-Failure-Cause AVP is of type enumerated and it shall contain the cause of the failure of a SM delivery. The following values are defined:
MEMORY_CAPACITY_EXCEEDED (0),
EQUIPMENT_PROTOCOL_ERROR (1),
EQUIPMENT_NOT_SM-EQUIPPED (2),
UNKNOWN_SERVICE_CENTRE (3),
SC-CONGESTION (4),
INVALID_SME-ADDRESS (5),
USER_NOT_SC-USER (6).
NOTE: The values of the SM- Enumerated-Delivery-Failure-Cause AVP correspond to the ones for the SM-EnumeratedDeliveryFailureCause parameter in MAP as described in 3GPP TS 29.002[9].
6.3.3.7 SM-Diagnostic-Info
The SM-Diagnostic-Info AVP is of type OctetString and it shall contain a complementary information associated to the SM Delivery Failure cause.
6.3.3.8 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.
6.3.3.9 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.
NOTE: There is no feature defined for this release.
6.3.3.10 SM-Delivery-Timer
The SM-Delivery-Timer is of type Integer and it shall contain the value in seconds of the timer for SM Delivery.
6.3.3.11 SM-Delivery-Start-Time
The SM-Delivery-Start-Time is of type Time and in shall contain the timestamp (in UTC) at which the SM Delivery Supervision Timer was started.
6.3.3.12 OFR-Flags
The OFR-Flags AVP is of type Unsigned32 and it shall contain a bit mask. The meaning of the bits shall be as defined in table 6.3.3.12/1:
Table 6.3.3.12/1: OFR-Flags
|
Bit |
Name |
Description |
|
0 |
S6a/S6d-Indicator |
This bit, when set, indicates that the OFR message is sent on the Gdd interface, i.e. the source node is an SGSN (or a combined MME/SGSN to which the UE is attached via UTRAN). This bit, when cleared, indicates that the OFR message is sent on the SGd interface, i.e. the source node is an MME (or a combined MME/SGSN to which the UE is attached via UTRAN or GERAN). |
6.3.3.13 SMSMI-Correlation-ID
The SMSMI-Correlation-ID AVP is of type Grouped. It shall contain information identities used in the context of MSISDN-less SMS delivery in IMS (see 3GPP TS 23.204 [17]).
The AVP format shall conform to:
SMS-MI-Correlation-ID ::= <AVP header: 3308 10415>
[ HSS-ID ]
[ Originating-SIP-URI ]
[ Destination-SIP-URI ]
*[ AVP ]
6.3.3.14 HSS-ID
The HSS-ID AVP is of typeUTF8String. The definition and the composition of the HSS-ID are specified in 3GPP TS 23.003 [16].
6.3.3.15 Originating-SIP-URI
The Originating-SIP-URI AVP is of type UTF8String. It shall contain the Public identity of the IMS UE without MSISDN which is the sender of a short message, in the context of MSISDN-less SMS delivery in IMS (see 3GPP TS 23.204 [17]).
6.3.3.16 Destination-SIP-URI
The Destination-SIP-URI AVP is of type UTF8String. It shall contain the Public identity of the IMS UE without MSISDN which is the recipient of a short message, in the context of MSISDN-less SMS delivery in IMS (see 3GPP TS 23.204 [17]).
6.3.3.17 Maximum-Retransmission-Time
The Maximum-Retransmission-Time is of type Time and in shall contain the maximum retransmission time (in UTC) until which the SMS-GMSC is capable to retransmit the MT Short Message.
6.3.3.18 Requested-Retransmission-Time
The Requested-Retransmission-Time is of type Time and in shall contain the timestamp (in UTC) at which the SMS-GMSC is requested to retransmit the MT Short Message.
6.3.3.19 SMS-GMSC-Address
The SMS-GMSC-Address AVP is of type OctetString and it shall contain the E.164 number of the SMS-GMSC or SMS Router, in international number format as described in ITU-T Recommendation E.164 [13] and 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.
6.3.3.20 DRMP
The DRMP AVP is of type Enumerated and it is defined in IETF RFC 7944 [19]. This AVP allows the MME, the SGSN, the SMS-IWMSC, the SMS-GMSC, the SMS Router and the IP-SM-GW 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.