Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑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…

 

9.2.3.24.10.2  — p. 95
9.2.3.24.10.2.1  Example of Basic text formatting and predefined EMS coding p. 95
An example of the basic concept of coding is given as follows:
TP-UDHI=1
SMS User Data Header: UDHL=05, IEI=0A, IEDL=03, IED1=0F, IED2=12, IED3=10
SMS User Data: This is a text with bold option on following with normal text.
Should be displayed as:
Example of Basic text formatting and predefined EMS coding
It is also possible to add predefined sounds in the message.
Example:
TP-UDHI=1
SMS User Data Header: UDHL=08, IEI=0B, IEDL=02, IED1=09,<sound5>, IEI=0B, IEDL=2, IED1=1C, <sound7>
SMS User Data: This is a message with two different sounds.
The sound nr5 shall be played after the 9th received character ("a") and sound nr7 shall be played after the 28th received character ("e").
Up
9.2.3.24.10.2.2  Example of User defined Objects EMS coding p. 96
Example of a message including one small picture is coded as follows:
TP UDHI=1
SMS User Data Header: UDHL=24, IEI=11, IEIDL=22, IED1=08, < small picture 32bytes (small picture 32bytes)>
SMS User Data: Hello!<CR><LF><CR><LF>One small picture in here
Should be displayed as:
One small picture in here
If the message starts with <CR>, then the "unreadable" data in an old terminal will be overwritten by the text, and the user will not see any strange characters. It is possible to insert the same picture several times in the same message. In that case, the TP-UD header shall contain as many IE as the number of occurrences contained in the SM or one segment of a concatenated message. Using defined elements will normally imply that more than one SM is required and therefore concatenation is required.
Up
9.2.3.24.10.2.3  Concatenation of SMS messages p. 96
Concatenated messages are required in most cases required when using several types of EMS elements, since it is only possible to send one large picture/large animation/melody in one single SM. After including either of these elements, there are only 4 (or 9 if no concatenation is used) characters left to the text part, and this is usually too little.
If one or more objects are embedded in one segment of a concatenated message, the IE octet indicating its/their position within the SM data cannot be set to a value that would refer to a position in the next segment(s) so that received segments should be processed before all of them have been received. It means that a formatting text that could not be conveyed in one segment shall be split in as many segments as necessary. In that case, the IE relating to the formatting shall be repeated in all the segments in which it will apply.
Example of a message including 2 Large Pictures, 4 Small animations and 2 User defined Melodies together with some text.
The EMS message: <Large Picture1> <User Defined Melody 1> Hello All, This is a real Enhanced Message <Small Animation 1>. I can send <Small Animation 2> and receive <Small Animation 3> really advanced EMS messages <Animation 4> Isn't it impressive? /Lars <User Defined Melody2> <Large Picture 2>
This EMS message has to use concatenated messages and the SM will typically contain the following data:
SM User Data Header User Data
1IEI=10 (Large Picture)
IED1=00 (beginning of the SM)
<Large Picture 1 (128 bytes)>
[<CR><LF>]
2IEI=0C (User Defined Sound)
IED1=00 (beginning of the SM)
<User Melody 1 (129bytes max)>
Hello
3IEI=0F (Small Animation)
IED1=24 (36th position)
<Small Animation 1 (32 bytes)>
IEI=0F (Small Animation)
IED1=2F (47th position)
<Small Animation 2 (32 bytes)>
All, This is a real Enhanced Message. I can send and
4IEI=0F (Small Animation)
IED1=07 (7th position)
<Small Animation 3 (32 bytes)>
IEI=0F (Small Animation)
IED1=25 (37th position)
<Small Animation 4 (32 bytes)>
receive really advanced EMS messages. Isn't it impressive? /Lars.
5IEI=0C (User Defined Sound)
IED1=00 (beginning of the SM)
<User Melody 1 (128 bytes max)>
[<CR><LF>]
6IEI=10 (Large Picture)
IED1=00 (beginning of the SM)
<Large Picture 2 (128 bytes)>
Up
9.2.3.24.10.3  EMS Formats p. 97
9.2.3.24.10.3.1  Soundsp. 97
Predefined Sounds
There are a number of fixed predefined sounds. Each sound nr corresponds to a specific sound according to the table below. The presentations of these sounds are manufacturer specific.
Sound nr Description
0Chimes high
1Chimes low
2Ding
3TaDa
4Notify
5Drum
6Claps
7FanFar
8Chord high
9Chord low
User defined sounds
The user defined sounds are coded according to the iMelody format[33]. The maximum length of a sound is 128 bytes.
Up
9.2.3.24.10.3.2  Picturesp. 97
Pictures are coded from upper left to lower right and in each byte the most significant bit represent the pixel at the left. The pictures are plain black and white, no colours or grey scales are supported. The bitvalue "0" represents a white pixel and the bitvalue "1" represents a black pixel.
Example:
16*16 picture
Byte 1Byte 2
Byte 3Byte 4
Byte 31Byte 32
Up
9.2.3.24.10.3.3  Animationp. 98
Predefined
There are a number of predefined animations. Each animation nr corresponds to a specific animation according to the table below. The way of displaying the animation is manufacturer specific.
Animation nr Description
0I am ironic, flirty
1I am glad
2I am sceptic
3I am sad
4WOW!
5I am crying
6I am winking
7I am laughing
8I am indifferent
9In love/Kissing
10I am confused
11Tongue hanging out
12I am angry
13Wearing glasses
14Devil
User Defined
Animations are coded as 4 sequential pictures, with the first picture sent first.
Up

Up   Top   ToC