3 Services and service elements

23.0403GPPRelease 17Technical realization of the Short Message Service (SMS)TS

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

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.

Short message delivery

Report

Figure 1: The Short Message Service mobile terminated

Short message submission

Report

Figure 2: The Short Message Service mobile originated

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.

NOTE: When the transmission or reception of a short message coincide with a change of state in the MS, i.e. from busy to idle or from idle to busy, or during a handover, the short message transfer may be aborted.

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

3.2.0 Introduction

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

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

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

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

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

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

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.

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

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 3GPP TS 29.002 [15].

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.

NOTE 1: The MNRG can also be set in the HLR and in the SGSN after an unsuccessful attempt to invoke the network requested PDP-Context Activation procedure. In this case, no SC address is stored in MWD list (see 3GPP TS 23.060 [27]).

NOTE 2: When a short message delivery attempt fails at the HLR due to Roaming being Restricted, the MS being deregistered in HLR or the MS being Purged the absent subscriber diagnostic reason is returned to the SC, however the reason is not stored in the MNRR-MSC or MNRR-SGSN.

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 figures 15 and 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.

NOTE 3: The HLR can be in a situation where the MWD list is empty but where either MNRF or MNRG (with the related MNRR-MSC or MNRR-SGSN) is still set. This enables the HLR to return the correct address (MSC or SGSN address) at the next Send Routing Information Request from the SMS-GMSC.

NOTE 4: If the SMS delivery failed on first attempt via the MSC or the SGSN (see cases 1a for IMSI Detach and 1b for GPRS Detach), and is successful on the second attempt (see cases 2e and 2f), the SC address shall not be inserted into the MWD list

3.2.7 Alert‑SC

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

1) to which a delivery attempt has failed because the MS is not reachable or because the MS memory capacity was exceeded; and

2) which is now recognized by the PLMN:

a) to have resumed operation (e.g. to have responded to a paging request); or

b) 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.

NOTE 5: Repeated delivery attempts from the SC may be of two types:

i) A repeated delivery attempt because the SC has been informed that the MS is active and available to receive short messages.

ii) An autonomous repeated delivery attempt by the SC.

The application of these two options is defined by the providers of the SC and the network.

3.2.7a MT Correlation ID

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.

NOTE: Using an MT Correlation ID in place of the real IMSI has the added benefit of enhancing subscriber privacy in that the full IMSI is not shared with the HPLMN of the sending MS.

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

Figure 3a: Structure of the MT Correlation ID

The MT Correlation ID is composed of three parts:

1) Mobile Country Code (MCC) of the HPLMN of the receiving MS. It consists of three decimal digits.

2) 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.

3) 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

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.

NOTE: HLRs supporting SMSIP and having implemented MWD, MNRF, MNRG, MNRR, MCEF shall also implement UNRI and UNRR

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

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

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.

3.3 Unsuccessful short message TPDU transfer SC ‑> MS

3.3.0 General

Unsuccessful message transfer SC ‑> MS may be caused by a variety of different errors. The description of the occurrence of the different errors and how to handle and transfer the error indications is given in 3GPP TS 24.008 [12], 3GPP TS 24.011 [13] and 3GPP TS 29.002 [15].

The different error indications which the SMS‑GMSC shall be capable of returning to the SC following an unsuccessful short message TPDU transfer SC ‑> MS, are given in table 1. In some cases, additional diagnostic information may be provided.

3.3.1 Errors occurring during transfer of TPDU to MS

These errors are generally due to barring or unsupported service in the PLMN or MS. An error indication is returned to the SC from the SMS‑GMSC, but further diagnostic information from the MS shall not be available.

3.3.2 Errors occurring after TPDU arrives at MS

These errors may occur due to the MS not supporting optional short message service features, or in connection with a short message application. An error indication shall be returned to the SC from the SMS‑GMSC. Additionally, a TPDU (SMS‑DELIVER‑REPORT) containing diagnostic information may be conveyed from the MS to the originating SC, transparently through the PLMN, by means defined in 3GPP TS 24.011 [13] and 3GPP TS 29.002 [15]. The sending of the diagnostic information is optional at the MS, but when it is sent, the PLMN shall convey the information to the SC, and the SC shall support reception of the information.

Table 1: Error indications related to mobile terminated short message transfer which may be transferred to the originating SC

Error indication

S1)

Meaning

Unknown subscriber

P

The PLMN rejects the short message TPDU because there is not allocated an IMSI or a directory number for the mobile subscriber in the HLR (see 3GPP TS 29.002 [15]).

Teleservice not provisioned

P

The PLMN rejects the short message TPDU because the recipient MS has no SMS subscription (see 3GPP TS 29.002 [15]).

Call barred

T

The PLMN rejects the short message TPDU due to barring of the MS (see 3GPP TS 29.002 [15], description of the Barring supplementary service, 3GPP TS 22.004 [3] and 3GPP TS 23.011[7]), description of Call barred due to Unauthorised Message Originator, 3GPP TS 29.002 [15], and description of Operator Determined Barring, 3GPP TS 22.041 [4] and 3GPP TS 23.015 [8]).

Facility not supported

T

The VPLMN rejects the short message TPDU due to no provision of the SMS in the VPLMN (see 3GPP TS 29.002 [15]).

Absent subscriber

T

The PLMN rejects the short message TPDU because

– there was no paging response via the SGSN, MSC or both (see 3GPP TS 24.008 [12] & 3GPP TS 29.002 [15])

‑ the IMSI GPRS or both records are marked detached (see 3GPP TS 29.002 [15]);

‑ the MS is subject to roaming restrictions (see "Roaming not allowed", 3GPP TS 29.002 [15]);

– deregistered in the HLR. The HLR does not have an MSC, SGSN or both numbers stored for the target MS, (see 3GPP TS 29.002 [15]);

– Unidentified subscriber (see 3GPP TS 29.002 [15]);

– MS purged (see 3GPP TS 29.002 [15]) ;

– the MS is not registered in the HSS/HLR for IMS;

– there was no SIP response received by the IP-SM-GW;

– the MS is temporarily unavailable (e.g. in power saving mode due to eDRX).

(The reasons for absence are assigned integer values in table 1a. The appropriate integer value is sent with the absent subscriber error indication as defined in 3GPP TS 29.002 [15])

MS busy for MT SMS

T

The PLMN rejects the short message TPDU because of congestion encountered at the visited MSC or the SGSN. Possible reasons include any of the following events in progress:

– short message delivery from another SC;

– IMSI or GPRS detach

– Location Update or Inter SGSN Routing Area Update;

– paging;

– emergency call;

– call setup.

SMS lower layers
capabilities not provisioned

T

The PLMN rejects the short message TPDU due to MS not being able to support the Short Message Service.

The short message transfer attempt is rejected either due to information contained in the class‑mark, or the MSC not being able to establish connection at SAPI = 3 (see 3GPP TS 24.008 [12] and 3GPP TS 29.002 [15]).

Error in MS

T

The PLMN rejects the short message TPDU due to an error occurring within the MS at reception of a short message, e.g. protocol error.

Illegal Subscriber

P

The PLMN rejects the short message TPDU because the MS failed authentication.

Illegal Equipment

P

The PLMN rejects the short message TPDU because the IMEI of the MS was on the prohibited list in the EIR.

System failure

T

The PLMN rejects the short message TPDU due to network or protocol failure others than those listed above (see 3GPP TS 29.002 [15]).

Memory Capacity Exceeded

T

The MS rejects the short message since it has no memory capacity available to store the message.

1) : Status (Permanent or Temporary)

The relation between the two sets of error indications is given in the table 1. Each error is classified as either "Temporary" or "Permanent". This classification gives an indication of whether or not it is probable that the MS becomes attainable within a reasonable period, and so provides the recommended action to be taken by the SC, i.e. either to store the message for later transfer, or to discard it.

Table 1a: Assignment of values to reasons for absence
(values must be in the range of 0 to 255, see 3GPP TS 29.002 [15])

Values

Reason for absence

0

– no paging response via the MSC

1

– IMSI detached

2

– roaming restriction

3

– deregistered in the HLR for non GPRS

4

– MS purged for non GPRS

5

– no paging response via the SGSN

6

– GPRS detached

7

– deregistered in the HLR for GPRS

8

– MS purged for GPRS

9

– Unidentified subscriber via the MSC

10

– Unidentified subscriber via the SGSN

11

– deregistered in the HSS/HLR for IMS

12

– no response via the IP-SM-GW

13

the MS is temporarily unavailable

All ‘non GPRS’ reasons (except for roaming restriction) can be combined with all ‘GPRS’ reasons and vice-versa

All other integer values are reserved.

3.4 Unsuccessful short message TPDU transfer MS ‑> SC

The error indications related to mobile originated short message transfer which may be transferred to the originating MS are given in 3GPP TS 24.011 [13]. In some cases, additional diagnostic information may be provided.

3.4.1 Errors occurring during transfer of TPDU to SC

These errors are generally due to barring or unsupported service in the PLMN. An error indication is returned to the MS from the MSC or the SGSN, but further diagnostic information from the SC shall not be available.

3.4.2 Errors occurring after TPDU arrives at SC

These errors may occur due to the SC not supporting optional short message service features, or in connection with a short message application. An error indication shall be returned to the MS from the MSC or from the SGSN. Additionally, a TPDU (SMS‑SUBMIT‑REPORT) containing diagnostic information may be conveyed from the SC to the originating MS, transparently through the PLMN, as defined in 3GPP TS 29.002 [15] and 3GPP TS 24.011 [13]. The sending of the diagnostic information is optional at the SC, but when it is sent, the PLMN shall convey the information to the MS, and the MS shall support reception of the information.

Note: The SMS‑SUBMIT‑REPORT is part of the negative acknowledgement to the mobile originated short message, and is not part of the status report capabilities described in clause 3.2.9.

3.5 Use of Supplementary Services in combination with the Short Message Service

Only a sub‑set of the Supplementary Services defined in 3GPP TS 22.004 [3]and 3GPP TS 23.011 [7] may be used in combination with the Short Message Service. This sub‑set comprises the following Supplementary Services:

All the 5 Barring services.

3.6 Applicability of Operator Determined Barring to the Short Message Service

The network feature Operator Determined Barring (see 3GPP TS 22.041 [4]) applies to the Short Message Service.

If a short message fails due to operator determined barring then an appropriate error cause is returned to the originator.

3.7 Multiple short message transfer

To avoid the need for a mobile to be paged, authenticated etc. for each message waiting in the Service Centre, the SC may indicate to the SMS-GMSC that there are more messages to send. When this indication is given, MAP procedures are invoked such that this indication is passed to the VMSC, and the VMSC does not release the MS until all short messages waiting in the SC have been transferred.

3.8 SMS and Internet Electronic Mail interworking

The interworking between Internet electronic mail and SMS is offered in both directions which enables new and old mobiles to send/receive Internet electronic mails via SMS. The interworking is according to the following procedures:

– An SMS message which is required to interwork with Internet email may have its TP‑PID value set for Internet electronic mail;

NOTE: There is an alternative mechanism described in clause 9.2.3.24 providing full RFC 5322 [34] internet electronic mail interworking.

– Either single or concatenated SMS can be used to transport the email;

– Concatenation may be achieved by the TPUDH mechanism, in which case the concatenation is carried out at a lower level to the formats specified in clauses 3.8.1 and 3.8.2. Alternatively, concatenation may be achieved using the text‑based means described below;

– Email cc fields are not supported;

– Where multiple fields are present, additional spaces may be inserted by the sender to improve presentation of the message. Spaces may not be inserted into the actual email address (e.g. user@domain1.domain2).

3.8.1 Basic Format

The basic format for transferring email in either direction consists of the following:

MT SMS:

[<from‑address><space>]<message>

MO SMS:

[<to‑address><space>]<message>

where [] denote optional fields and <> delimit fields.

The to‑address or from address may take the form:

user@domain1.domain2

or

User Name <user@domain1.domain2>

In the latter case the angle brackets <> are part of the address and are actually transmitted.

Depending on the nature of the gateway, the destination/origination address is either derived from the content of the SMS TP‑OA or TP‑DA field, or the TP‑OA/TP‑DA field contains a generic gateway address and the to/from address is added at the beginning as shown above.

Multiple addresses may be identified in MO messages by separating each address by a comma like this:

address1,address2,address3<space><message>

It is optional for the receiving gateway to support this. If the receiving gateway does not support multiple messages then it shall reject the original message by returning an appropriate error in a text message.

3.8.2 Optional Fields

The following further optional fields are supported. An email <‑> SMS gateway may insert additional spaces in the MT message for presentation to the user, and must accept additional spaces in the MO message from the user.

3.8.2.1 Subject

The subject is placed between the address and the message, delimited by round brackets () or preceded by ##, for example:

[<to‑address>](<subject>)<message>

or

[<to‑address>]##<subject>#<message>

An MO message may contain either format. An MT message may contain either format. Developers must ensure that both forms are supported for full compatibility.

3.8.2.2 Real Name

The Real Name field contains the real name of the sender and is used only in MO messages. The SC or email gateway shall generate an email message according to standard email procedures containing Real Name <user@domain1.domain2> (the angle brackets being part of the address and hence transmitted). If a subject is to be included with the Real Name then only the ## prefix is used.

The syntax is:

[<to‑address>]#<real‑name>[##<subject>]#<message>

3.8.2.3 Optional Control Flag

An optional control flag may be added to the start of the message in MO messages only. This consists of a single character <CF> following a # symbol as follows:

[#<CF>#][<to‑address>]<space><message>

This may also be used in combination with the above fields. It is intended for use where a particular SC or email gateway specific function is required to be invoked. For example, the control flag #A# might add a particular (pre‑stored) signature to the end of the message or #R# might change the from‑address to a pre‑stored value or #5# might add the text "Please phone me at the office". All of these functions are open for definition by Service Centre or email gateway operators.

3.8.3 Text concatenation

If the concatenation mechanism described in clause 9.2.3.24.1 is not supported by the transmitting or receiving entity, the following textual concatenation mechanism may be used. The first message is ended with a + sign, and each subsequent message start and end with + signs until the final message which starts with a + sign but does not end with a + sign.

<message1>+

+<message2>+

+<message3>

Any header fields placed on the front of an MO or MT message are not added to the second and subsequent messages.

This provides a simple mechanism which is completely backward compatible. There is no indication of the number of messages and should a message be lost by the system or arrive out of sequence then the original message cannot be reconstructed. Therefore, wherever possible the concatenation mechanism specified in clause 9.2.3.24.1 should be used instead.

3.8.4 Alternative characters for Internet email addresses in MO SMS.

It is difficult or impossible to generate some characters on a mobile phone and so the following alternatives may be used:

@ may be replaced by *

_ (underscore) may be replaced by $

3.9 SMS COMPRESSION

Short Messages may be compressed in accordance with the compression algorithm described in 3GPP TS 23.042 [26].

Compression and Decompression may take place between SME’s or between an SME and the SC.

The compression only applies to the TP-User-Data part of the TPDU and excludes any TP-User-Data-Header which may be present. The Compression Header (see 3GPP TS 23.042 [26]) must commence at the first octet of the TP‑User‑Data field immediately following any TP-User-Data-Header field which may be present.

The TP-UDL value must be set in accordance with that value defined for the compressed TP-User-Data case in clause 9.2.3.16.

The TP-DCS parameter indicates whether or not a short message is compressed. If the TP-DCS parameter indicates that the short message is compressed then the alphabet encoding values (bits 2 and 3 in 3GPP TS 23.038 [9]) must be ignored by the receiving entity.

In the case where a short message after compression is greater than 140 octets (including the Compression Header and Footer (see 3GPP TS 23.042 [26]) and any TP-User-Data-Header which may be present) then the sending entity must concatenate the short message in the normal way as described in clause 9.2.3.24.1 if it wishes to continue to send the short message. Only the first segment of the concatenated short message must contain the Compression Header defined in 3GPP TS 23.042 [26]. All segments other than the final segment must be 140 octets in length. Only the final segment contains the Compression Footer (see 3GPP TS 23.042 [26]).

For mobile terminated compressed messages, where the MMI or the Message Class indicated in the TP-DCS requires the message to be stored in the MS then the MS shall store the compressed message as received. In the case where the MS is capable of decompression then the MS may display the decompressed message. Such an MS may optionally store the message in decompressed form subject to the MS being configured to do this via MMI. However, prior to storing the message in decompressed form, the MS may have to create a concatenated SM and carry out component modification on the TP-UDL and TP-DCS values to indicate the correct length values and that the message is no longer compressed. Transfer of messages direct from the radio interface or those stored in the MS to a TE is according to the procedure defined in 3GPP TS 27.005 [14] and is independent of whether the message is compressed or uncompressed.

For mobile originated compressed messages, an MS capable of compression may compress a short message generated within the MS itself prior to sending it to the radio interface. An MS capable of compression may optionally compress an uncompressed message received from a TE subject to the MS being configured to do this via MMI. In such a case the MS would have to carry out component modification on the TP-UDL and TP-DCS values to indicate the correct length values and that the message is compressed. A TE may send a message (compressed or uncompressed) to the MS using the procedures defined in 3GPP TS 27.005 [14]. The MS shall store the compressed message as received and/or transfer it directly to the radio interface.

In addition for the compression method described above, it may be possible to compress certain Information Elements of the User Data Header of a TPDU. The compression method is defined in clause 9.2.3.24.10.1.13.

3.10 Enhanced Messaging Service

The Enhanced Messaging Service (EMS) is based upon the standard SMS, but with formatting added to the text. The formatting may permit the message to contain animations, pictures, melodies, formatted text, and vCard and vCalendar objects. Objects may be mixed together into one message. This clause overviews the supported features. The coding mechanisms and formats are specified in clause 9.2.3.24.10.

The following sub clauses describe a number of features of EMS. The data formats in the features below shall be supported (ie the UE shall behave in a predictable manner when receiving such data) but the features are supported subject to the capabilities of the UE. However, it is highly recommended that all of these features are implemented otherwise interoperability problems at the application level may result.

3.10.1 Text formatting

The following text formatting features are supported:

Alignment

– Left

– Centre

– Right

– Default (Language dependent)

Font size

– Normal

– Large

– Small

Style

– Normal

– Bold

– Italic

– Underlined

– Strikethrough

– Text Colour

– Text Background Colour

3.10.2 Pictures

Basic Pictures

It is possible to include either a small (16*16 pixels), large (32*32 pixels) or pictures of variable size. These pictures have neither animation nor grey scale; they are plain black and white. All pictures are user defined.

Extended Pictures

It is possible to include extended pictures. These pictures may be black and white, greyscale or colour bit maps. The picture size is a maximum of 255 x 255 pixels. These pictures may be transmitted in a compressed form.

3.10.3 Animations

Predefined

There are number of predefined animations. These animations are not sent as animation over the air interface, only the identification of them. As soon as the position of the animation in the SM data is reached, the animation corresponding to the received number shall be displayed in a manner which is manufacturer specific.

User Defined

The user-defined animations consist of 4 pictures and there are two different sizes of these animations. The picture size of the small animations are 8*8 pixels and the large 16*16 pixels. These animations are sent over the air interface.

Extended Animations

It is possible to include extended animations. These may be black and white, greyscale or colour bit maps. The maximum size of a single animated frame is 255 x 255 pixels. The repetition of these animations may be controlled by the originator. These animations may be transmitted in a compressed form.

3.10.4 Sound

Predefined

There are a number of predefined sounds. These sounds are not transferred over the air interface, only the identification of them. There are 10 different sounds that can be added in the message, and as soon as the sound mark is in focus (on the display), the sound will be played.

User Defined

The sender can define own melodies according to the iMelody format [33]. These melodies are transferred in the SM and can take up to 128 bytes.

Extended Sounds

Monophonic melodies may be transferred using the iMelody format [33]. These may be transmitted in a compressed form.

3.10.5 vCard and vCalendar

A message may contain vCard and vCalendar objects as specified in [36][37]. These may be transmitted in a compressed form.

3.10.6 WVG (Wireless Vector Graphics) Object

A message may contain one or more WVG objects. A WVG object is a vector graphics picture or animation and is scalable. Two subtypes of WVG objects are supported; Standard WVG object and Character Size WVG object. Actual display size of a Standard WVG object depends on display screen size and MMI implementation on terminals. A Character Size WVG object has a height that equals or is similar to the height of message text but with variable width. Character Size WVG object may be edited in the same way as standard text, e.g. insertion deletion and text wrapping.

3.10.6.1 Overview of WVG Graphical Primitives

The WVG element is used to describe vector graphics objects. The vector graphics format is used to allow the creation of small pictures which may include simple animation or the creation small handwritten sketches. WVG makes use of the following graphical primitives (full detail is listed in annex G.2) These primitives can be used to describe a compact drawing.

List of Graphical Primitives:

– Polylines (G2.1)

– Simple Line Polyline (G.2.1.1)

– Circular Polyline (G.2.1.2)

– Bezier lines (G.2.1.3)

– Polygons (G.2.2)

– Arbitrary Polygon (G.2.2)

– Regular Polygon (G.2.4)

– Star Shaped Polygon (G.2.4)

– Regular Grid Element (G.2.4)

– Ellipses (G.2.3.1)

– Rectangles (G.2.3.2)

– Text Element (G.2.5)

– Grouping Element (G.2.6)

– Reuse Element (G.2.7)

– Animations Elements (G.2.8)

– Frame Element (G.2.9)

– Local Element (G.2.10)