Tech-invite  3GPPspace  IETFspace
21  22  23  24  25  26  27  28  29  31  32  33  34  35  36  37  38  4‑5x

Content for  TS 23.040  Word version:  18.0.0

Top   Top   Up   Prev   Next
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.3 Unsuccessful short message TPDU transfer SC → MS  3.4 Unsuccessful short message TPDU transfer MS → SC  3.5 Use of Supplementary Services in combination with the Short Message Service  3.6 Applicability of Operator Determined Barring to the Short Message Service  3.7 Multiple short message transfer  3.8 SMS and Internet Electronic Mail interworking  3.8.1 Basic Format  3.8.2 Optional Fields  3.8.3 Text concatenation  3.8.4 Alternative characters for Internet email addresses in MO SMS.  3.9 SMS COMPRESSION  3.10 Enhanced Messaging Service  3.10.1 Text formatting  3.10.2 Pictures  3.10.3 Animations  3.10.4 Sound  3.10.5 vCard and vCalendar  3.10.6 WVG (Wireless Vector Graphics) Object 
...

 

3.3  Unsuccessful short message TPDU transfer SC → MS  p. 24

3.3.0  General |R15|  p. 24

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 TS 24.008, TS 24.011 and TS 29.002.
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.
Up

3.3.1  Errors occurring during transfer of TPDU to MS  p. 24

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  p. 24

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 TS 24.011 and TS 29.002. 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.
Error indication S
(note 1)		 Meaning
Unknown subscriberPThe 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 TS 29.002).
Teleservice not provisionedPThe PLMN rejects the short message TPDU because the recipient MS has no SMS subscription (see TS 29.002).
Call barredTThe PLMN rejects the short message TPDU due to barring of the MS (see TS 29.002, description of the Barring supplementary service, TS 22.004 and TS 23.011), description of Call barred due to Unauthorised Message Originator, TS 29.002, and description of Operator Determined Barring, TS 22.041 and TS 23.015).
Facility not supportedTThe VPLMN rejects the short message TPDU due to no provision of the SMS in the VPLMN (see TS 29.002).
Absent subscriberTThe PLMN rejects the short message TPDU because
  • there was no paging response via the SGSN, MSC or both (see TS 24.008 & TS 29.002)
  • the IMSI GPRS or both records are marked detached (see TS 29.002);
  • the MS is subject to roaming restrictions (see "Roaming not allowed", TS 29.002);
  • deregistered in the HLR. The HLR does not have an MSC, SGSN or both numbers stored for the target MS, (see TS 29.002);
  • Unidentified subscriber (see TS 29.002);
  • MS purged (see TS 29.002) ;
  • 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 TS 29.002)
MS busy for MT SMSTThe 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 provisionedTThe 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 TS 24.008 and TS 29.002).
Error in MSTThe 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 SubscriberPThe PLMN rejects the short message TPDU because the MS failed authentication.
Illegal EquipmentPThe PLMN rejects the short message TPDU because the IMEI of the MS was on the prohibited list in the EIR.
System failureTThe PLMN rejects the short message TPDU due to network or protocol failure others than those listed above (see TS 29.002).
Memory Capacity ExceededTThe MS rejects the short message since it has no memory capacity available to store the message.
NOTE 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.
Values Reason for absence
0no paging response via the MSC
1IMSI detached
2roaming restriction
3deregistered in the HLR for non GPRS
4MS purged for non GPRS
5no paging response via the SGSN
6GPRS detached
7deregistered in the HLR for GPRS
8MS purged for GPRS
9Unidentified subscriber via the MSC
10Unidentified subscriber via the SGSN
11deregistered in the HSS/HLR for IMS
12no response via the IP-SM-GW
13the 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.
Up

3.4  Unsuccessful short message TPDU transfer MS → SC  p. 26

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

3.4.1  Errors occurring during transfer of TPDU to SC  p. 26

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  p. 26

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 TS 29.002 and TS 24.011. 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.
Up

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

Only a sub-set of the Supplementary Services defined in TS 22.004and TS 23.011 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  p. 27

The network feature Operator Determined Barring (see TS 22.041) 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  p. 27

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  p. 27

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;
  • 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).
Up

3.8.1  Basic Format  p. 27

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.
Up

3.8.2  Optional Fields  p. 28

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  p. 28

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  p. 28

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  p. 28

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.
Up

3.8.3  Text concatenation  p. 29

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.
Up

3.8.4  Alternative characters for Internet email addresses in MO SMS.  p. 29

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  p. 29

Short Messages may be compressed in accordance with the compression algorithm described in TS 23.042.
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 TS 23.042) 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 TS 23.038) 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 TS 23.042) 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 TS 23.042. All segments other than the final segment must be 140 octets in length. Only the final segment contains the Compression Footer (see TS 23.042).
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 TS 27.005 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 TS 27.005. 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.
Up

3.10  Enhanced Messaging Service  p. 30

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.
Up

3.10.1  Text formatting  p. 30

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  p. 31

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.
Up

3.10.3  Animations  p. 31

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.
Up

3.10.4  Sound  p. 31

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.
Up

3.10.5  vCard and vCalendar |R5|  p. 31

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 |R5|  p. 31

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.
Up

3.10.6.1  Overview of WVG Graphical Primitives  p. 32

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:
Up

Up   Top   ToC