5 SIP related procedures

24.3413GPPRelease 18Stage 3Support of SMS over IP networksTS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

5.1 Introduction

5.2 Functional entities

5.2.1 User Equipment (UE)

5.2.1.1 General

To be compliant with short message over IP in this document, a UE shall implement:

a) the role of an SM-over-IP sender as specified in clause 5.3.1.1, clause 5.3.1.2, and clause 5.3.1.3;

b) the role of an SM-over-IP receiver as specified in clause 5.3.2.1, clause 5.3.2.2, clause 5.3.2.3, clause 5.3.2.4, and clause 5.3.2.5; or

c) the roles described in item a) and item b).

To be compliant with short message over IP in MSISDN less operation in this document, a UE shall implement:

a) the role of an SM-over-IP sender as specified in clause 5.3.1.4.1, clause 5.3.1.4.2, and clause 5.3.1.4.3;

b) the role of an SM-over-IP receiver as specified in clause 5.3.2.6.1, clause 5.3.2.6.2, clause 5.3.2.6.3, and clause 5.3.2.6.4; or

c) the roles described in item a) and item b).

NOTE: The capability of sending short messages over IP does not affect current limitations, thus the UE is limited to send at most one UE originated SM and to receive at most one UE terminated SM at a time.

5.2.1.2 Configuration

Parameters such as the PSI of the SC of the SM-over-IP sender can be obtained from the UICC as per 3GPP TS 31.103 [18] and 3GPP TS 31.102 [19] if used or from the SIM as per 3GPP TS 51.011 [20] if used.

5.2.1.3 Policy enforcement

The network operator’s preference for selection of the domain to be used for short message service originated by the UE indicates the domain for originating short messages.

The network operator’s preference for selection of the domain to be used for short message service originated by the UE can be set to one of the following values:

a) the SMS service is not to be invoked over the IP networks; and

b) the SMS service is preferred to be invoked over the IP networks.

The UE shall support the network operator’s preference for selection of the domain to be used for short message service originated by the UE.

The UE may support being configured with the network operator’s preference for selection of the domain to be used for short message service originated by the UE in the SMS_Over_IP_Networks_Indication of 3GPP TS 24.167 [8A].

Editor’s note [CR#0086, IOC_UE_conf]: Handling of any configuration on UICC related to the network operator’s preference for selection of the domain to be used for short message service originated by the UE is FFS.

If the network operator’s preference for selection of the domain to be used for short message service originated by the UE is set to "the SMS service is not to be invoked over the IP networks", the UE shall not perform the procedures in clause 5.3.1.

The policy on usage of SMS over IP indicates when the UE is allowed to use SMS over IP.

The policy on usage of SMS over IP can be set to one of the following values:

a) SMS over IP is used only if voice over PS is available and only on the IP-CAN bearer that is used for the transport of SIP signalling associated with voice over PS;

b) SMS over IP is used only if voice over PS is available and on any IP-CAN bearer; and

c) SMS over IP is used irrespective of whether voice over PS is available and on any IP-CAN bearer.

The UE may support the policy on usage of SMS over IP.

If the UE supports the policy on usage of SMS over IP and the network operator’s preference for selection of the domain to be used for short message service originated by the UE is set to "the SMS service is preferred to be invoked over the IP networks":

a) the UE may support being configured with SMSoIP usage policy using one or more of the following methods:

1) the SMSoIP usage policy leaf of the EF_{IMSConfigData} file described in 3GPP TS 31.102 [19];

2) the SMSoIP usage policy leaf of the EF_{IMSConfigData} file described in 3GPP TS 31.103 [18]; and

3) the SMSoIP usage policy leaf of 3GPP TS 24.167 [8A].

If the UE is configured with both the SMSoIP usage policy leaf of 3GPP TS 24.167 [8A] and the SMSoIP usage policy leaf of the EF_{IMSConfigData} file described in 3GPP TS 31.102 [19] or the SMSoIP usage policy leaf of the EF_{IMSConfigData} file described in 3GPP TS 31.103 [18], then the SMSoIP usage policy leaf of the EF_{IMSConfigData} file shall take precedence.

NOTE 1: Precedence for files configured on both the USIM and ISIM is defined in 3GPP TS 31.103 [18].

b) if the policy on usage of SMS over IP is set to "SMS over IP is used only if voice over PS is available and only on the IP-CAN bearer that is used for the transport of SIP signalling associated with voice over PS":

1) if the domain selection for originating voice calls specified in 3GPP TS 23.221 [29] determines that the UE does not use the IMS to originate voice call then the UE shall not perform the procedures in clause 5.3.1 and clause 5.3.2 and determines that SMS over IP is restricted (see 3GPP TS 24.229 [10]); and

2) if:

A) the domain selection for originating voice calls specified in 3GPP TS 23.221 [29] determines that the UE uses the IMS to originate voice calls;

B) the UE supports multiple registrations as specified in 3GPP TS 24.229 [10];

C) the UE registered several registration flows; and

D) at least one of the registration flow was registered via an IP-CAN different than the remaining registration flows;

then the UE shall not perform the procedures in clause 5.3.1 and clause 5.3.2 and determines that SMS over IP is restricted (see 3GPP TS 24.229 [10]) over access technology where the audio is restricted or not preferred according to 3GPP TS 24.216 [30]; and

c) if the policy on usage of SMS over IP is set to "SMS over IP is used only if voice over PS is available and on any IP-CAN bearer" and the domain selection for originating voice calls specified in 3GPP TS 23.221 [29] determines that the UE does not use the IMS to originate voice call then the UE shall not perform the procedures in clause 5.3.1 and clause 5.3.2 and determines that SMS over IP is restricted (see 3GPP TS 24.229 [10]).

NOTE 2: If the network operator’s preference for selection of the domain to be used for short message service originated by the UE is set to "the SMS service is not to be invoked over the IP networks", the policy on usage of SMS over IP has no effect.

NOTE 3: If the policy on usage of SMS over IP is set to "SMS over IP is used irrespective of whether voice over PS is available and on any IP-CAN bearer", there is no restriction regarding how SMS over IP is used.

5.2.2 Application Server (AS)

To be compliant with short message over IP in this document, an AS shall implement the role of an IP-SM-GW as specified in clause 5.3.3.1, clause 5.3.3.2, clause 5.3.3.3, and clause 5.3.3.4.

To be compliant with short message over IP in MSISDN less operation in this document, an AS shall implement the role of an IP-SM-GW as specified in clause 5.3.3.1, clause 5.3.3.2, clause 5.3.3.3, and clause 5.3.3.5.

5.3 Roles

5.3.1 SM-over-IP sender

5.3.1.1 General

In addition to the procedures specified in clause 5.3.1, the SM-over-IP sender shall support the procedures specified in 3GPP TS 24.229 [10] appropriate to the functional entity in which the SM-over-IP sender is implemented. The SM-over-IP sender shall build and populate RP-DATA message, containing all the information that a mobile station submitting an SM according to 3GPP TS 24.011 [8] would place, for successful delivery. The SM-over-IP sender shall parse and interpret RP- DATA, RP-ACK and RP-ERROR messages, containing all the information that a mobile station receiving an SM according to 3GPP TS 24.011 [8] would see, in a SM submission or status report.

NOTE 1: If the SM-over-IP sender uses SMR entity timers as specified in 3GPP TS 24.011 [8], then TR1M is set to a value greater than timer F (see 3GPP TS 24.229 [10]).

NOTE 2: If the SM-over-IP sender expects to receive a SM submit report will include the "+g.3gpp.smsip" parameter in the Contact header field when sending a REGISTER request.

5.3.1.2 Submitting a short message

When an SM-over-IP sender wants to submit an SM over IP, the SM-over-IP sender shall send a SIP MESSAGE request with the following information:

a) the Request-URI, which shall contain the PSI of the SC of the SM-over-IP sender;

NOTE 1: The PSI of the SC can be SIP URI or tel URI based on operator policy. The PSI of the SC can be obtained using one of the following methods in the priority order listed below:

1) provided by the user;

2) if UICC is used, then:

– if an ISIM is present, then the PSI of the SC is obtained from the EF_PSISMSCin DF_TELECOM as per 3GPP TS 31.103 [18];

– if an ISIM is not present, then the PSI of the SC is obtained from the EF_PSISMSCin DF_TELECOM as per 3GPP TS 31.102 [19]; or

– if the PSI of the SC is not available in EF_PSISMSCin DF_TELECOM, then the PSI of the SC contains the TS‑Service-Centre-Address stored in the EF_SMSP in DF_TELECOM as per 3GPP TS 31.102 [19]. If the PSI of the SC is based on the E.164 number from the TS‑Service-Centre-Address stored in the EF_SMSP in DF_TELECOM then the URI constructed can be either a tel URI or a SIP URI (using the "user=phone" SIP URI parameter format).

3) if SIM is used instead of UICC, then the PSI of the SC contains the TS‑Service Centre Address stored in the EF_SMSP in DF_TELECOM as per 3GPP TS 51.011 [20]. If the PSI of the SC is based on the E.164 number from the TS‑Service-Centre-Address stored in the EF_SMSP in DF_TELECOM then the URI constructed can be either a tel URI or a SIP URI (using the "user=phone" SIP URI parameter format); or

4) if neither the UICC nor SIM is used, then how the PSI of the SC is configured and obtained is through means outside the scope of this specification.

b) the From header, which shall contain a public user identity of the SM-over-IP sender;

NOTE 2: The IP-SM-GW will have to use an address of the SM-over-IP sender that the SC can process (i.e. an E.164 number). This address will come from a tel URI in a P-Asserted-Identity header (as defined in RFC 3325 [13]) placed in the SIP MESSAGE request by the P-CSCF or S-CSCF.

NOTE 3: The SM-over-IP sender has to store the Call-ID of the SIP MESSAGE request, so it can associate the appropriate SIP MESSAGE request including a submit report with it.

c) the To header, which shall contain the PSI of the SC of the SM-over-IP sender;

d) the Content-Type header, which shall contain "application/vnd.3gpp.sms"; and

e) the body of the request shall contain an RP-DATA message as defined in 3GPP TS 24.011 [8], including the SMS headers and the SMS user information encoded as specified in 3GPP TS 23.040 [3].

NOTE 4: The address of the SC is included in the RP-DATA message content. The address of the SC included in the RP-DATA message content is stored in the EF_SMSP in DF_TELECOM of the (U)SIM of the SM-over-IP sender.

NOTE 5: The SM-over-IP sender will use content transfer encoding of type "binary" for the encoding of the SM in the body of the SIP MESSAGE request.

NOTE 6: Both the address of the SC and the PSI of the SC can be configured in the EF_PSISMSCin DF_TELECOM of the USIM and ISIM respectively using the USAT as per 3GPP TS 31.111 [21].

The SM-over-IP sender may request the SC to return the status of the submitted message. The support of status report capabilities is optional for the SC.

When a SIP MESSAGE request including a submit report in the "vnd.3gpp.sms" payload is received, the SM-over-IP sender shall:

– if SM-over-IP sender supports In-Reply-To header usage and the In-Reply-To header indicates that the request corresponds to a short message submitted by the SM-over-IP sender, generate a 200 (OK) SIP response according to RFC 3428 [14].

if SM-over-IP sender supports In-Reply-To header usage and the In-Reply-To header indicates that the request does not correspond to a short message submitted by the SM-over-IP sender, a 488 (Not Acceptable here) SIP response according to RFC 3428 [14].

– if SM-over-IP sender does not support In-Reply-To header usage, generate a 200 (OK) SIP response according to RFC 3428 [14]; and extract the payload encoded according to 3GPP TS 24.011 [8] for RP-ACK or RP-ERROR.

5.3.1.3 Receiving a status report

When a SIP MESSAGE request including a status report in the "vnd.3gpp.sms" payload is delivered, the SM-over-IP sender shall:

– generate a SIP response according to RFC 3428 [14];

– extract the payload encoded according to 3GPP TS 24.011 [8] for RP-DATA; and

– create a delivery report for the status report as described in clause 5.3.2.4. The content of the delivery report is defined in 3GPP TS 24.011 [8].

5.3.1.4 SM-over-IP sender procedures for operation without MSISDN

5.3.1.4.1 General

This clause specifies the procedures for the SM-over-IP sender to support the MSISDN less.

An SM-over-IP sender supporting the procedures in this clause shall support:

a) procedures specified in clause 5.3.1.1; and

b) the In-Reply-To header field.

5.3.1.4.2 Submitting a short message and subscription without MSISDN

When an SM-over-IP sender wants to submit an SM over IP and the destination side is addressed with a SIP URI, then the SM-over-IP sender shall perform the actions as specified in clause 5.3.1.2 with the following additions and modifications:

a) the Content-Type header field, which shall contain "multipart/mixed";

b) an application/vnd.3gpp.sms+xml MIME body as described in clause D.1 with a Content-Disposition header field set to "render" and with "handling" header field parameter set to "optional". The XML document shall contain a single <To> element which contains the URI of the receiver of the short message; and

c) an application/vnd.3gpp.sms MIME body containing the RP-DATA message as defined in 3GPP TS 24.011 [8], including the SMS headers and the SMS user information encoded as specified in 3GPP TS 23.040 [3] with a TP-DA field set to the dummy MSISDN value as defined in 3GPP TS 23.003 [22].

The SM-over-IP sender can request the IP-SM-GW to return the status of submitted messages.

When a SIP MESSAGE request including a submit report in the "vnd.3gpp.sms" payload is received, the SM-over-IP sender shall:

1) if the In-Reply-To header field indicates that the request corresponds to a short message submitted by the SM-over-IP sender, generate a 200 (OK) SIP response according to RFC 3428 [14]; or

2) if the In-Reply-To header field indicates that the request does not correspond to a short message submitted by the SM-over-IP sender, generate a 488 (Not Acceptable here) SIP response according to RFC 3428 [14].

5.3.1.4.3 Receiving a status report and subscription without MSISDN

When a SIP MESSAGE request including a "vnd.3gpp.sms" payload is received in response to a short message sent according to the procedures in clause 5.3.1.4.2 then the SM-over-IP sender shall:

– generate a SIP response according to RFC 3428 [14];

– extract the payload encoded according to 3GPP TS 24.011 [8] for RP-DATA; and

– create a delivery report for the received SMS-STATUS-REPORT. In order to do so send a SIP MESSAGE as follows:

a) the Request-URI, which shall contain the address of the IP-SM-GW;

NOTE 1: The address of the IP-SM-GW is received in the P-Asserted-Identity header field in the received SIP MESSAGE request.

b) the From header field which shall contain a public user identity of the SM-over-IP sender.

c) the To header field which shall contain the address of the IP-SM-GW;

d) the In-Reply-To header field which shall contain the Call-Id of the received SIP MESSAGE request;

e) the Content-Type header field shall contain "application/vnd.3gpp.sms"; and

f) the body of the request shall contain the RP-ACK or RP-ERROR message for the SM delivery report, as defined in 3GPP TS 24.011 [8].

NOTE 2: The SM-over-IP sender will use content transfer encoding of type "binary" for the encoding of the SM in the body of the SIP MESSAGE request.

5.3.2 SM-over-IP receiver

5.3.2.1 General

In addition to the procedures specified in clause 5.3.2, the SM-over-IP receiver shall support the procedures specified in 3GPP TS 24.229 [10] appropriate to the functional entity in which the SM-over-IP receiver is implemented. The SM-over-IP receiver shall build and populate RP-SMMA, RP-ACK, and RP-ERROR messages, containing all the information that a mobile station according to 3GPP TS 24.011 [8] would place, for a notification for availability of memory and a delivery report. The SM-over-IP receiver shall parse and interpret RP- DATA message, containing all the information that a mobile station receiving an SM according to 3GPP TS 24.011 [8] would see, in a SM delivery.

5.3.2.2 Registration

On sending a REGISTER request, the SM-over-IP receiver shall indicate its capability to receive traditional short messages over IMS network by including a "+g.3gpp.smsip" parameter into the Contact header according to RFC 3840 [16].

5.3.2.3 Delivery of a short message

When a SIP MESSAGE request including a short message in the "vnd.3gpp.sms" payload is delivered, the SM-over-IP receiver shall:

– generate a SIP response according to RFC 3428 [14];

– extract the payload encoded according to 3GPP TS 24.011 [8] for RP-DATA; and

– create a delivery report as described in clause 5.3.2.4. The content of the report is defined in 3GPP TS 24.011 [8].

5.3.2.4 Sending a delivery report

When an SM-over-IP receiver wants to send an SM delivery report over IP, the SM-over-IP receiver shall send a SIP MESSAGE request with the following information:

a) the Request-URI, which shall contain the IP-SM-GW;

NOTE 1: The address of the IP-SM-GW is received in the P-Asserted-Identity header in the SIP MESSAGE request including the delivered short message.

b) the From header, which shall contain a public user identity of the SM-over-IP receiver.

c) the To header, which shall contain the IP-SM-GW;

d) the In-Reply-To header which shall contain the Call-Id of the SIP MESSAGE request that was received in the received short message;

e) the Content-Type header shall contain "application/vnd.3gpp.sms"; and

f) the body of the request shall contain the RP-ACK or RP-ERROR message for the SM delivery report, as defined in 3GPP TS 24.011 [8].

NOTE 2: The SM-over-IP sender will use content transfer encoding of type "binary" for the encoding of the SM in the body of the SIP MESSAGE request.

5.3.2.5 Sending a notification about SM-over-IP receiver having memory available

When an SM-over-IP receiver wants to send a notification about UE having memory available, the SM-over-IP receiver shall send a SIP MESSAGE request with the following information:

a) the Request-URI, which shall contain the IP-SM-GW address, if available, and shall contain PSI of the SC otherwise;

NOTE 1: The address of the IP-SM-GW is received in the P-Asserted-Identity in the SIP MESSAGE request that included the short message the UE could not store.

b) the From header, which shall contain a public user identity of the SM-over-IP receiver;

c) the To header, which shall contain the IP-SM-GW address, if available, and shall contain PSI of the SC, otherwise;

d) the Content-Type header shall contain "application/vnd.3gpp.sms"; and

e) the body of the request shall contain an RP-SMMA message, see 3GPP TS 24.011 [8], including the SMS headers and the SMS user information encoded as specified in 3GPP TS 23.040 [3].

NOTE 2: The SM-over-IP receiver will use content transfer encoding of type "binary" for the encoding of the SMS in the body of the SIP MESSAGE request.

NOTE 3: According to 3GPP TS 23.204 [5], the IP-SM-GW routes SIP MESSAGE requests containing a notification of UE having memory available (containing RP-SMMA as the body) towards the HSS and routes other SIP MESSAGE requests (containing RP-DATA, RP-ACK or RP-ERROR as the body) towards SMS-IWMSC.

5.3.2.6 SM-over-IP receiver procedures for operation without MSISDN

5.3.2.6.1 General

This clause specifies the procedures for the SM-over-IP receiver to support the MSISDN less operation.

An SM-over-IP receiver supporting the procedures in this clause shall support:

a) procedures specified in clause 5.3.2.1; and

b) the In-Reply-To header field.

5.3.2.6.2 Registration

On sending a REGISTER request, a SM-over-IP receiver that supports the MSISDN less operation shall include a "+g.3gpp.smsip-msisdnless" media feature tag into the Contact header field according to RFC 3840 [16]..

NOTE: When in MSISDN less operation the SM-over-IP receiver gets the address of the originating side from the received XML document that is included in the body of the SIP MESAGE request.

5.3.2.6.3 Delivery of a short message

When a SIP MESSAGE request including a "vnd.3gpp.sms" MIME body is received then the SM-over-IP receiver shall:

1) generate a SIP response according to RFC 3428 [14];

2) extract the payload encoded according to 3GPP TS 24.011 [8] for RP-DATA;

3) check if the received short message contains a TP-OA field is set to the dummy MSISDN value as defined in 3GPP TS 23.003 [22]. If the TP-OA does not contain the dummy MSISDN value, then continue with the procedures in clause 5.3.2.4. If the TP-OA contains the dummy MSISDN value, then continue with the next steps;

4) check if the received SIP MESSAGE contains a Feature-Caps header field with a "+g.3gpp.smsip-msisdn-less" header field parameter. If it is present then continue with the following steps, otherwise discard the received SIP MESSAGE and skip the following steps; and

5) create a delivery report for the received short message. In order to do so send a SIP MESSAGE as follows:

a) the Request-URI, which shall contain the address of the IP-SM-GW;

NOTE 1: The address of the IP-SM-GW is received in the P-Asserted-Identity header field in the received SIP MESSAGE request.

b) the From header field, which shall contain a public user identity of the SM-over-IP receiver;

c) the To header field, which shall contain the address of IP-SM-GW;

d) the In-Reply-To header field which shall contain the Call-Id of the received SIP MESSAGE;

e) the Content-Type header, which shall contain "multipart/mixed";

f) application/vnd.3gpp.sms+xml MIME body as described in clause D.1 with a Content-Disposition header field set to "render" and with "handling" header field parameter set to "optional". The XML document shall contain a single <To> element which contains the URI of the receiver of the short message delivery report; and

NOTE 2: The address of the receiver of the delivery report is taken from the <From> element of the xml document that has been received in the related SIP MESSAGE request.

g) application/vnd.3gpp.sms MIME body containing the RP-ACK or RP-ERROR message for the SM delivery report as defined in 3GPP TS 24.011 [8].

NOTE 3: The SM-over-IP sender will use content transfer encoding of type "binary" for the encoding of the SM in the body of the SIP MESSAGE request.

5.3.2.6.4 Sending a notification about SM-over-IP receiver having memory available

When an SM-over-IP receiver wants to send a notification about UE having memory available, then the SM-over-IP receiver shall implement the procedures of clause 5.3.2.5.

5.3.3 IP-Short-Message-Gateway (IP-SM-GW)

5.3.3.1 General

An IP-SM-GW for transport layer interworking provides the protocol interworking for the submission of short messages from the SM-over-IP sender to the SC, for the delivery of short messages from the SC to the SM-over-IP receiver, and for the SMS-Status Reports from the SC to the SM-over-IP sender.

An IP-SM-GW in MSISDN less operation provides for SIP MESSAGE based submission of short messages from the SM-over-IP sender to the SM-over-IP receiver, of SMS Submit Reports to the SM-over-IP sender and SMS-Status Reports to the SM-over-IP sender.

In addition to the procedures specified in clause 5.3.3, the IP-SM-GW shall support the procedures specified in clause 5.7 in 3GPP TS 24.229 [10].

5.3.3.2 Indication of SM-over-IP receiver availability status for delivery of short messages

NOTE 1: If operator policy does not require the indication the availability status of public user identity for receiving SMS over IP messages, then IP-SM-GW will not receive third-party REGISTER request.

Upon receipt of a third-party REGISTER request, the IP-SM-GW shall:

– send a 200 (OK) response for the REGISTER request;

– if an MSISDN is received in the message body of the third party REGISTER request within the <service-info> XML element, store the MSISDN sent in the message body of the REGISTER request within the <service-info> XML element.

– if no MSISDN is received,

a) if an Authorization header field was contained in the REGISTER request received from the UE that is contained in a "message/sip" MIME body of the third party REGISTER request, derive the IMSI from the private user identity obtained from the "username" header field parameter of the Authorization header field in the REGISTER request received from the UE that is contained in a "message/sip" MIME body of the third party REGISTER request; or

b) if no Authorization header field was contained in the REGISTER request received from the UE that is contained in a "message/sip" MIME body of the third party REGISTER request derive the IMSI from the public user identity obtained from the "To" header field in the REGISTER request received from the UE that is contained in a "message/sip" MIME body of the third party REGISTER request; and

NOTE 2: The actual format of the <service-info> element is transparent to the S-CSCF.

NOTE 3: The relation between private user identity and the IMSI is defined in 3GPP TS 23.003 [22].

NOTE 4: 3GPP TS 24.229 [10] specifies how the REGISTER request from the UE can be included in the third party REGISTER request.

– subscribe to the reg event package for the public user identity registered at the user’s registrar (S-CSCF) as described in RFC 3680 [15] and RFC 6665 [27].

Upon receipt of a NOTIFY request the IP-SM-GW shall check the availability status for receiving SMS over IP messages, i.e. if the public user identity has a contact registered with the ability to receive SMS over IP messages. If the availability status of the public user identity for receiving SMS over IP messages has changed, the IP-SM-GW shall start a data update procedure to the HSS as specified in 3GPP TS 29.002 [11] to indicate that either the MSISDN or IMSI registered with it is available/unavailable for delivery of SMS.

5.3.3.3 Answering routing information query

If a routing information query is received from the HSS/HLR, the IP-SM-GW shall extract the MSISDN of the SM-over-IP receiver (destination UE) from the received message. If the IP-SM-GW has information about a public user identity associated with the MSISDN, the IP-SM-GW shall return its own address to the SMS-GMSC that originated the routing information query.

If the IP-SM-GW has no information related to the MSISDN of the SM-over-IP receiver (destination UE), the IP-SM-GW shall query the HSS/HLR for routing information. If the query results in an error response, the IP-SM-GW shall return the error response to the SMS-GMSC; otherwise the IP-SM-GW shall return its own address to the SMS-GMSC that originated the routing information query.

NOTE: The address of the SMS-GMSC is available in the received routing information query.

5.3.3.4 Transport layer interworking

5.3.3.4.1 Receiving a short message in a SIP MESSAGE request

NOTE 1: The SIP MESSAGE received from the SM-over-IP sender/receiver will include a P-Asserted-Identity header (as defined in RFC 3325 [13]) containing a tel URI of the SM-over-IP sender/receiver and will contain either a short message (RP-DATA), or a notification for availability of memory (RP-SMMA), or a delivery report (RP-ACK or RP-ERROR).

If a SIP MESSAGE request including "vnd.3gpp.sms" payload is received from the SM-over-IP sender/receiver and the IP-SM-GW does not support the In-Reply-To header usage, the IP-SM-GW shall:

1) respond with a 202 (Accepted) response;

2) extract and validate the format of the SC address from the received payload as defined in 3GPP TS 24.011 [8] and 3GPP TS 23.040 [3];

3) extract the RPDU type (see 3GPP TS 24.011 [8]) from the received payload;

4) add the MSISDN of the SM-over-IP receiver to the RP International Mobile Subscriber Identity field if the received payload is a notification for availability of memory. If the MSISDN of the SM-over-IP receiver is not available then insert the tel URI received in a P-Asserted-Identity header (as defined in RFC 3325 [13]) placed in the SIP MESSAGE request by the P-CSCF or S-CSCF; and

NOTE 2: The MSISDN is not available if the registration is not required according to the operator policy.

5) include the RPDU type in the appropriate message to

– the SC via SMS-IWMSC in case of a short message;

– the SC via SMS-GMSC in case of a delivery report; or

– the HSS in case of a notification for availability of memory.

If step 2) or 3) above fails for message that contains RPDU with RP-DATA or RP-SMMA content, the IP-SM-GW shall send a SIP MESSAGE request with the following information:

a) the Request-URI, containing the sending user’s URI;

b) the Content-Type header, set to "application/vnd.3gpp.sms"; and

c) the body of the request containing an RP-ERROR message including an appropriate error code as defined in 3GPP TS 24.011 [8].

NOTE 3: The IP-SM-GW will use content transfer encoding of type "binary" for the encoding of the SM in the body of the SIP MESSAGE request.

If a SIP MESSAGE request including "vnd.3gpp.sms" payload is received from the sender/receiver, and the IP-SM-GW supports the In-Reply-To header, the IP-SM-GW shall:

1) if the SIP MESSAGE does not include the In-Reply-To header:

a) respond with a 202 (Accepted) response;

b) extract and validate the format of the SC address from the received payload as defined in 3GPP TS 24.011 [8] and 3GPP TS 23.040 [3];

c) extract the RPDU type (see 3GPP TS 24.011 [8]) from the received payload;

d) the MSISDN of the SM-over-IP receiver to the RP International Mobile Subscriber Identity field if the received payload is a notification for availability of memory. If the MSISDN of the SM-over-IP receiver is not available then insert the tel URI received in a P-Asserted-Identity header (as defined in RFC 3325 [13]) placed in the SIP MESSAGE request by the P-CSCF or S-CSCF; and

NOTE 4: The MSISDN is not available if the registration is not required according to the operator policy.

e) include the RPDU type in the appropriate message to

– the SC via SMS-IWMSC in case of a short message;

– the SC via SMS-GMSC in case of a delivery report; or

– the HSS in case of a notification for availability of memory.

If step b) or c) above fails for message that contains RPDU with RP-DATA or RP-SMMA content, the IP-SM-GW shall send a SIP MESSAGE request with the following information:

– the Request-URI, containing the sending user’s URI;

– the Content-Type header, set to "application/vnd.3gpp.sms"; and

– the body of the request containing an RP-ERROR message including an appropriate error code as defined in 3GPP TS 24.011 [8].

NOTE 5: The IP-SM-GW will use content transfer encoding of type "binary" for the encoding of the SM in the body of the SIP MESSAGE request.

1) if the SIP MESSAGE includes the In-Reply-To header:

a) if the In-Reply-To header indicates that the request does not correspond to a short message submitted by the IP-SM-GW, send a 488 (Not Acceptable here) SIP response according to RFC 3428 [14];

b) if the In-Reply-To header indicates that the request corresponds to a short message submitted by the IP-SM-GW:

– generate a 202 (Accepted) SIP response according to RFC 3428 [14];

– extract and validate the format of the SC address from the received payload as defined in 3GPP TS 24.011 [8] and 3GPP TS 23.040 [3];

– extract the RPDU type (see 3GPP TS 24.011 [8]) from the received payload;

– add the MSISDN of the SM-over-IP receiver to the RP International Mobile Subscriber Identity field if the received payload is a notification for availability of memory. If the MSISDN of the SM-over-IP receiver is not available then insert the tel URI received in a P-Asserted-Identity header (as defined in RFC 3325 [13]) placed in the SIP MESSAGE request by the P-CSCF or S-CSCF; and

NOTE 6: The MSISDN is not available if the registration is not required according to the operator policy.

– include the RPDU type in the appropriate message within the same MAP dialog delivering the short message to

– the SC via SMS-GMSC in case of a delivery report; or

– the HSS in case of a notification for availability of memory.

NOTE 7: The IP-SM-GW finding the MAP dialog using the SIP session identified by the Call-ID contained in the In-Reply-To header.

if step 2) or 3) above fails for message that contains RPDU with RP-SMMA content, the IP-SM-GW shall send a SIP MESSAGE request with the following information:

– the Request-URI, containing the sending user’s URI;

– the Content-Type header, set to "application/vnd.3gpp.sms"; and

– the body of the request containing an RP-ERROR message including an appropriate error code as defined in 3GPP TS 24.011 [8].

NOTE 8: The IP-SM-GW will use content transfer encoding of type "binary" for the encoding of the SM in the body of the SIP MESSAGE request.

5.3.3.4.2 Delivering a short message in a SIP MESSAGE request

If a short message is received from the SMS-GMSC, the IP-SM-GW shall extract the IMSI of the SM-over-IP receiver from the received message. Then the IP-SM-GW shall send a SIP MESSAGE request with the following information:

a) the Request-URI, which shall contain a public user identity of the SM-over-IP receiver associated with the received IMSI;

b) the Accept-Contact header, which shall contain a "+g.3gpp.smsip" parameter and the "explicit" and "require" tags according to RFC 3841 [17];

c) the Request-Disposition header which shall contain the "no-fork" directive;

d) the P-Asserted-Identity header which shall contain the SIP URI of the IP-SM-GW;

e) the Content-Type header which shall contain "application/vnd.3gpp.sms"; and

f) the body of the request which shall contain an RP-DATA message as defined in 3GPP TS 24.011 [8], including the SMS headers and the SMS user information encoded as specified in 3GPP TS 23.040 [3].

NOTE 1: The IP-SM-GW will use content transfer encoding of type "binary" for the encoding of the SM in the body of the SIP MESSAGE request.

If the IP-SM-GW cannot deliver the short message successfully in a SIP MESSAGE request and cannot deliver the short message via SGSN or MSC, then the IP-SM-GW will apply the procedures defined in 3GPP TS 29.311 [23] clause 6.1.4.4.1 to send a delivery report to SC via SMS-GMSC.

NOTE 2: If routing information is available (SGSN or MSC address or both), the IP-SM-GW can also attempt the delivery of a short message via SGSN or MSC or both before sending a delivery report to SC via SMS-GMSC. The priority order of these attempts (i.e., SMS over IP, SMS over CS, SMS over PS) is subject to operator policy. However, if no MSISDN is present in the short message then no routing information is obtainable by the IP-SM-GW, and attempting delivery of the short message via other domains (e.g. MSC, SGSN) by the IP-SM-GW is not possible.

5.3.3.4.3 Forwarding a submit report in a SIP MESSAGE request

If an SM submit report is received from the SMS-IWMSC, the IP-SM-GW shall retrieve the IMSI of the SM-over-IP sender from the existing MAP context. Then the IP-SM-GW shall obtain a corresponding public user identity and send a SIP MESSAGE request with the following information:

a) the Request-URI, which shall contain a public user identity of the SM-over-IP sender;

b) the Accept-Contact header, which shall contain a "+g.3gpp.smsip" parameter and the "explicit" and "require" tags according to RFC 3841 [17];

c) the Request-Disposition header which shall contain the "fork" and optionally the "parallel" directives;

d) the In-Reply-To header which shall contain the Call-Id of the SIP MESSAGE request that included the submitted short message;

e) the P-Asserted-Identity header which shall contain the SIP URI of the IP-SM-GW;

f) the Content-Type header which shall contain "application/vnd.3gpp.sms"; and

g) the body of the request which shall contain an RP-ACK or RP-ERROR message as defined in 3GPP TS 24.011 [8].

NOTE: The IP-SM-GW will use content transfer encoding of type "binary" for the encoding of the SM in the body of the SIP MESSAGE request.

5.3.3.4.4 Delivering a status report in a SIP MESSAGE request

If a status report is received from the SMS-GMSC, the IP-SM-GW shall extract the IMSI of the SM-over-IP sender from the received message. Then the IP-SM-GW shall send a SIP MESSAGE request with the following information:

a) the Request-URI, which shall contain a public user identity of the SM-over-IP sender associated with the received IMSI;

b) the Accept-Contact header, which shall contain a "+g.3gpp.smsip" parameter and the "explicit" and "require" tags according to RFC 3841 [17];

c) the Request-Disposition header which shall contain the "no-fork" directive;

NOTE 1: The status report is always sent to the SMS capable UE that registered with the highest q value.

d) the Content-Type header which shall contain "application/vnd.3gpp.sms"; and

e) the body of the request which shall contain an RP-DATA message as defined in 3GPP TS 24.011 [8], including the SMS headers and the SMS user information encoded as specified in 3GPP TS 23.040 [3].

NOTE 2: The IP-SM-GW will use content transfer encoding of type "binary" for the encoding of the SM in the body of the SIP MESSAGE request.

If the IP-SM-GW cannot deliver the status report successfully in a SIP MESSAGE request and cannot deliver the short message via SGSN or MSC, then the IP-SM-GW will apply the procedures defined in 3GPP TS 29.311 [23] clause 6.1.4.4.1 to send a delivery report to SC via SMS-GMSC.

NOTE 3: If routing information is available (SGSN or MSC address or both), the IP-SM-GW can also attempt the delivery of a short message via SGSN or MSC or both before sending a delivery report to SC via SMS-GMSC. The priority order of these attempts (i.e., SMS over IP, SMS over CS, SMS over PS) is subject to operator policy.

NOTE 4: The SM-over-IP sender will acknowledge the status report with a delivery report.

5.3.3.5 IP-SM-GW procedures for operation without MSISDN

5.3.3.5.1 General

This clause specifies the procedures for the IP-SM-GW to support the MSISDN less operation.

An IP-SM-GW supporting the procedures in this clause shall support the In-Reply-To header field.

5.3.3.5.2 Receiving a short message in a SIP MESSAGE request from a SM-over-IP sender or SM-over-IP receiver

If a SIP MESSAGE request is received from the sender/receiver including a"vnd.3gpp.sms" MIME body; then the IP-SM-GW shall:

1) if the SIP MESSAGE request does not include the In-Reply-To header field:

a) respond with a 202 (Accepted) response according to RFC 3428 [14];

b) extract and validate the format of the SC address from the received payload as defined in 3GPP TS 24.011 [8] and 3GPP TS 23.040 [3];

c) extract the RPDU type (see 3GPP TS 24.011 [8]) from the received payload. If the received payload is a notification for availability of memory then include the RPDU in the appropriate message to the HSS an skip the following steps; and

d) extract the TP-DA field and check if the the TP-DA field it is set to the dummy MSISDN as defined in 3GPP TS 23.003 [22]. If the value is not set to the dummy MSISDN then continue with the procedures specified in clause 5.3.3.4.1. Otherwise the IP-SM-GW shall based on local policy determine whether the procedures in this clause are to be employed and shall:

NOTE 1: Local policy can e.g. include subscriber specific authorization and can include information support in the terminating side network.

A) construct a SMS-DELIVER from the received SMS-SUBMIT. The TP-OA field shall be set to the dummy MSISDN value as defined in 3GPP TS 23.003 [22];

B) set the Request-URI for the MESSAGE to be sent to what has been received in the <To> element in the received XML document;

C) set the To header field to the same value as contained in the Request-URI;

D) set the P-Asserted-Identity header field to its own SIP URI;

E) set the From header field to its own SIP URI;

G) include a Feature-Caps header field with a "+g.3gpp.smsip-msisdn-less" header field parameter;

H) set the Content-Type header, which shall contain "multipart/mixed";

I) include an application/vnd.3gpp.sms+xml MIME body as described in clause D.1 with a Content-Disposition header field set to "render" and with "handling" header field parameter set to "optional". The XML document shall contain a single <From> element which contains the URI of the sender of the short message. The URI of the sender is taken from the P-Asserted-Identity header field of the related received SIP MESSAGE request;

J) include an application/vnd.3gpp.sms MIME body containing the RP-DATA message as defined in 3GPP TS 24.011 [8], including the SMS headers and the SMS user information encoded as specified in 3GPP TS 23.040 [3] with a TP-DA field set to the dummy MSISDN value as defined in 3GPP TS 23.003 [22]; and

K) send the so created SIP MESSAGE request towards the terminating side IP-SM-GW.

If step b) or c) above fails for message that contains RPDU with RP-DATA content, the IP-SM-GW shall send a SIP MESSAGE request with the following information:

A) the Request-URI, containing the sending user’s URI;

B) the Content-Type header, which shall contain "multipart/mixed";

C) include a Feature-Caps header field with a "+g.3gpp.smsip-msisdn-less" header field parameter;

D) include an application/vnd.3gpp.sms+xml MIME body as described in clause D.1 with a Content-Disposition header field set to "render" and with "handling" header field parameter set to "optional". The XML document shall contain a single <From> element which contains the URI of the sender of the short message; and

E) include an application/vnd.3gpp.sms MIME body containing the RP-ERROR message including an appropriate error code as defined in 3GPP TS 24.011 [8], including the SMS headers and the SMS user information encoded as specified in 3GPP TS 23.040 [3].

NOTE 2: The IP-SM-GW will use content transfer encoding of type "binary" for the encoding of the SM in the body of the SIP MESSAGE request.

If the IP-SM-GW decides to not forward the received SIP MESSAGE request, the IP-SM-GW shall send a SIP MESSAGE request with the following information:

A) the Request-URI, containing the sending user’s URI;

B) the Content-Type header, which shall contain "multipart/mixed";

C) include a Feature-Caps header field with a "+g.3gpp.smsip-msisdn-less" header field parameter;

NOTE 3: The IP-SM-GW will use content transfer encoding of type "binary" for the encoding of the SM in the body of the SIP MESSAGE request.

2) if the SIP MESSAGE request includes the In-Reply-To header field:

a) if the In-Reply-To header field indicates that the request does not correspond to a short message submitted by the IP-SM-GW, send a 488 (Not Acceptable here) SIP response according to RFC 3428 [14];

b) if the In-Reply-To header field indicates that the request corresponds to a short message submitted by the IP-SM-GW and the IP-SM-GW has used clause 5.3.3.5.3 procedures for delivery of the short message:

A) generate a 202 (Accepted) SIP response according to RFC 3428 [14];

B) extract and validate the format of the SC address from the received payload as defined in 3GPP TS 24.011 [8] and 3GPP TS 23.040 [3];

C) extract the RPDU type (see 3GPP TS 24.011 [8]) from the received payload;

D) construct a new new payload based on the received payload;

E) set the R-URI of the SIP MESSAGE request to the address of the entity that has sent the related SIP MESSAGE request identified via the context that relates to the In-Reply-To header field;

F) set the To header field to the same value as contained in the Request-URI;

G) set the P-Asserted-Identity header field to its own SIP URI;

H) set the From header field to its own SIP URI;

I) include a Feature-Caps header field with a "+g.3gpp.smsip-msisdn-less" header field parameter;

I) set the Content-Type header, which shall contain "multipart/mixed";

J) include an application/vnd.3gpp.sms MIME body containing the the RPDU type in the SIP MESSAGE request ;

NOTE 4: The RPDU contains a delivery report.

K) include an application/vnd.3gpp.sms+xml MIME body as described in clause D.1 with a Content-Disposition header field set to "render" and with "handling" header field parameter set to "optional". The XML document shall contain a single <From> element which contains the URI of the sender of the short message. The URI of the sender is taken from the P-Asserted-Identity header field of the related received SIP MESSAGE request; and

L) send the so created SIP MESSAGE request.

5.3.3.5.3 Delivering a short message in a SIP MESSAGE request to a SM-over-IP receiver

If a short message contained in a SIP MESSAGE request is received that has been sent by the originating side IP-SM-GW as specified in clause 5.3.3.5.2, the IP-SM-GW shall send a SIP MESSAGE request with the following information:

1) the Request-URI, which shall contain a public user identity as received from the originating side;

2) the Accept-Contact header field, which shall contain a "+g.3gpp.smsip-msisdn-less" parameter and the "explicit" and "require" tags according to RFC 3841 [17];

3) the Request-Disposition header field which shall contain the "no-fork" directive;

4) the From header field which shall contain the SIP URI of the IP-SM-GW;

5) the P-Asserted-Identity header field which shall contain the SIP URI of the IP-SM-GW;

6) include a Feature-Caps header field with a "+g.3gpp.smsip-msisdn-less" header field parameter;

7) set the Content-Type header, which shall contain "multipart/mixed";

8) include an application/vnd.3gpp.sms MIME body containing the RP-DATA message as defined in 3GPP TS 24.011 [8], including the SMS headers and the SMS user information encoded as specified in 3GPP TS 23.040 [3] as received in the incoming SIP MESSAGE request; and

NOTE 1: The IP-SM-GW will use content transfer encoding of type "binary" for the encoding of the SM in the body of the SIP MESSAGE request.

9) include an application/vnd.3gpp.sms+xml MIME body as described in clause D.1 with a Content-Disposition header field set to "render" and with "handling" header field parameter set to "optional". The XML document shall contain a single <From> element which contains the URI of the sender of the short message.

When the IP-SM-GW receives any 4xx, 5xx, or 6xx response to a SIP MESSAGE, the IP-SM-GW shall send a SIP MESSAGE with the following information:

1) a Request-URI, which shall contain the identity as received in the P-Asserted-Identity in the related SIP MESSAGE request from the originating side;

2) a From header field which shall contain the SIP URI of the IP-SM-GW;

3) a P-Asserted-Identity header field which shall contain the SIP URI of the IP-SM-GW;

4) a Feature-Caps header field with a "+g.3gpp.smsip-msisdn-less" header field parameter;

5) a Content-Type header as specified in RFC 5621 [25], which shall contain "multipart/mixed";

6) an application/vnd.3gpp.sms MIME body containing the RP-ERROR message as defined in 3GPP TS 24.011 [8], including the SMS headers and the SMS user information encoded as specified in 3GPP TS 23.040 [3] as received in the incoming SIP MESSAGE request; and

NOTE 3: The IP-SM-GW will use content transfer encoding of type "binary" for the encoding of the SM in the body of the SIP MESSAGE request.

7) an application/vnd.3gpp.sms+xml MIME body as described in clause D.1 with a Content-Disposition header field set to "render" and with "handling" header field parameter set to "optional". The XML document shall contain a single <Correlation-ID> element and a single <Delivery-Outcome> element set to "SMDeliveryFailure" as defined in annex C.1.3.

5.3.3.5.4 Delivering a delivery report in a SIP MESSAGE request

If a deliver report contained in a SIP MESSAGE request is received that has been sent by the terminating side IP-SM-GW as specified in clause 5.3.3.5.2 and the IP-SM-GW decides to send a status report to the SM-over-IP-sender as specified in 3GPP TS 23.040 [3], the IP-SM-GW shall send a SIP MESSAGE request with the following information:

1) the Request-URI, which shall contain a public user identity as received in the related SIP MESSAGE request;

2) the Accept-Contact header field, which shall contain a "+g.3gpp.smsip-msisdn-less" media feature tag and the "explicit" and "require" tags according to RFC 3841 [17];

3) the Request-Disposition header field which shall contain the "no-fork" directive;

4) the From header field which shall contain the content of the P-Asserted-Identity header field

5) the P-Asserted-Identity header field which shall contain the SIP URI of the IP-SM-GW;

6) the Content-Type header, which shall contain "multipart/mixed";

7) include a Feature-Caps header field with a "+g.3gpp.smsip-msisdn-less" header field parameter;

8) construct an SMS-STATUS-REPORT based on the received SMS-DELIVER-REPORT;

9) an application/vnd.3gpp.sms+xml MIME body as described in clause D.1 with a Content-Disposition header field set to "render" and with "handling" header field parameter set to "optional". The XML document shall contain a single <From> element which contains the URI of the sender of the short message; and

10) include an application/vnd.3gpp.sms MIME body containing the RP-DATA message as defined in 3GPP TS 24.011 [8], including the SMS headers and the SMS user information encoded as specified in 3GPP TS 23.040 [3] as received in the related SIP MESSAGE request.

NOTE 1: The IP-SM-GW will use content transfer encoding of type "binary" for the encoding of the SM in the body of the SIP MESSAGE request.

If a delivery report indicating no success contained in a SIP MESSAGE request is received that has been sent by the terminating side IP-SM-GW, the IP-SM-GW shall:

1) extract the received payload from the "vnd.3gpp.sms" payload; and

2) extract the received payload from the "vnd.3gpp.sms+xml" payload;

The IP-SM-GW will update the SC with the appropriate message as defined in 3GPP TS 29.002 [11]. The IP-SM-GW shall treat an unknown value in the <Delivery-Outcome> element as it treats the value "SMDeliveryFailure".

NOTE 2: The IP-SM-GW will send a MO_FORWARD_SM to the SC.

5.3.3.5.5 Delivering a submit report in a SIP MESSAGE request

The IP-SM-GW may support sending of SM submit report. When the IP-SM-GW sends a SM submit report, the IP-SM-GW shall support the procedures as specified in clause 5.3.3.4.3 starting with item a.

5.3.3.5.6 Procedures for receiving a SIP MESSAGE request from an IP-SM-GW

If a SIP MESSAGE request is received from another IP-SM-GW containing a"vnd.3gpp.sms" MIME body; then the IP-SM-GW shall:

NOTE 1: It is configuration specific how the IP-SM-GW finds out that a SIP MESSAGE request is received from another IP-SM-GW

1) send a SIP 202 (Accepted) response according to RFC 3428 [14];

2) save the SIP URI of the sending IP-SM-GW, contained in the P-Asserted-Identity header field of the received SIP MESSAGE request; and

3) deliver the received content to the SM-over-IP-receiver as described in clause 5.3.3.5.3 or SM-over-IP-sender as described in clause 5.3.3.5.4

If the IP-SM-GW cannot deliver the short message in a SIP MESSAGE request then the IP-SM-GW shall send a delivery report encapsulated in a SIP MESSAGE request to the originating side with the following information:

1) a Request-URI, which shall contain the identity as received in the P-Asserted-Identity in the related SIP MESSAGE request from the originating side;

2) a From header field which shall contain the SIP URI of the IP-SM-GW;

3) a P-Asserted-Identity header field which shall contain the SIP URI of the IP-SM-GW;

4) a Feature-Caps header field with a "+g.3gpp.smsip-msisdn-less" header field parameter;

5) a Content-Type header as specified in RFC 5621 [25], which shall contain "multipart/mixed";

NOTE 2: The IP-SM-GW will use content transfer encoding of type "binary" for the encoding of the SM in the body of the SIP MESSAGE request.

5.3.3.6 SIP failure case

When initiating a SIP failure response to any received SIP request, depending on operator policy, the IP-SM-GW may insert a SIP Response-Source header field in accordance with the procedures in clause 5.7.1.0 of 3GPP TS 24.229 [10], where the "role" header field parameter is set to "ip-sm-gw".

Annex A (normative):
Media feature tags defined within the current document