Content for TS 23.040 Word version: 18.0.0

0… 3… 3.3… 4… 8… 9… 9.2… 9.2.2.2… 9.2.2.3… 9.2.3… 9.2.3.12… 9.2.3.24 9.2.3.24.1… 9.2.3.24.10… 9.2.3.24.10.1.12… 9.2.3.24.10.2… 9.2.3.24.11… 9.2.3.25… 9.3… 10… 10.1.1… 10.1.3… 10.1.5… 10.1.7… 10.1.9… 10.1.11… 10.1.13… 10.1.15… 10.1.17… 10.2 10.2.1… 10.2.3… 10.2.5… 10.2.7… 10.3 11… A… C C.1… C.3… C.5… C.7… C.9… C.11… C.13… C.15… D… E… F… G… G.2… G.6 G.7 H… I… J… K…

3.1 Basic services 3.2 Short Message Service elements 3.2.0 Introduction 3.2.1 Validity-Period 3.2.2 Service-Centre-Time-Stamp 3.2.3 Protocol-Identifier 3.2.4 More-Messages-to-Send 3.2.5 Delivery of Priority and non-Priority Messages 3.2.6 Messages-Waiting 3.2.7 Alert-SC 3.2.7a MT Correlation ID 3.2.8 Options concerning MNRG, MNRF, UNRI, MNRR-MSC, MNRR-SGSN, UNRR, MCEF and MWD 3.2.9 Status report capabilities 3.2.10 Reply Path
...

3 Services and service elements p. 15

The SMS provides a means to transfer short messages between a GSM/UMTS MS and an SME via an SC. The SC serves as an interworking and relaying function of the message transfer between the MS and the SME.

The present document describes only the short message services between the MS and SC. It may, however, refer to possible higher layer applications.

3.1 Basic services p. 16

The Short Message Service comprise two basic services:

SM MT (Short Message Mobile Terminated);
SM MO (Short Message Mobile Originated).

SM MT denotes the capability of the GSM/UMTS system to transfer a short message submitted from the SC to one MS, and to provide information about the delivery of the short message either by a delivery report or a failure report with a specific mechanism for later delivery; see Figure 1.

SM MO denotes the capability of the GSM/UMTS system to transfer a short message submitted by the MS to one SME via an SC, and to provide information about the delivery of the short message either by a delivery report or a failure report. The message shall include the address of that SME to which the SC shall eventually attempt to relay the short message; see Figure 2.

The text messages to be transferred by means of the SM MT or SM MO contain up to 140 octets.

Copy of original 3GPP image for 3GPP TS 23.040, Fig. 1: The Short Message Service mobile terminated

Figure 1: The Short Message Service mobile terminated
(⇒ copy of original 3GPP image)

Copy of original 3GPP image for 3GPP TS 23.040, Fig. 2: The Short Message Service mobile originated

Figure 2: The Short Message Service mobile originated
(⇒ copy of original 3GPP image)

An active MS shall be able to receive a short message TPDU (SMS DELIVER) at any time, independently of whether or not there is a speech or data call in progress. A report shall always be returned to the SC; either confirming that the MS has received the short message, or informing the SC that it was impossible to deliver the short message TPDU to the MS, including the reason why.

An active MS shall be able to submit a short message TPDU (SMS SUBMIT) at any time, independently of whether or not there is a speech or data call in progress. A report shall always be returned to the MS; either confirming that the SC has received the short message TPDU, or informing the MS that it was impossible to deliver the short message TPDU to the SC, including the reason why.

It is also possible for two short messages to be received in sequence having the same originating address and identification, i.e. message reference number (MO) or SC Timestamp (MT). Such a situation may be due to errors at the RP or CP layers (e.g. during inter MSC handover) where it may be a duplicated message or otherwise it may be a valid new message.

The receiving entity should therefore make provision to check other parameters contained in the short message to decide whether the second short message is to be discarded.

3.2 Short Message Service elements p. 17

3.2.0 Introduction |R7| p. 17

The SMS comprises 8 elements particular to the submission and reception of messages:

Validity-Period;
Service-Centre-Time-Stamp;
Protocol-Identifier;
More-Messages-to-Send;
Priority;
Messages-Waiting;
Alert-SC.
MT Correlation ID.

3.2.1 Validity-Period p. 17

The Validity Period is the information element which gives an MS submitting an SMS SUBMIT to the SC the possibility to include a specific time period value in the short message (TP Validity Period field, see clause 9). The TP Validity Period parameter value indicates the time period for which the short message is valid, i.e. for how long the SC shall guarantee its existence in the SC memory before delivery to the recipient has been carried out.

3.2.2 Service-Centre-Time-Stamp p. 17

The Service Centre Time Stamp is the information element by which the SC informs the recipient MS about the time of arrival of the short message at the SM TL entity of the SC. The time value is included in every SMS DELIVER (TP Service Centre Time Stamp field, see clause 9) being delivered to the MS.

3.2.3 Protocol-Identifier p. 17

The Protocol Identifier is the information element by which the SM TL either refers to the higher layer protocol being used, or indicates interworking with a certain type of telematic device.

The Protocol Identifier information element makes use of a particular field in the message types SMS SUBMIT, SMS SUBMIT-REPORT for RP-ACK, SMS DELIVER DELIVER, SMS-DELIVER-REPORT for RP-ACK, SMS_STATUS_REPORT and SMS COMMAND TP Protocol Identifier (TP PID).

3.2.4 More-Messages-to-Send p. 17

The More Messages to Send is the information element by which the SC informs the MS that there is one or more messages waiting in that SC to be delivered to the MS. The More Messages to Send information element makes use of a Boolean parameter in the message SMS DELIVER, TP More Messages to Send (TP MMS).

3.2.5 Delivery of Priority and non-Priority Messages p. 17

Priority is the information element provided by an SC or SME to indicate to the PLMN whether or not a message is a priority message.

Delivery of a non priority message shall not be attempted if the MS has been identified as temporarily absent (see clause 3.2.6).

Delivery of a non priority message shall be attempted if the MS has not been identified as temporarily absent irrespective of whether the MS has been identified as having no free memory capacity (see clause 3.2.6).

Delivery of a priority message shall be attempted irrespective of whether or not the MS has been identified as temporarily absent, or having no free memory capacity.

3.2.6 Messages-Waiting p. 18

The Messages Waiting is the service element that enables the PLMN to provide the HLR, SGSN and VLR with which the recipient MS is associated with the information that there is a message in the originating SC waiting to be delivered to the MS. The service element is only used in case of previous unsuccessful delivery attempt(s) for non Single-short SM due to temporarily absent mobile or MS memory capacity exceeded. This information, denoted the Messages Waiting Indication (MWI), consists of Messages Waiting Data (MWD), the Mobile-station-Not-Reachable-for-GPRS (MNRG), the UE-Not-Reachable-for-IP (UNRI), the Mobile Station Not Reachable Flag (MNRF), the Mobile-Not-Reachable-via-the-MSC-Reason (MNRR-MSC), the Mobile-Not-Reachable-via-the-SGSN-Reason (MNRR-SGSN), the UE Not Reachable-Reason (UNRR) and the Mobile Station Memory Capacity Exceeded Flag (MCEF) located in the HLR; the Mobile-station-Not Reachable-for-GPRS (MNRG) located in the SGSN, and the Mobile Station Not Reachable Flag (MNRF) located in the VLR. Figure 3 shows an example.

Copy of original 3GPP image for 3GPP TS 23.040, Fig. 3: Example of how information on one MS can be put in relation to SC(s) in order to fulfil the requirement of Alert-SC mechanism

Figure 3: Example of how information on one MS can be put in relation to SC(s) in order to fulfil the requirement of Alert-SC mechanism
(⇒ copy of original 3GPP image)

The MWD shall contain a list of addresses (SC Addr) of SCs which have made previous unsuccessful delivery attempts of a message (see clause 5). In order to be able to send alert messages to every SC which has made unsuccessful delivery attempts for a non Single-shot SM to an MS, the HLR shall store the MSIsdn Alert or IMSI-Alert (see clause 3.2.7) together with references to the SC addresses. The requirements placed upon the HLR are specified in GSM TS 03.08 [6]. The description of how the HLR is provided with SC and MS address information is given in TS 29.002.

The Mobile Station Memory Capacity Exceeded Flag (MCEF) within the HLR is a Boolean parameter with the value TRUE an attempt to deliver a short message to an MS has failed with a cause of MS Memory Capacity Exceeded, and with the value FALSE otherwise.

The Mobile station Not Reachable-for-GPRS (MNRG) within the HLR and the SGSN is a Boolean parameter with the value TRUE when an attempt to deliver a short message to an MS has failed with a cause of Absent Subscriber, and with the value FALSE otherwise (except as described in note 1 below).

The Mobile Station Not Reachable Flag (MNRF) within the HLR and the VLR is a Boolean parameter with the value TRUE when the list MWD contains one or more list elements because an attempt to deliver a short message to an MS has failed with a cause of Absent Subscriber, and with the value FALSE otherwise.

The UE Not Reachable for-IP (UNRI) within the HLR/HSS and IP-SM-GW is a Boolean parameter with the value TRUE when the list MWD contains one or more list elements because an attempt to deliver a short message to an UE has failed with a cause of Absent Subscriber, and with the value FALSE otherwise.

The Mobile-Station-Not-Reachable-via-the-MSC-Reason (MNRR-MSC) within the HLR stores the reason for the MS being absent when an attempt to deliver a short message to an MS fails at the MSC with the cause Absent Subscriber. The HLR updates the MNRR-MSC with the reason for absence when an absent subscriber diagnostic information is received from the SMS-GMSC and the MNRF is set. The HLR clears the MNRR-MSC when the MNRF is cleared. If the MNRF is set due to a failure at the MSC with cause Absent Subscriber and information pertaining to the absence of the MS is not available from the SMS-GMSC, the MNRR-MSC shall remain in a cleared state. The MNRR-MSC shall either be in a cleared state or contain one of the following reasons:

No Paging Response via the MSC;

IMSI Detached.

The Mobile-Station-Not-Reachable-via-the-SGSN-Reason (MNRR-SGSN) within the HLR stores the reason for the MS being absent when an attempt to deliver a short message to an MS fails at the SGSN with the cause Absent Subscriber. The HLR updates the MNRR-SGSN with the reason for absence when an absent subscriber diagnostic information is received from the GMSC and the MNRG is set. The HLR clears the MNRR-SGSN when the MNRG is cleared. If the MNRG is set due to a failure at the SGSN with cause Absent Subscriber and information pertaining to the absence of the MS is not available from the GMSC, the MNRR-SGSN shall remain in a cleared state. The MNRR-SGSN shall either be in a cleared state or contain one of the following reasons:

No Paging Response via the SGSN;

GPRS Detached.

The UE-Station-Not-Reachable-Reason (UNRR) within the HSS/HLR stores the reason for the UE being absent when an attempt to deliver a short message to an UE fails at the IP-SM-GW with the cause Absent Subscriber. The HSS/HLR updates the UNRR with the reason for absence when an absent subscriber diagnostic information is received from the IP-SM-GW and the UNRI is set. The HSS/HLR clears the UNRR when the UNRI is cleared. If the UNRI is set due to a failure at the IP-SM-GW with cause Absent Subscriber, the UNRR shall remain in a cleared state. The UNRR shall either be in a cleared state or contain one of the following reasons:

No Response via the IP-SM-GW;

UE deregistered.

The MWD, MCEF, MNRR-MSC, MNRR-SGSN, MNRG, MNRF, UNRI and UNRR are updated in the following way:

1a)

When a mobile terminated short message delivery fails at the MSC due to the MS being temporarily absent (i.e. either IMSI DETACH flag is set or there is no response from the MS to a paging request via the MSC), the SC address is inserted into the MWD list (if it is not already present), the MNRF is set (if it is not already set) and the MNRR-MSC is updated (if the information is available), as described in clause 10.

1b)

When a mobile terminated short message delivery fails at the SGSN due to the MS being temporarily absent (i.e. either GPRS DETACH flag is set or there is no response from the MS to a paging request via the SGSN), the SC address is inserted into the MWD list (if it is not already present), the MNRG is set (if it is not already set) and the MNRR-SGSN is updated (if the information is available), as described in clause 10.

1c)

When a mobile terminated short message delivery fails at the MSC due to the MS memory capacity being exceeded, the SC address is inserted into the MWD list (if it is not already present),the MCEF is set (if it is not already set), the MNRF is cleared and the MNRR-MSC is cleared.

1d)

When a mobile terminated short message delivery fails at the SGSN due to the MS memory capacity being exceeded, the SC address is inserted into the MWD list (if it is not already present), the MCEF is set (if it is not already set), the MNRG is cleared and the MNRR-SGSN is cleared.

1e)

When a mobile terminated short message delivery fails due to the UE memory capacity via the IP-SM-GW being exceeded, the SC address is inserted into the MWD list (if it is not already present), the MCEF is set (if it is not already set), the UNRI is cleared and the UNRR is cleared.

1f)

If the MSIsdn or IMSI used by the SC to address the recipient MS for alerting purposes is different from the MSIsdn Alert or IMSI-Alert of the MS (see clause 3.2.7), the HLR returns the MSIsdn Alert or IMSI-Alert to the SC within the failure report, see "1c Failure report" in Figure 15 and Figure 16.

2a)

When either the HLR or VLR detects that the MS has recovered operation (e.g. has responded to a paging request over MSC), the HLR directly or on request of the VLR shall clear MNRF and MNRR-MSC. Then, if with a non empty MWD list and the MCEF clear, the HLR shall invoke operations to alert the SCs within the MWD (see clause 3.2.7 and clause 10). After each SC is alerted by the HLR, the address for that SC shall be deleted from the MWD. If the MCEF is set in the HLR, the HLR shall not invoke operations to alert the SCs within the MWD and data are not cleared from the MWD.

2b)

When either the HLR or SGSN detects that the MS has recovered operation (e.g. has responded to a paging request via the SGSN), the HLR directly or on request of the SGSN shall clear MNRG and MNRR-SGSN. Then, if with a non empty MWD list and the MCEF clear, the HLR shall invoke operations to alert the SCs within the MWD (see clause 3.2.7 and clause 10). After each SC is alerted by the HLR, the address for that SC is deleted from the MWD. If the MCEF is set in the HLR, the HLR shall not invoke operations to alert the SCs within the MWD and data are not cleared from the MWD.

2c)

When the IP-SM-GW informs the HLR/HSS that the UE is reachable for SMS over IP, either due to an IMS registration or due to the UE becoming available again, the HLR/HSS shall clear the UNRI and UNRR. Then, if with a non empty MWD list and the MCEF clear, the HLR/HSS shall invoke operations to alert the SCs within the MWD (see clause 3.2.7 and clause 10). After each SC is alerted by the HLR/HSS, the address for that SC is deleted from the MWD. If the MCEF is set in the HLR/HSS, the HLR/HSS shall not invoke operations to alert the SCs within the MWD and data are not cleared from the MWD.

2d)

When the HLR receives (via the MSC and the VLR) a notification that the MS (with a non empty MWD and the MCEF set in the HLR) has memory capacity available to receive one or more short messages, the HLR shall invoke operations to alert the SCs within the MWD (see clause 3.2.7 and clause 10). Once the Alert-SC operations have been invoked, the MNRF is cleared in the VLR and the MCEF, MNRF and MNRR-MSC are cleared in the HLR. After each SC is alerted by the HLR, the address for that SC is deleted from the MWD.

2e)

When the HLR receives (via the SGSN) a notification that the MS (with a non empty MWD and the MCEF set in the HLR) has memory capacity available to receive one or more short messages, the HLR shall invoke operations to alert the SCs within the MWD (see clause 3.2.7 and clause 10). Once the Alert-SC operations have been invoked, the MNRG is cleared in the SGSN and the MCEF, MNRG and MNRR-SGSN are cleared in the HLR. After each SC is alerted by the HLR, the address for that SC is deleted from the MWD.

2f)

When the HLR/HSS receives (via the IP-SM-GW) a notification that the UE (with a non empty MWD and the MCEF set in the HLR/HSS) has memory capacity available to receive one or more short messages, the HLR/HSS shall invoke operations to alert the SCs within the MWD (see clause 3.2.7 and clause 10). Once the Alert-SC operations have been invoked, the UNRI and UNRR are cleared in the HLR/HSS. After each SC is alerted by the HLR/HSS, the address for that SC is deleted from the MWD.

2g)

When the HLR receives from the SMS-GMSC a notification that a short message has been successfully delivered from an SC to an MS via the MSC for which the MCEF is set and the MWD are not empty, the HLR shall invoke operations to alert other SCs within the MWD (see clause 3.2.7 and clause 10). Once the Alert-SC operations have been invoked, the MCEF, MNRF and MNRR-MSC are cleared in the HLR. After each SC is alerted by the HLR, the address for that SC is deleted from the MWD. The SC which successfully delivered the message is also deleted from the MWD, if present.

2h)

When the HLR receives from the SMS-GMSC a notification that a short message has been successfully delivered from an SC to an MS via the SGSN for which the MCEF is set and the MWD are not empty, the HLR shall invoke operations to alert other SCs within the MWD (see clause 3.2.7 and clause 10). Once the Alert-SC operations have been invoked, the MCEF, MNRG and MNRR-SGSN are cleared in the HLR. After each SC is alerted by the HLR, the address for that SC is deleted from the MWD. The SC which successfully delivered the message is also deleted from the MWD, if present.

2i)

When the HLR receives (via the MSC and the VLR, or the SGSN) a notification that the MS has memory capacity available to receive one or more short messages but the MCEF is not set and the MWD are empty, the HLR acknowledges the notification but does not alert any service centre.

3.2.7 Alert-SC p. 21

The Alert-SC is the service element, which may be provided by some GSM/UMTS PLMNs, to inform the SC that an MS:

to which a delivery attempt has failed because the MS is not reachable or because the MS memory capacity was exceeded; and
which is now recognized by the PLMN:
1. to have resumed operation (e.g. to have responded to a paging request); or
2. to have memory newly available (which implies that the mobile is reachable).

is again ready to receive one or more short messages. The SC may on reception of an Alert-SC initiate the delivery attempt procedure for the queued messages destined for this MS.

To each MS there may be allocated one or more MSIsdns or External-Identifier(s). When the HLR is to alert an SC that an MS is again attainable it shall use a specific MSIsdn or IMSI corresponding to the External-Identifier for this purpose; in the present document called MSIsdn Alert or IMSI-Alert.

3.2.7a MT Correlation ID |R7| p. 21

The MT Correlation ID is a service element used only when the HPLMN of the receiving MS is using an SMS Router or an IP-SM-GW. It is used to correlate a Forward SM operation to a previous Info Retrieval operation.

Use of the MT Correlation ID enhances security. By analysing the Correlation ID received in a Forward Short message operation, it can be easily checked from where the associated Info Retrieval operation originated, thus resulting in detection of "fake" and "spoofed" SMs.

The MT Correlation ID is used in place of the IMSI in the IMSI IE at the protocol layer. Hence, its structure is defined to be exactly the same as this element.

The MT Correlation ID shall be composed as shown in Figure 3a below.

Copy of original 3GPP image for 3GPP TS 23.040, Fig. 3a: Structure of the MT Correlation ID

Figure 3a: Structure of the MT Correlation ID
(⇒ copy of original 3GPP image)

The MT Correlation ID is composed of three parts:

Mobile Country Code (MCC) of the HPLMN of the receiving MS. It consists of three decimal digits.
Mobile Network Code (MNC) of the HPLMN of the receiving MS. It consists of three decimal digits. If the MNC of the HPLMN of the receiving MS is 2 digits only in length, the first digit of the MSIN shall be appended to the right hand side.
Sender ID. It consists of nine decimal digits and shall be unique for its lifetime. For security purposes, its value shall be a number allocated at random, rather than sequentially.

An example of the MT Correlation ID is:

Sender ID: 569123006

IMSI in use: 234151234567890

Where:

MCC = 234;

MNC = 15;

MSIN = 1234567890,

Which gives the MT Correlation ID: 234151569123006.

3.2.8 Options concerning MNRG, MNRF, UNRI, MNRR-MSC, MNRR-SGSN, UNRR, MCEF and MWD p. 22

Setting the Mobile Station Not Reachable Flag (MNRF) in the VLR is mandatory. Setting the Mobile station Not-Reachable-for-GPRS (MNRG) in the SGSN is mandatory. It is mandatory for the VLR or the SGSN to send the "MS Reachable" message (see clause 10) to the HLR when the MS has been detected as becoming active and then to clear MNRF in the VLR or the MNRG in SGSN.

The Messages Waiting Data (MWD), the Mobile Station Not Reachable Flag (MNRF), the Mobile station Not-Reachable-for-GPRS (MNRG), the Mobile-Station-Not-Reachable-via-the-MSC-Reason (MNRR-MSC), the Mobile-Station-Not-Reachable-via-the-SGSN-Reason (MNRR-SGSN), and the Mobile Station Memory Capacity Exceeded Flag (MCEF) within the HLR are optional, but if one is implemented all must be implemented (except MNRG and MNRR-SGSN if the HLR does not support GPRS). This is linked to the transmission of the "Alert-SC" message.

The following describes what happens when a delivery fails.

Case 1: MWD, MNRF, MNRG, UNRI, MNRR-MSC, MNRR-SGSN, UNRR,and MCEF are implemented in the HLR.

In the case of a delivery failure (to an MS) with cause Absent Subscriber, the SMS-GMSC requests the HLR to add, if needed, a new entry in the MWD with cause Absent Subscriber. This new entry contains the SC address. The HLR sets its copy of the MNRF, MNRG or both and updates the MNRR-MSC, MNRR-SGSN or both (if the information is available). The SC is notified of the failure, the reason for the MS being absent and also of the MWD setting in the HLR within the Report message (see clause 10).

If a delivery through an IP-SM-GW fails (to an MS) with cause Mobile Station Memory Capacity Exceeded via the SGSN, IP-SM-GW, or the MSC, the IP-SM-GW requests the HSS to add, if needed, a new entry in the MWD with cause Mobile Station Memory Capacity Exceeded. This new entry contains the SC address. The HLR sets the MCEF and resets MNRF, MNRG, or UNRI. The SC is notified of the failure and also of the MWD setting in the HLR within the Report message (see clause 10).

In the case of a delivery failure (to an MS) with cause Mobile Station Memory Capacity Exceeded via the SGSN or the MSC, the SMS-GMSC or SMS Router requests the HLR to add, if needed, a new entry in the MWD with cause Mobile Station Memory Capacity Exceeded. This new entry contains the SC address. The HLR sets the MCEF and resets MNRF or MNRG. The SC is notified of the failure and also of the MWD setting in the HLR within the Report message (see clause 10).

If the HLR indicates that it is able to store the SC address, then the SC shall receive an Alert-SC message when the MS becomes active.

If the HLR indicates that it is unable to store the SC address (e.g. because MWD is full), then the only way to ensure delivery is for the SC to try to retransmit the message periodically.

When the HLR receives the MS Reachable message, if the MCEF is clear it sends an Alert-SC message to the concerned SC, updates MWD and clears MNRF (if the MS is reachable via the MSC) or MNRG (if the MS is reachable via the SGSN) or UNRI (if the MS is reachable via the IP-SM-GW).

When the HLR receives the MS Memory Capacity Available message, it sends an Alert-SC message to the concerned SC, updates MWD, clears the MCEF and clears MNRF (if the MS is reachable via the MSC), UNRI (if the UE is reachable via the IP-SM-GW) or MNRG (if the MS is reachable via the SGSN).

Case 2: MWD, MNRF, MNRG, MNRR-MSC, MNRR-SGSN and MCEF are not implemented in the HLR.

In the case of a delivery failure, the SC is notified that the HLR is unable to store its address in the MWD. In case of a delivery failure (to a MS) with cause Absent Subscriber, the SC is notified of the reason for the MS being absent (if the information is available). The SC must retransmit the short message periodically in order to ensure delivery.

The HLR discards the MS Reachable message received from the VLR or SGSN without any failure or error report.

The HLR discards the MS Memory Capacity Available message received from the MS via the MSC and the VLR or SGSN without any failure or error report.

3.2.9 Status report capabilities p. 23

The SMS also offers to the SC the capabilities of informing the MS of the status of a previously sent mobile originated short message. The status of the message can be:

Successfully delivered to the SME;
The SC was not able to forward the message to the SME. The reason can be an error of permanent or temporary nature. Permanent errors can be e.g. validity period expired, invalid SME address. Errors of temporary nature can be e.g. SC SME connection being down, SME temporarily unavailable.

This is achieved by the SC returning a status report TPDU (SMS STATUS REPORT) to the originating MS when the SC has concluded the status of the short message. The status report may be initiated by a status report request within the mobile originated short message. The status report TPDU is treated as an SMS DELIVER TPDU by the SC when it comes to delivery procedures e.g. the alerting mechanism.

The SC may also return to a non MS SME the status of a mobile terminated short message. This is however outside the scope of the present document.

The status report capabilities of the SMS are optional, i.e. the choice of whether to offer status report or not is left to the SC operator.

For reasons of resilience and/or load sharing architecture of SMSC's by network operators, the SMSC address (the RP OA) used by the SMSC to send the Status Report to the MS cannot be guaranteed to be the same SMSC address (RP-DA) used by the MS to submit the SM to which the Status Report refers. Where an MS wishes to implement a check that these addresses correlate, a means of disabling the correlation check shall be provided at the MS through MMI.

3.2.10 Reply Path p. 24

Reply Path specified in the present document provides a way of both requesting and indicating a service centre's commitment to deliver a reply from the replying MS to the originating SME.

Annex D deals with MS procedures, which in general are outside the scope of GSM/UMTS specifications. However, for advanced use of the SMS, including both application level protocols and human responses, it is of vital importance to guarantee that a reply supporting MS is able to reply on every SM, to every SME capable of receiving such reply short messages.