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…

E.1 Predefined Sound E.2 iMelody E.3 Black and white bitmap E.4 2-bit greyscale bitmap E.5 6-bit colour bitmap E.6 Predefined animation E.7 Black and white bitmap animation E.8 2-bit greyscale bitmap animation E.9 6-bit colour bitmap animation E.10 vCard E.11 vCalendar E.12 Data Format Delivery Request E.13 Standard WVG Object E.14 Polyphonic melody
...

E (Normative) Extended Object Format Type |R5| p. 167

E.1 Predefined Sound p. 167

The predefined sound as integrated in the Extended Object IE is structured as follows:

Octet 8

Sound number as defined in Table of clause 9.2.3.24.10.3.1.

E.2 iMelody p. 167

An iMelody object [33] can be integrated in an Extended Object IE with the following structure:

Octet 8..n

iMelody object coded according to the iMelody format [33].

E.3 Black and white bitmap p. 167

The user-defined black and white bitmap as integrated in the Extended Object IE is structured as follows:

Octet 8

Horizontal dimension of picture.

This octet shall contain the horizontal number of pixels.

Octet 9

Vertical dimension of picture.

This octet shall contain the vertical number of pixels.

Octet 10..n

Picture data, pixel by pixel from top left to bottom right.

The picture data is encoded as a continuous sequence of bits. There shall be no fill bits at the end of each row of data, Fill bits may only be used in the last octet of the picture data if needed. The fill bits in the last octet shall be ignored. Within each octet the MSB represents the leftmost pixel.

The colour values are encoded as follows:

Bit Value  Colour
  
0          White
1          Black

E.4 2-bit greyscale bitmap p. 167

The user-defined 2-bit greyscale bitmap as integrated in the Extended Object IE is structured as follows:

Octet 8

Horizontal dimension of picture.

This octet shall contain the horizontal number of pixels

Octet 9

Vertical dimension of picture.

This octet shall contain the vertical number of pixels.

Octet 10..n

Picture data, pixel by pixel from top left to bottom right. The picture data is encoded as a continuous sequence of bits. There shall be no fill bits at the end of each row of data, Fill bits may only be used in the last octet of the picture data. The fill bits in the last octet shall be ignored.The pair of bits at the MSB represents the leftmost pixel of the four defined in an octet.

The colour values are encoded as follows:

Bit Value  Colour
  
00         Black
01         Dark Grey
10         Light Grey
11         White

E.5 6-bit colour bitmap p. 168

The user-defined 6-bit colour bitmap as integrated in the Extended Object IE is structured as follows:

Octet 8

Horizontal dimension of picture.

This octet shall contain the horizontal number of pixels

Octet 9

Vertical dimension of picture.

This octet shall contain the vertical number of pixels.

Octet 10..n

Each pixel colour is represented by 6-bits of data, giving a total of 64 colours. (2 bits of data define the levels of each red, green and blue). The overall pixel colour is a composite of the three RGB values.

The first pair of bits of picture data define the level of red of the topmost, leftmost pixel, the next pair of bits the level of green for this pixel, and the third pair the level of blue for the pixel. The first bit of a pair defining a colour level is the MSB. This is illustrated below.

Octet 1
Bit 7	Bit 6	Bit 5	Bit 4	Bit 3	Bit 2	Bit 1	Bit 0
MSB Red Pixel 1	LSB Red Pixel 1	MSB Green Pixel 1	LSB Green Pixel 1	MSB Blue Pixel 1	LSB Blue Pixel 1	MSB Red Pixel 2	LSB Red Pixel 2

Octet 2
Bit 7	Bit 6	Bit 5	Bit 4	Bit 3	Bit 2	Bit 1	Bit 0
MSB Green Pixel 2	LSB Green Pixel 2	MSB Blue Pixel 2	LSB Blue Pixel 2	MSB Red Pixel 3	LSB Red Pixel 3	MSB Green Pixel 3	LSB Green Pixel 3

E.6 Predefined animation p. 168

The predefined animation as integrated in the Extended Object IE is structured as follows:

Octet 8

Animation number as defined in Table of clause 9.2.3.24.10.3.3.

E.7 Black and white bitmap animation p. 168

The user-black and white animation is integrated in the Extended Object IE is structured as follows:

Octet 8

Horizontal dimension of picture.

This octet shall contain the horizontal number of pixels.

Octet 9

Vertical dimension of picture.

This octet shall contain the vertical number of pixels.

Octet 10

The number of frames in the animation.

Octet 11

Animation control byte.

Bits	Meaning
7 - 4	Frame display. The value (in tenths of a second) that is requested between each frame: 0000 1 tenth (i.e. 0.1s) 1111 16 tenths (i.e. 1.6 s).
3 - 0	Repeat value. The requested number of repetitions of the animation: 0000 Unlimited repetition 0001 1 repetition 1111 15 repetitions.

Octet 12..n

Contains a series of bitstreams encoding 1 bit pixel depth bitmaps as defined in F.3. If a frame in the animation would require fill bits (as described in F.3) these shall be contained at the end of the frame such that the bit-stream for the next frame begins on an octet boundary.

E.8 2-bit greyscale bitmap animation p. 169

The user-black and white animation is integrated in the Extended Object IE is structured as follows:

Octet 8

Horizontal dimension of picture.

This octet shall contain the horizontal number of pixels.

Octet 9

Vertical dimension of picture.

This octet shall contain the vertical number of pixels.

Octet 10

The number of frames in the animation.

Octet 11

Animation control byte.

Bits	Meaning
7 - 4	Frame display. The value (in tenths of a second) that is requested between each frame: 0000 1 tenth (i.e. 0.1s) 1111 16 tenths (i.e. 1.6 s).
3 - 0	Repeat value. The requested number of repetitions of the animation: 0000 Unlimited repetition 0001 1 repetition 1111 15 repetitions.

Octet 12..n

Contains a series of bitstreams encoding 2 bit pixel depth bitmaps as defined in F.4. If a frame in the animation would require fill bits (as described in F.4) these shall be contained at the end of the frame such that the bit-stream for the next frame begins on an octet boundary.

E.9 6-bit colour bitmap animation p. 169

The user-black and white animation is integrated in the Extended Object IE is structured as follows:

Octet 8

Horizontal dimension of picture.

This octet shall contain the horizontal number of pixels.

Octet 9

Vertical dimension of picture.

This octet shall contain the vertical number of pixels.

Octet 10

The number of frames in the animation.

Octet 11

Animation control byte.

Bits	Meaning
7 - 4	Frame display. The value (in tenths of a second) that is requested between each frame: 0000 1 tenth (i.e. 0.1s) 1111 16 tenths (i.e. 1.6 s).
3 - 0	Repeat value. The requested number of repetitions of the animation: 0000 Unlimited repetition 0001 1 repetition 1111 15 repetitions.

Octet 12.n

Contains a series of bitstreams encoding 6 bit pixel depth bitmaps as defined in F.5. If a frame in the animation would require fill bits (as described in F.5) these shall be contained at the end of the frame such that the bit-stream for the next frame begins on an octet boundary.

E.10 vCard p. 170

A vCard object [36] can be integrated in a Extended Object IE with the following structure:

Octet 8.n

vCard object as defined in [36]. The UTF-8 encoding is used instead of the default 7-bit ASCII. For certain vCard properties, other encoding can be used by setting the CHARSET property parameter to the appropriate character set.

E.11 vCalendar p. 170

A vCalendar object [37] can be integrated in a Extended Object IE with the following structure:

Octet 8..n

vCalendar object as defined in [37]. The UTF-8 encoding is used instead of the default 7-bit ASCII. For certain vCalendar properties, other encoding can be used by setting the CHARSET property parameter to the appropriate character set.

E.12 Data Format Delivery Request p. 170

This Data Format Delivery Request is an optional feature used by an SME to indicate which Extended Object data formats, listed in clause 9.2.3.24.10.1.11, it is requesting for delivery. This Data Format Delivery Request may be included by an SME in a MO SM containing other EMS related data, or in a MO SM independently. Processing of this data format is optional in a MT short message.

The information in this data format represents an extensible bit field with the first bit being mapped to the first Extended Object (EO) data format defined in the table in clause 9.2.3.24.10.1.11.

Octet 8

Bit 0: If set to 1 indicates support for EO data format 00

Bit 1: If set to 1 indicates support for EO data format 01

Bit 2: If set to 1 indicates support for EO data format 02

……

Octet n

Bit 0: If set indicates support for EO data format ((n - 8) * 8)

Bit 1: If set indicates support for EO data format ((n - 8) * 8) + 1

Bit 2: If set indicates support for EO data format ((n - 8) * 8) + 2

…….

Any unused bits in the last octet shall be set to zero.

E.13 Standard WVG Object p. 170

The Standard WVG object as defined by Format Type 0x0B in the Extended Object IE is as follows.

Octet 8..n)

Standard WVG object bit stream

The unused bits in the last octet will be filled with 0

The detailed data format and attributes of Standard WVG object are defined in Annex G.

The bit order is defined as follows:

The octet with a smaller octet number stores the bits appearing in the front position in the bit stream; the most significant bit in an octet stores the first bit in position in a 8-bit segment in the bit stream.

A Standard WVG object may or may not have fixed size. In either case, display size should be determined by the terminal implementation. Recommended display size is a largest possible size on terminal screen while aspect ratio shall be maintained.

E.14 Polyphonic melody p. 171

A Polyphonic melody can be integrated as an extended object in one or more short messages. Informative guidelines for the creation of polyphony content using SP-MIDI [38] are listed in Annex H.

However, in order to guarantee the interoperability with legacy mobile devices which are not able to interpret specific SP-MIDI content, the following considerations shall be taken into account for content creation:

When content is not provided in SP-MIDI format the presence of the MIP table in polyphonic extended objects is not mandatory. Since a receiving SME supporting polyphonic extended objects may decide to ignore and skip the content of a MIP message by implementing its own note stealing or channel masking strategy when played. However, when SP-MIDI format data is present and the message is stored and subject to potential forwarding, the specific SP-MIDI content shall be kept as received by the SME.
the additional rhythm channel as specified in clause 3.2 in [38] might not be supported by the receiving SME.

Octet 8..n

SMF as defined in [38], [40]