The purpose of this FAQ is to give answers to developers questions concerning smart messaging development. This document is subject to change without notice.

1. How can I get more information about Smart Messaging?
2. How can I get new ringing tone and graphical logos and pictures to my mobile phone?
3. Which Nokia phones support Smart Messaging?
4. Where can I get the business card and calendar event message specifications?
5. How can I send short message (SMS) from my PC using mobile phone in text mode?
6. How can I send short message (SMS) from my PC using mobile phone in PDU mode?
7. How can I encode the short message TPDU (7bit, no user-data-header)?
8. How can I encode the short message TPDU (8 bit, User-data-header)?
9. How can I encode operator logo message user data (8 bit)?
10. How can I encode Caller Line Identification (CLI) icon message user data (8 bit)?
11. How can I encode an OTA bitmap?
12. How can I encode ringing tone message user data (8 bit)?
13. How can I encode vCard message user data (8 bit)?
14. How can I encode vCalendar message user data (8 bit)?
15. How can I restore the original operator logo?
16. How can I encode Picture message user data (8 bit)?
17. How can I encode Downloadable Profile message user data (8 bit)?
18. How can I encode concatenated SMS message?
19. How can I encode a 72X14 operator logo as a single message, and is it even an acceptable format, as it doesn't seem to follow the specification?

1. How can I get more information about Smart Messaging?
The best way to get information is to go to the http://www.forum.nokia.com/ website and the Smart Messaging section. The Smart Messaging specification 3.0.0 and all the other documents give you good starting point. This FAQ and the discussion board will help you in more detailed questions.

2. How can I get new ringing tone and graphical logos and pictures to my mobile phone?
In order to get ringing tones and logos to your mobile phone, please contact the Club Nokia Careline in Europe. Club Nokia Careline supports and gives information to Club Nokia members. Visit Club Nokia for more information. Your network service provider may also have working services where you can get ringing tones and logos.

3. Which Nokia phones support Smart Messaging?
Most of the Nokia mobile phones are capable of receiving smart messages. Those messages can contain ringing tones, operator logos, group graphics (caller line identification icons), picture messages, business cards (vCard ) and calendar bookings (vCal). Also the TTML (Tagged Text Mark-up Language) and DMCP (Dynamic Menu Control Protocol) are supported in some phone models. Following Nokia phones support different smart messages. Please notice that this table includes only GSM phone models.

| Ringing tone | Opera- tor logo | CLI icon | Picture mes- sage | Busi- ness card (vCard) | Calendar reser- vation (vCal) | Down- load- able Profile | WAP Settings
3210 | X | X |  | X | X |  |  |
3310 | X | X |  | X | X | X | X |
3330 | X | X |  | X | X | X | X | X
5110 |  | X |  |  | X |  |  |
5130 |  | X |  |  | X |  |  |
5510 | X | X |  | X | X | X | X | X
6110 | X | X | X |  | X | X |  |
6130 | X | X | X |  | X | X |  |
6150 | X | X | X |  | X | X |  |
6210 | X | X | X | X | X | X |  | X
6250 | X | X | X | X | X | X |  | X
7110 | X | X | X |  | X | X |  | X
8110i | X |  |  |  |  |  |  |
8210 | X | X | X | X | X | X |  |
8310 | X | X | X | X | X | X | X | X
8810 | X | X | X |  | X | X |  |
8850 | X | X | X | X | X | X |  |
8890 | X | X | X | X | X | X |  |
9110 | X | X |  |  | X | X |  |
9110i | X | X |  |  | X | X |  | X
9210 | X | X |  |  | X | X |  | X

Top of page

4. Where can I get the business card and calendar event message specifications?
Most of Nokia phones support vCard and vCal smart messages. Those specifications are specified by the Versit Consortium. Specifications are named as "The Electronic Calendaring and Scheduling Exchange Format" and "The Electronic Business Card". Visit http://www.imc.org/ for more information.

Top of page

5. How can I send short message (SMS) from my PC using mobile phone in text mode?
Short messages containing 7bit textual information can be sent from the PC program to mobile phone. The mobile phone must be installed as a modem to the PC's operating system. And the phone must be connected to the PC using cable or infrared. See also " AT Command Set for Nokia GSM Products" in Smart Messaging documents. To send text mode SMS:

AT command | Description
AT+CMGF=1<enter/carriage return> | The SMS sending mode is changed to text mode (default is 0, PDU mode)
AT+CMGS="+4441793181022" <enter/carriage return> <text entered> <ctrl+z> | The message is sent to entered to number +4441793181022. Replace this number with your own number.

The modem responds with "+CMGS: < TP-Message-reference value in integer format>" and OK, and the message is sent. Sending can be cancelled by using an <ESC> character. <ctrl-z> must be used to indicate the ending of a message body.

Top of page

6. How can I send short message (SMS) from my PC using mobile phone in PDU mode?
Short message can be sent from the PC program using AT commands. The mobile phone must be installed as a modem to the PC's operating system. And the phone must be connected to the PC using cable or infrared. This section includes example how message containing textual information is sent from the PC program to mobile phone using PDU mode.
See also " AT Command Set for Nokia GSM Products" in Smart Messaging documents.

To send PDU mode SMS:

AT command | Description
AT+CMGF=0<enter/carriage return> | The SMS sending mode is changed to PDU mode (default is 0, PDU mode).
AT+CMGS=<length> <enter/carriage return><pdu><ctrl-Z> | Sends a message from the DTE to the network (SMS-SUBMIT). <length> is the length of the actual TPDU in octets. The RP layer SC (short message centre) address octets are not counted in the length. <pdu> is the RP SC address Address-Value field followed by a TPDU in hexadecimal format.

The modem responds with "+CMGS: < TP-Message-reference value in integer format>" and OK, and the message is sent. Sending can be cancelled by using an <ESC> character. <ctrl-z> must be used to indicate the ending of a message body.

Error responses from the phone see: "AT Command Set for Nokia GSM Products" in Smart Messaging documents.

Top of page

7. How can I encode the short message TPDU (7bit, no user-data-header)
SMS-SUBMIT and SMS-DELIVER are TPDUs (Transfer Protocol Data Unit). Those can be build different ways, structure is explained more detailed in GSM 03.40 specification. SUBMIT goes from phone to network and DELIVER is coming from network to phone. Here is included an example of sending a 7bit short message with the SMS PDU mode.

Example how this is done in practise using normal terminal program.

AT+CMGF=0 | set SMS PDU mode on
OK |
AT+CMGS=29 | length of the SMS PDU (decimal), The RP layer SC address octets are not counted in the length.
079153485002020911000C915348870420140000A71 154747A0E4ACF41F4F29C9E769F4121
+CMGS: 212 | message reference is shown
OK

Table 1. <pdu>, RP SC Address-Value field followed by a TPDU in hexadecimal format

RP SC address (optional) | Value | Description | Status
| 07 | Address length | Length of the address is 7. Including the type of numbering plan indication.
| 91 | Type of address | International address using ISDN telephone numbering plan.
| 53 48 50 02 02 09 | Short message service centre address | The short message service centre number. F.ex +35 84 05 20 20 10 is encoded as 53 48 50 02 02 09. In this case the address takes 6 octets.
TPDU Octet 1 bits | Value (hex11) | Description | Status
7 | 0 | TP-Reply -Path | Reply path no set
6 | 0 | TP-User-Data -header-indicator | Indication that user data doesn't contain additional header.
5 | 0 | TP-Status -Report-Request | Not requested
4 | 1 | TP-Validity -Period-Format | Relative format (bits 4 and 3)
3 | 0 | TP-Validity -Period-Format | Relative format (bits 4 and 3)
2 | 0 | TP-Rejected -Dublicates | Do not reject duplicates in SC
1 | 0 | TP-Message -Type-Indicator | type:SMS-SUBMIT (from phone to network), (bits 1 and 0)
0 | 1 | TP-Message -Type-Indicator | type:SMS-SUBMIT (from phone to network), (bits 1 and 0)
TPDU Octet 2 | Value | Description | Status
| 00 | TP-Message -Reference | Given by the phone, application/ user does not need to fill this octet.
TPDU Octet 3 | Value | Description | Status
| 0C | Address length in semi-octets. | Length of the address is 12 in semi-octets. Length the type of numbering plan indication.
TPDU Octet 4 | Value | Description | Status
| 91 | Type of address | International address using ISDN telephone numbering plan.
TPDU Octet 5-10 | Value | Description | Status
| 53 48 87 04 20 14 | TP-Destination -Address | The destination telephone number. F.ex +35 84 78 40 02 41 is encoded as 53 48 87 04 20 14. In this case the address takes 6 octets. The address can be 2 to 12 octets long.
TPDU Octet 11 | Value | Description | Status
| 00 | TP-Protocol -Identifier, consist one octet. For the details, see GSM 03.40 specification, version 7.2.0, page 53. | Parameter identifying the above layer protocol, if any. Note that for the straightforward case of simple MS-to-SC short message transfer, the TP-Protocol-Identifier is set to the value 00.
TPDU Octet 12 bits | Value (hex00) | Description | Status
7 | 0 | TP-Data -Coding-Scheme used in TP-User -Data, consist one octet. See GSM 3.38 | Functionality (bits 7 and 6) related to usage of bits 4-0.
6 | 0 |  | Functionality (bits 7 and 6) related to usage of bits 4-0.
5 | 0 |  | Indicates that text is uncompressed.
4 | 0 |  | Indicated that bits 1 and 0 have no message class meaning.
3 | 0 | Alphabet being used (bits 3 and 2) | 7bit message
2 | 0 | Alphabet being used (bits 3 and 2) | 7bit message
1 | 0 | Reserved | No meaning, indicated by bit 4
0 | 0 | Reserved | No meaning, indicated by bit 4
TPDU Octet 13 | Value | Description | Status
| A7 | TP-Validity -Period (Relative format). See GSM 03.40, version 7.2.0, page 55 for details | A7 -> 24 hours
TPDU Octet 14 | Value | Description | Status
| 11 | TP-User -Data-Length | Parameter indicating the length of the TP-User-Data field to follow. Represented as amount of septets (integer). 11 hex -> 17 septets. This is because of 7-bit user data. User data is coded to seven databits, because SMS have to be sent to air in 7 bit format. Length includes the user data header (not included in this example) and data itself.
TPDU Octet 115-29 | Value | Description | Status
| 54747A0E 4ACF41F4F 29C9E769 F4121 | TP-User-Data | The user data. Format of the user data depends, what kind of message is sent. This example includes text string "This is testing !". 17 septets + fill bits = 15 octets.

Top of page

8. How can I encode the short message TPDU (8 bit, User-data-header)
SMS-SUBMIT and SMS-DELIVER are TPDUs (Transfer Protocol Data Unit). Those can be build different ways, structure is explained more detailed in GSM 03.40 specification. SUBMIT goes from phone to network and DELIVER is coming from network to phone. Here is included an example of sending a 8bit short message with the SMS PDU mode.

Example of how this is done in practise using normal terminal program.

AT+CMGF=0 | set SMS PDU mode on
OK |
AT+CMGS=50 | length of the SMS PDU, The RP layer SC address is not included in this example.
0051000C9153487004633200F5A72406050415811581 024A3A51D195CDD008001B20550590610560558550548540 8208499000
+CMGS: 212 | message reference is shown
OK

Table 2. <pdu>, TPDU in hexadecimal format

RP SC address (optional) | Value | Description | Status
| 00 | Address length | Length of the address is 0, because the address is not included in this message.
TPDU Octet 1 bits | Value (hex 51) | Description | Status
7 | 0 | TP-Reply-Path | Reply path no set
6 | 1 | TP-User -Data-Header -Indicator | Indication that user data contains an additional header.
5 | 0 | TP-Status -Report-Request | Not requested
4 | 1 | TP-Validity -Period-Format | Relative format (bits 4 and 3)
3 | 0 | TP-Validity -Period-Format | Relative format (bits 4 and 3)
2 | 0 | TP-Reject -Duplicates | Do not reject duplicates in SC
1 | 0 | TP-Message -Type -Indicator | type:SMS-SUBMIT (from phone to network), (bits 1 and 0)
0 | 1 | TP-Message -Type -Indicator | type:SMS-SUBMIT (from phone to network), (bits 1 and 0)
TPDU Octet 2 | Value | Description | Status
| 00 | TP-Message -Reference | Given by the phone, application/user does not need to fill this octet.
TPDU Octet 3 | Value | Description | Status
| 0C | Address length in semi-octets. | Length of the address is 12 in semi-octets. Length includes the type of numbering plan indication.
TPDU Octet 4 | Value | Description | Status
| 91 | Type of address | International address using ISDN telephone numbering plan.
TPDU Octets 5-10 | Value | Description | Status
| 21 48 70 04 63 32 | TP-Destination-Address | The destination telephone number. F.ex +12 84 07 40 36 23 is encoded as 21 48 70 04 63 32. In this case the address takes 6 octets. The address can be 2 to 12 octets long.
TPDU Octet 11 | Value | Description | Status
| 00 | TP-Protocol-Identifier, consist one octet. For the details, see GSM 03.40 specification, version 7.2.0, page 53. | Parameter identifying the above layer protocol, if any. Note that for the straightforward case of simple MS-to-SC short message transfer, the TP-Protocol-Identifier is set to the value 00.
TPDU Octet 12 bits | Value (hex F5) | Description | Status
7 | 1 | TP-Data-Coding-Scheme used in TP-User-Data, consist one octet. See GSM 3.38 | Functionality (bits 7 - 4) related to usage of bits 3 - 0.
6 | 1 |  | Functionality (bits 7 - 4) related to usage of bits 3 - 0.
5 | 1 |  | Functionality (bits 7 - 4) related to usage of bits 3 - 0.
4 | 1 |  | Functionality (bits 7 - 4) related to usage of bits 3 - 0.
3 | 0 | reserved, set to 0 |
2 | 1 | Message coding | 8-bit data
1 | 0 | Message class (bits 1 and 0) | Class 1, Default meaning: ME-specific
0 | 1 | Message class (bits 1 and 0) | Class 1, Default meaning: ME-specific
TPDU Octet 13 | Value | Description | Status
| A7 | TP-Validity -Period (Relative format). See GSM 03.40, version 7.2.0, page 55 for details. | A7 -> 24 hours.
TPDU Octet 14 | Value | Description | Status
| 24 | TP-User -Data-Length | Parameter indicating the length of the TP-User-Data field to follow. Represented as amount of octets (integer). 24 hex -> 36 octets. Length includes the user data header and data itself.
TPDU Octets 15-50 | Value | Description | Status
| 06050415 81158102 4A3A51D 195CDD0 08001B20 55059061 05605585 50548540 82084990 00 | TP-User -Data | The user data. Format of the user data depends, what kind of message is sent. This message includes user data header and the user data itself. The example is ringing tone message.

Top of page

9. How can I encode operator logo message user data (8 bit)?
This example shows how to encode the operator logo message userdata. The length of the userdata is such a long that the message must be sent as a concatenated message (two parts). The length of the first part is 140 (dec) which is 8C (hex), and the length of the second part is 19 (dec) which is 13 (hex).

Here is the hex coded user data and the details of the data is explained in the tables 3a and 3b.

The first part:
0B05041582000000030102013042F4500A00480E01FFFFFFFFFFFFF
FFFFF000000000000000000FFFFFFFFFFFFFFFFFF00000000000000
000010F000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000
00000

The second part:
0B050415820000000301020200000000000001

Table 3a. The first part of the Operator logo message user data (length 140 octets -> hex 8C)

Octet number | Value | Description
1 | 0B | Length of the User Data Header
2 | 05 | IEI - Information Element Identifier (Application port addressing scheme, 16 bit port address)
3 | 04 | IEDL - Information Element Data Length
4 | 15 | Information Element Data (octets 4 & 5 --> 1582 - destination port)
5 | 82 | Information Element Data
6 | 00 | Information Element Data (octets 6 & 7 --> 0000 - originator port)
7 | 00 | Information Element Data
8 | 00 | IEI - Information Element Identifier (Concatenated short message, 8 bit reference number)
9 | 03 | IEDL - Information Element Data Length
10 | 01 | Information Element Data (Concatenated short message reference number)
11 | 02 | Information Element Data (Total number of (concatenated) messages (0-255))
12 | 01 | Information Element Data (Sequence number of current short message)
13 | 30 | Operator logo version number. ISO-8859-1 character "0"
14 | 42 | MCC (Mobile Country Code), octets 14 and 15, little-endian BCD, filled with F16', 244 -> 42 F4 Notice: To see the logo on the phone's screen, octets 14 and 15 must be defined with the settings of the current operator.
15 | F4 | MCC (Mobile Country Code), octets 14 and 15, little-endian BCD, filled with F16', 244 -> 42 F4 Notice: To see the logo on the phone's screen, octets 14 and 15 must be defined with the settings of the current operator.
16 | 50 | MNC (Mobile Network Code) coding, little-endian BCD, filled with F16', 05 -> 50
17 | 0A | ISO-8859-1 "Line feed" character
18 | 00 | InfoField, See "Smart Messaging Specification 3.0.0" for details.
19 | 48 | The width of the bitmap. Hex 48 -> 72 decimal
20 | 0E | The height of the bitmap. Hex 0E -> 14 decimal
21 | 01 | The depth of the bitmap (number of gray scales).
22-140 | Value: FFFFFFFFFFFFFFFFFF000000000000000000FFFFFFFF FFFFFFFFFF00000000000000000010F0000000000000 00000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000 000000000000000000 Description: OTA bitmap data.

Table 3b. The second part of the Operator logo message user data (length 19 octets -> hex 13)

Octet number | Value | Description
1 | 0B | Length of the User Data Header
2 | 05 | IEI - Information Element Identifier (Application port addressing scheme, 16 bit port address)
3 | 04 | IEDL - Information Element Data Length
4 | 15 | Information Element Data (octets 4 & 5 --> 1582 - destination port)
5 | 82 | Information Element Data
6 | 00 | Information Element Data (octets 6 & 7 --> 0000 - originator port)
7 | 00 | Information Element Data
8 | 00 | IEI - Information Element Identifier (Concatenated short message, 8 bit reference number)
9 | 03 | IEDL - Information Element Data Length
10 | 01 | Information Element Data (Concatenated short message reference number)
11 | 02 | Information Element Data (Total number of (concatenated) messages (0-255))
12 | 02 | Information Element Data (Sequence number of current short message)
13-19 | 00000000000001 | The rest of the OTA bitmap data.

Top of page

10. How can I encode Caller Line Identification (CLI) icon message user data (8 bit)?
This example shows how to encode the Caller Line Identification icon (Caller group graphic) message user data. The length of the userdata is 138 octets, which is 8A in hexadecimal presentation.

Here is the hex coded user data and the details of the data is explained in the table 4.

060504158300003000480E010000000000000000000000000000000000
0000007904100000000000008504100000000000008104100000000000
0081041038F38000000081041045144000000081041045144000000081
041045144000000085041045144000000079F41F38F380000000000000
00100000000000000001E00000000000000000000000

Table 4. CLI icon message user data (length 138 octets -> hex 8A)

Octet number | Value | Description
1 | 06 | Length of the User Data Header
2 | 05 | IEI - Information Element Identifier (Application port addressing scheme, 16 bit port address)
3 | 04 | IEDL - Information Element Data Length
4 | 15 | Information Element Data (octets 4 & 5 --> 1583 - destination port)
5 | 83 | Information Element Data
6 | 00 | Information Element Data (octets 6 & 7 --> 0000 - originator port)
7 | 00 | Information Element Data
8 | 30 | CLI Icon version number. ISO-8859-1 character "0"
9 | 00 | InfoField, See "Smart Messaging Specification 3.0.0" for details.
10 | 48 | The width of the bitmap. Hex 48 -> 72 decimal
11 | 0E | The height of the bitmap. Hex 0E -> 14 decimal
12 | 01 | The depth of the bitmap (number gray scales).
13-138 |  | OTA bitmap data

Top of page

11. How can I encode an OTA bitmap?
OTA Bitmap is used as a part of the following Smart Messaging formats: Operator logo, CLI icon, Picture Message and Downloadable Profile. In today's Nokia phones the maximum size of the operator logo and the CLI icon is 72x14 pixels, while the maximum size of the picture message and the screen saver is 72x28 pixels.

An OTA Bitmap consists of a bitmap header and a bitmap data. The size of the bitmap is specified in the header. Several other information (ie. number of colors) are also defined there, but those informations handle issues that are not supported in today's Nokia phones. So these values are similar in all OTA Bitmap headers.

Typical OTA Bitmap (72x14 pixels) header is: 00480E01

00 | 'Infofield'
48 | 'Width of the bitmap is 72 pixels'
0E | 'Height of the bitmap is 14 pixels'
01 | 'Number of colors or grey shades (only one color)'

The image data is located after the header information and is encoded as follows. Each semi-octet in the OTA bitmap presents 4 pixels in the original bitmap. Because one row takes 18 semi-octets, the whole 72x14 size (operator logo and CLI icon) bitmap takes 18x14 = 252 semi-octets = 126 octets. In the case of the picture message and screen saver the whole 72x28 size bitmap takes 18x28 = 504 semi-octets = 252 octets.

For example, if the first four pixels of the image are 1010 (1 - black, 0 - white), the first semi-octet of the OTA bitmap data is hex A.

This is an example of a simple OTA bitmap (72x14 pixels). In the picture, there are two black lines and several black dots.

FFFFFFFFFFFFFFFFFF | <- First line black
000000000000000000 | <- Second line white
FFFFFFFFFFFFFFFFFF |
000000000000000000 |
10F000000000000000 | <- Fourth pixel of this line is
000000000000000000 | black and 9-12 pixels are
000000000000000000 | also black
000000000000000000 |
000000000000000000 |
000000000000000000 |
000000000000000000 |
000000000000000000 |
000000000000000000 |
000000000000000001 | <- Last pixel of this
| row/bitmap is black

For more information, please refer to the Smart Messaging Specification 3.0.0.

Top of page

12. How can I encode ringing tone message user data (8 bit)?
This example shows how to encode the ringing tone message user data. The length of the user data is 37 octets, which is 25 in hexadecimal presentation.

Here is the hex coded user data and the details of the data are explained in the tables 5 and 6.

06050415810000024A3A51D195CDD004001B2055059061056055855
0548540820849900000

Table 5. Ringing tone message user data (length 37 octets -> hex 25)

Octet number | Value | Description
1 | 06 | Length of the User Data Header
2 | 05 | IEI - Information Element Identifier (Application port addressing scheme, 16 bit port address)
3 | 04 | IEDL - Information Element Data Length
4 | 15 | Information Element Data (octets 4 & 5 --> 1581 - destination port)
5 | 81 | Information Element Data
6 | 00 | Information Element Data (octets 6 & 7 --> 0000 - originator port)
7 | 00 | Information Element Data

The rest of the user data (024A3A51D195CDD004001B2055059061056055855054854082084
9900000) has been encoded from the bit string which is explained in the table 6. The whole bit string must be devided to octets and then transferred to hex code. For more information please refer to the Smart Messaging Specification 3.0.0.

Table 6. Ringing tone bit string

Bit string | Description | Value
00000010 | <command-length> | Number of command part presents
01001010 | <ringing-tone-programming> | Command part 1 (with filler bit)
0011101 | <sound> | Command part 2
001 | <basic song type> |
0100 | <song title length> | 4 characters (ISO-8859-1)
01110100 | the first character | t
01100101 | the second character | e
01110011 | the third character | s
01110100 | the fourth character | t
00000001 | <song sequence length> | 1 song patterns
000 | <pattern header> | pattern header id
00 | <pattern id> | A-part
0000 | <loop value> | no loop
00001101 | <pattern specifier> | <length of the new pattern> 13 pattern instructions
100 | <tempo instruction id> |
10000 | <beats per minute> | 160 (i.e. length of 1/4 note = 0,38 sec.)
001 | <note instruction id> |
0101 | <note value> | note E
010 | <note duration> | 1/4 note
00 | <note duration specifier> | no special duration
001 | <note instruction id> |
0110 | <note value> | note F
010 | <note duration> | 1/4 note
00 | <note duration specifier> | no special duration
001 | <note instruction id> |
1000 | <note instruction> | note G
010 | <note duration> | 1/4 note
00 | <note duration specifier> | no special duration
001 | <note instruction id> |
0101 | <note value> | note E
100 | <note duration> | 1/16 note
00 | <note duration specifier> | no special duration
001 | <note instruction id> |
0101 | <note value> | note E
011 | <note duration> | 1/8 note
00 | <note duration specifier> | no special duration
001 | <note instruction id> |
0101 | <note value> | note E
010 | <note duration> | 1/4 note
00 | <note duration specifier> | no special duration
001 | <note instruction id> |
0101 | <note value> | note E
001 | <note duration> | 1/2 note
00 | <note duration specifier> | no special duration
001 | <note instruction id> |
0101 | <note value> | note E
000 | <note duration> | full note
00 | <note duration specifier> | no special duration
010 | <scale instruction id> |
00 | <note scale> | Scale-1 (i.e. Note A is 440 Hz)
001 | <note instructon id> |
0000 | <note value> | pause
010 | <note duration> | 1/4 note
00 | <note duration specifier> | no special duration
010 | <scale instruction id> |
01 | <note scale> | Scale-2 (i.e. Note A is 880 Hz), default
001 | <note instruction id> |
1001 | <note value> | Gis i.e. As'
000 | <note duration> | full note
00 | <note duration specifier> | no special duration
0000000 |  | filler bits
00000000 | <command end> | The end of the ringing tone data

Top of page

13. How can I encode vCard message user data (8 bit)?

This example shows how to encode the vCard message userdata.

The vCard message content is:

> BEGIN:VCARD
> VERSION:2.1
> N:Smith;Mike
> TEL;PREF:+55512345
> END:VCARD

Here is the hex coded user data of the example above. The details of the data are explained in the table 7. The length of the user data is 78 octets, which is 4E in hexadecimal presentation.

06050423F40000424547494E3A56434152440D0A56455253494F4E
3A322E310D0A4E3A536D6974683B4D696B650D0A54454C3B5052
45463A2B35353531323334350D0A454E443A56434152440D0A

Table 7. vCard message user data (length 78 octets -> hex 4E)

Octet number | Value | Description
1 | 06 | Length of the User Data Header
2 | 05 | IEI - Information Element Identifier (Application port addressing scheme, 16 bit port address)
3 | 04 | IEDL - Information Element Data Length
4 | 23 | Information Element Data (octets 4 & 5 --> 23F4 - destination port)
5 | F4 | Information Element Data
6 | 00 | Information Element Data (octets 6 & 7 --> 0000 - originator port)
7 | 00 | Information Element Data
8 | 42 | B
9 | 45 | E
10 | 47 | G
11 | 49 | I
12 | 4E | N
13 | 3A | :
14 | 56 | V
15 | 43 | C
16 | 41 | A
17 | 52 | R
18 | 44 | D
19 | 0D | <CR> Carriage Return
20 | 0A | <LF> Line Feed
21 | 56 | V
22 | 45 | E
23 | 52 | R
24 | 53 | S
25 | 49 | I
26 | 4F | O
27 | 4E | N
28 | 3A | :
29 | 32 | 2
30 | 2E | .
31 | 31 | 1
32 | 0D | <CR> Carriage Return
33 | 0A | <LF> Line Feed
34 | 4E | N
35 | 3A | :
36 | 53 | S
37 | 6D | m
38 | 69 | i
39 | 74 | t
40 | 68 | h
41 | 3B | ;
42 | 4D | M
43 | 69 | i
44 | 6B | k
45 | 65 | e
46 | 0D | <CR> Carriage Return
47 | 0A | <LF> Line Feed
48 | 54 | T
49 | 45 | E
50 | 4C | L
51 | 3B | ;
52 | 50 | P
53 | 52 | R
54 | 45 | E
55 | 46 | F
56 | 3A | :
57 | 2B | +
58 | 35 | 5
59 | 35 | 5
60 | 35 | 5
61 | 31 | 1
62 | 32 | 2
63 | 33 | 3
64 | 34 | 4
65 | 35 | 5
66 | 0D | <CR> Carriage Return
67 | 0A | <LF> Line Feed
68 | 45 | E
69 | 4E | N
70 | 44 | D
71 | 3A | :
72 | 56 | V
73 | 43 | C
74 | 41 | A
75 | 52 | R
76 | 44 | D
77 | 0D | <CR> Carriage Return
78 | 0A | <LF> Line Feed

Top of page

14. How can I encode vCalendar message user data (8 bit)?

This example shows how to encode vCalendar message user data.

The vCalendar message content is:

> BEGIN:VCALENDAR
> VERSION:1.0
> BEGIN:VEVENT
> DESCRIPTION:Steering Group meeting in Portal
> DTSTART:20000906T100000
> DTEND:20000906T120000
> END:VEVENT
> END:VCALENDAR

Here is the hex coded user data and the details of the data are explained in the tables 8a and 8b. The length of the user data is so long that the message must be sent as a concatenated message (two parts). The length of the first part is 140 (dec) which is 8C (hex), and the length of the second part is 49 (dec) which is 31 (hex).

The first part:
0B050423F500000003020201424547494E3A5643414C454E444152
0D0A56455253494F4E3A312E300D0A424547494E3A564556454E54
0D0A4445534352495054494F4E3A5374656572696E672047726F75
70206D656574696E6720696E20506F7274616C0D0A445453544152
543A3230303030393036543130303030300D0A4454454E443A3230
3030303930

The second part:
0B050423F50000000302020236543132303030300D0A454E443A56
4556454E540D0A454E443A5643414C454E4441520D0A

Table 8a. The first part of the vCalendar message user data. (length 140 octets -> hex 8C)

Octet number | Value | Description
1 | 0B | Length of the User Data Header
2 | 05 | IEI - Information Element Identifier (Application port addressing scheme, 16 bit port address)
3 | 04 | IEDL - Information Element Data Length
4 | 23 | Information Element Data (octets 4 & 5 --> 23F5 - destination port) .
5 | F5 | Information Element Data
6 | 00 | Information Element Data (octets 6 & 7 --> 23F5 - destination port)
7 | 00 | Information Element Data
8 | 00 | IEI - Information Element Identifier (Concatenated short message, 8 bit reference number)
9 | 03 | IEDL - Information Element Data Length
10 | 02 | Information Element Data (Concatenated short message reference number)
11 | 02 | Information Element Data (Total number of (concatenated) messages (0-255))
12 | 01 | Information Element Data (Sequence number of current short message)
13 | 42 | B
14 | 45 | E
15 | 47 | G
16 | 49 | I
17 | 4E | N
18 | 3A | :
19 | 56 | V
20 | 43 | C
21 | 41 | A
22 | 4C | L
23 | 45 | E
24 | 4E | N
25 | 44 | D
26 | 41 | A
27 | 52 | R
28 | 0D | <CR> Carriage Return
29 | 0A | <LF> Line Feed
30 | 56 | V
31 | 45 | E
32 | 52 | R
33 | 53 | S
34 | 49 | I
35 | 4F | O
36 | 4E | N
37 | 3A | :
38 | 31 | 1
39 | 2E | .
40 | 30 | 0
41 | 0D | <CR> Carriage Return
42 | 0A | <LF> Line Feed
43 | 42 | B
44 | 45 | E
45 | 47 | G
46 | 49 | I
47 | 4E | N
48 | 3A | :
49 | 56 | V
50 | 45 | E
51 | 56 | V
52 | 45 | E
53 | 4E | N
54 | 54 | T
55 | 0D | <CR> Carriage Return
56 | 0A | <LF> Line Feed
57 | 44 | D
58 | 45 | E
59 | 53 | S
60 | 43 | C
61 | 52 | R
62 | 49 | I
63 | 50 | P
64 | 54 | T
65 | 49 | I
66 | 4F | O
67 | 4E | N
68 | 3A | :
69 | 53 | S
70 | 74 | t
71 | 65 | e
72 | 65 | e
73 | 72 | r
74 | 69 | i
75 | 6E | n
76 | 67 | g
77 | 20 | <SPACE>
78 | 47 | G
79 | 72 | r
80 | 6F | o
81 | 75 | u
82 | 70 | p
83 | 20 | <SPACE>
84 | 6D | m
85 | 65 | e
86 | 65 | e
87 | 74 | t
88 | 69 | i
89 | 6E | n
90 | 67 | g
91 | 20 | <SPACE>
92 | 69 | i
93 | 6E | n
94 | 20 | <SPACE>
95 | 50 | P
96 | 6F | o
97 | 72 | r
98 | 74 | t
99 | 61 | a
100 | 6C | I
101 | 0D | <CR> Carriage Return
102 | 0A | <LF> Line Feed
103 | 44 | D
104 | 54 | T
105 | 53 | S
106 | 54 | T
107 | 41 | A
108 | 52 | R
109 | 54 | T
110 | 3A | :
111 | 32 | 2
112 | 30 | 0
113 | 30 | 0
114 | 30 | 0
115 | 30 | 0
116 | 39 | 9
117 | 30 | 0
118 | 36 | 6
119 | 54 | T
120 | 31 | 1
121 | 30 | 0
122 | 30 | 0
123 | 30 | 0
124 | 30 | 0
125 | 30 | 0
126 | 0D | <CR> Carriage Return
127 | 0A | <LF> Line Feed
128 | 44 | D
129 | 54 | T
130 | 45 | E
131 | 4E | N
132 | 44 | D
133 | 3A | :
134 | 32 | 2
135 | 30 | 0
136 | 30 | 0
137 | 30 | 0
138 | 30 | 0
139 | 39 | 9
140 | 30 | 0

Table 8b. The second part of the vCalendar message user data. (length 49 octets -> hex 31)

Octet number | Value | Description
1 | 0B | Length of the User Data Header
2 | 05 | IEI - Information Element Identifier (Application port addressing scheme, 16 bit port address)
3 | 04 | IEDL - Information Element Data Length
4 | 23 | Information Element Data (octets 4 & 5 --> 23F5 - destination port)
5 | F5 | Information Element Data
6 | 00 | Information Element Data (octets 6 & 7 --> 0000 - originator port)
7 | 00 | Information Element Data
8 | 00 | IEI - Information Element Identifier (concatenated short message, 8 bit reference number)
9 | 03 | IEDL - Information Element Data Length
10 | 02 | Information Element Data (Concatenated short message reference number)
11 | 02 | Information Element Data (Total number of (concatenated) messages (0-255))
12 | 02 | Information Element Data (Sequence number of current short message)
13 | 36 | 6
14 | 54 | T
15 | 31 | 1
16 | 32 | 2
17 | 30 | 0
18 | 30 | 0
19 | 30 | 0
20 | 30 | 0
21 | 0D | <CR> Carriage Return
22 | 0A | <LF> Line Feed
23 | 45 | E
24 | 4E | N
25 | 44 | D
26 | 3A | :
27 | 56 | V
28 | 45 | E
29 | 56 | V
30 | 45 | E
31 | 4E | N
32 | 54 | T
33 | 0D | <CR> Carriage Return
34 | 0A | <LF> Line Feed
35 | 45 | E
36 | 4E | N
37 | 44 | D
38 | 3A | :
39 | 56 | V
40 | 43 | C
41 | 41 | A
42 | 4C | L
43 | 45 | E
44 | 4E | N
45 | 44 | D
46 | 41 | A
47 | 52 | R
48 | 0D | <CR> Carriage Return
49 | 0A | <LF> Line Feed

Top of page

15. How can I restore the original operator logo?

The easiest way to remove previously downloaded operator logo and restore the original one is to send almost normal operator logo message to the phone. The differences to the normal operator logo message are values of the octets 9, 10 and 11, which determine values of the MCC and MNC. The octets must have different values than the current operator's values. For example the values of the octets 9 - 11 could be 000000. The content of the OTA bitmap has no relevance in the message, therefore the OTA bitmap data can be missing (header information is mandatory). When receiving this kind of operator logo message the logo must be saved and after that the original operator logo appears on the screen.

For example, the userdata of the message which removes old operator logo:

06050415820000300000000A00000001

The description of the user data octets is explained in detail in the FAQ question 9 (table 3a).

Top of page

16. How can I encode Picture message user data (8 bit)?

This example shows how to encode Picture message user data. The example includes a picture and text "Test".

The length of the Picture message user data is so long that the message must be sent as a concatenated message (three parts). Here is the hex coded user data and the details of the data are explained in tables 9a, 9b and 9c. The length of the first part is 140 (dec) which is 8C (hex), the length of the second part is 140 (dec) which is 8C (hex), and the length of the third part is 23 (dec) which is 17 (hex).

The first part:
0B0504158A00000003010301300000045465737402010000481C01666
6666666666666669999999999999999998000000000000000014000000
06000E000024000000E900310000280000031080CF3B8018000004004
11044401400000FFFE2F8B12024000000000538CAA02800000000062
89C4018000000000414140014000000000014280024000200000

The second part:
0B0504158A00000003010302014280028001F0000000A28001800FFE0
00000A500015FFFFFFFFFFEA57FFA400AAA00000055000282015004
40015D08A1881024800040FF0201404100010003ABE00244000008200
D55588280101440001AAAAC0180000000003555560140010000806AA
AAB0240000000005555550280000000000000000199999999999999

The third part:
0B0504158A000000030103039999666666666666666666

For more information, please refer to the Smart Messaging Specification 3.0.0.

Table 9a. The first part of the Picture message user data. (length 140 octets -> hex 8C)

Octet number | Value | Description
1 | 0B | Length of the User Data Header
2 | 05 | IEI - Information Element Identifier (Application port addressing scheme, 16 bit port address)
3 | 04 | IEDL - Information Element Data Length
4 | 15 | Information Element Data (octets 4 & 5 --> 158A - destination port)
5 | 8A | Information Element Data
6 | 00 | Information Element Data (octets 6 & 7 --> 0000 - originator port)
7 | 00 | Information Element Data
8 | 00 | IEI - Information Element Identifier (Concatenated short message, 8 bit reference number)
9 | 03 | IEDL - Information Element Data Length
10 | 01 | Information Element Data (Concatenated short message reference number)
11 | 03 | Information Element Data (Total number of (concatenated) messages (0-255))
12 | 01 | Information Element Data (Sequence number of current short message)
13 | 30 | Identifier for version, current version is (ASCII) zero "0". If it is not "0", stop the processing the message.
14 | 00 | "00" <Item-length> <ISO-8859-1-char>*
15 | 00 | Text length (octets 15 & 16)
16 | 04 | Text length (octets 15 & 16)
17 | 54 | T
18 | 65 | e
19 | 73 | s
20 | 74 | t
21 | 02 | "02" = <Item length> <OTA bitmap>
22 | 01 | <Item-length> (octets 22 & 23) value 0100(hex) = 256(dec) = 4 octets for header and the rest for OTA bitmap data
23 | 00 | <Item-length> (octets 22 & 23) value 0100(hex) = 256(dec) = 4 octets for header and the rest for OTA bitmap data
24 | 00 | The first byte of the bitmap must be 00 (hex); i.e. OTA bitmap header field 'number of animated icons' must hold 0, indicating that there is no animation, just a single static image.
25 | 48 | width = 48(hex) = 72(dec)
26 | 1C | height = 1C(hex) = 28(dec)
27 | 01 | The depth of the bitmap (number of grey scales)
28-140 | Value: 66666666666666666699999999999999999980000 0000000000001400000006000E000024000000E90031000 0280000031080CF3B801800000400411044401400000FFF E2F8B12024000000000538CAA0280000000006289C4018 000000000414140014000000000014280024000200000 Description: OTA bitmap visible data

Table 9b. The second part of the Picture message user data. (length 140 octets -> hex 8C)

Octet number | Value | Description
1 | 0B | Length of the User Data Header
2 | 05 | IEI - Information Element Identifier (Application port addressing scheme, 16 bit port address)
3 | 04 | IEDL - Information Element Data Length
4 | 15 | Information Element Data (octets 4 & 5 --> 158A - destination port)
5 | 8A | Information Element Data
6 | 00 | Information Element Data (octets 6 & 7 --> 0000 - originator port)
7 | 00 | Information Element Data
8 | 00 | IEI - Information Element Identifier (concatenated short message, 8 bit reference number)
9 | 03 | IEDL - Information Element Data Length
10 | 01 | Information Element Data (Concatenated short message reference number)
11 | 03 | Information Element Data (Total number of (concatenated) messages (0-255))
12 | 02 | Information Element Data (Sequence number of current short message)
13-140 | Value: 014280028001F0000000A28001800FFE000000A5 00015FFFFFFFFFFEA57FFA400AAA00000055000282015 00440015D08A1881024800040FF0201404100010003ABE 00244000008200D55588280101440001AAAAC018000000 0003555560140010000806AAAAB0240000000005555550 280000000000000000199999999999999 Description: OTA bitmap visible data continues

Table 9c. The third part of the Picture message user data. (length 23 octets -> hex 17)

Octet number | Value | Description
1 | 0B | Length of the User Data Header
2 | 05 | IEI - Information Element Identifier (Application port addressing scheme, 16 bit port address)
3 | 04 | IEDL - Information Element Data Length
4 | 15 | Information Element Data (octets 4 & 5 --> 158A - destination port)
5 | 8A | Information Element Data
6 | 00 | Information Element Data (octets 6 & 7 --> 0000 - originator port)
7 | 00 | Information Element Data
8 | 00 | IEI - Information Element Identifier (Concatenated short message, 8 bit reference number)
9 | 03 | IEDL - Information Element Data Length
10 | 01 | Information Element Data (Concatenated short message reference number)
11 | 03 | Information Element Data (Total number of (concatenated) messages (0-255))
12 | 03 | Information Element Data (Sequence number of current short message)
13-23 | Value: 9999666666666666666666 Description: The rest of the OTA bitmap visible data

Top of page

17. How can I encode Downloadable Profile message user data (8 bit)?
This example shows how to encode Downloadable Profile message user data. The profile message example includes three parts: profile name, ringing tone and screen saver.

The length of the Downloadable Profile message user data is so long that the message must be sent as a concatenated message (four parts). Here is the hex coded user data and the details of the data are explained in tables 10a, 10b, 10c and 10d. The length of parts 1-3 is 140 (dec) which is 8C (hex), and length of the fourth part is 54 (dec) which is 36 (hex).

The first part:
0B0504158A00000003010401300400100053004D0053002000540065
00730074030090024A3A6589C9A585B989BDC9D40400C920A2AC2
2D49C81A61A428AB08B52720698690A26C49C69A8186184289B12
71A6A0618610A2AC22D49C81A61A428AB08B52720698692698A22
C26C2A826C22C49A2106186186288B09B0AA09B0AA09B0AB49C1
2718618718A22

The second part:
0B0504158A00000003010402C26849C6289A12718A26849C61A6288B
09B0AA09B0AA08B0AA52698A22C26C2A826C22C49A200006010000
481C0180000BFFFFFFD00001410012000000480082210022FFFFFF44
008411FC42800001423F88090082BFFFFD410090050102A000054080
A0000002AFFFF5400000000002A80015400000009802ABFFD5403F
8001

The third part:
0B0504158A000000030104032402AA0055402480112402AAFF554024
80392402AA815540208054C802AABD55402080100002AAA555400000
100002AAA555400000110402AABD55401300110402AA815540248011
2402AAFF55402480012402AA005540248001FC02ABFFD54019000000
02A80015400000000002AFFFF5400000050102A000054080A0090082

The fourth part:
0B0504158A00000003010404BFFFFD41009011FC42800001423F8821
0022FFFFFF44008441001200000048008280000BFFFFFFD00001

For more information, please refer to the Smart Messaging Specification 3.0.0.

Table 10a. The first part of the Downloadable Profile message user data. (length 140 octets -> hex 8C)

Octet number | Value | Description
1 | 0B | Length of the User Data Header
2 | 05 | IEI - Information Element Identifier (Application port addressing scheme, 16 bit port address)
3 | 04 | IEDL - Information Element Data Length
4 | 15 | Information Element Data (octets 4 & 5 --> 158A - destination port)
5 | 8A | Information Element Data
6 | 00 | Information Element Data (octets 6 & 7 --> 0000 - originator port)
7 | 00 | Information Element Data
8 | 00 | IEI - Information Element Identifier (Concatenated short message, 8 bit reference number)
9 | 03 | IEDL - Information Element Data Length
10 | 01 | Information Element Data (Concatenated short message reference number)
11 | 04 | Information Element Data (Total number of (concatenated) messages (0-255))
12 | 01 | Information Element Data (Sequence number of current short message)
13 | 30 | Identifier for version, current version is (ASCII) zero "0". If it is not "0", stop the processing the message.
14 | 04 | Item type 04 (Item length & Profile Name). The profile name must be encoded to unicode characters.
15 | 00 | Item length (octets 15 & 16)
16 | 10 | Item length (octets 15 & 16)
17 | 00 |
18 | 53 | S
19 | 00 |
20 | 4D | M
21 | 00 |
22 | 53 | S
23 | 00 |
24 | 20 | <space>
25 | 00 |
26 | 54 | T
27 | 00 |
28 | 65 | e
29 | 00 |
30 | 73 | s
31 | 00 |
32 | 74 | t
33 | 03 | Item type 03 (ringing tone)
34 | 00 | Item length (octets 34 & 35)
35 | 90 | Item length (octets 34 & 35)
36-140 | Value: 024A3A6589C9A585B989BDC9D40400C920A2AC22D49 C81A61A428AB08B52720698690A26C49C69A8186184 289B1271A6A0618610A2AC22D49C81A61A428AB08B5 2720698692698A22C26C2A826C22C49A21061861862 88B09B0AA09B0AA09B0AB49C12718618718A22 Description: Ringing tone data. For more information of encoding a ringing tone format, please refer to the FAQ question 12 ("How can I encode ringing tone user data (8bit)?") and the Smart Messaging specification.

Table 10b. The second part of the Downloadable Profile message user data. (length 140 octets -> hex 8C)

Octet number | Value | Description
1 | 0B | Length of the User Data Header
2 | 05 | IEI - Information Element Identifier (Application port addressing scheme, 16 bit port address)
3 | 04 | IEDL - Information Element Data Length
4 | 15 | Information Element Data (octets 4 & 5 --> 158A - destination port)
5 | 8A | Information Element Data
6 | 00 | Information Element Data (octets 6 & 7 --> 0000 - originator port)
7 | 00 | Information Element Data
8 | 00 | IEI - Information Element Identifier (Concatenated short message, 8 bit reference number)
9 | 03 | IEDL - Information Element Data Length
10 | 01 | Information Element Data (Concatenated short message reference number)
11 | 04 | Information Element Data (Total number of (concatenated) messages (0-255))
12 | 02 | Information Element Data (Sequence number of current short message)
13-52 | Value: C26849C6289A12718A26849C61A6288B09B0AA09B0AA 08B0AA52698A22C26C2A826C22C49A2000 Description: Ringing tone data continues.
55 | 06 | Item type 06 (screen saver)
56 | 01 | Item length (octets 56 & 57). Length is 256 bytes
57 | 00 | Item length (octets 56 & 57). Length is 256 bytes
58-140 | Value: 00481C0180000BFFFFFFD000014100120000004800822 10022FFFFFF44008411FC42800001423F88090082BFFF FD410090050102A000054080A0000002AFFFF54000000 00002A80015400000009802ABFFD5403F8001 Description: OTA bitmap format, 72x28 bitmap. For more information, please refer to the FAQ question 11 ("How can I encode an OTA bitmap?") and the Smart Messaging specification.

Table 10c. The third part of the Downloadable Profile message user data. (length 140 octets -> hex 8C)

Octet number | Value | Description
1 | 0B | Length of the User Data Header
2 | 05 | IEI - Information Element Identifier (Application port addressing scheme, 16 bit port address)
3 | 04 | IEDL - Information Element Data Length
4 | 15 | Information Element Data (octets 4 & 5 --> 158A - destination port)
5 | 8A | Information Element Data
6 | 00 | Information Element Data (octets 6 & 7 --> 0000 - originator port)
7 | 00 | Information Element Data
8 | 00 | IEI - Information Element Identifier (Concatenated short message, 8 bit reference number)
9 | 03 | IEDL - Information Element Data Length
10 | 01 | Information Element Data (Concatenated short message reference number)
11 | 04 | Information Element Data (Total number of (concatenated) messages (0-255))
12 | 03 | Information Element Data (Sequence number of current short message)
13-140 | Value: 2402AA0055402480112402AAFF55402480392402AA815 540208054C802AABD55402080100002AAA55540000010 0002AAA555400000110402AABD55401300110402AA815 5402480112402AAFF55402480012402AA005540248001 FC02ABFFD5401900000002A80015400000000002AFFFF 5400000050102A000054080A0090082 Description: The OTA bitmap data continues.

Table 10d. The fourth part of the Downloadable Profile message user data. (length 54 octets -> hex 36)

Octet number | Value | Description
1 | 0B | Length of the User Data Header
2 | 05 | IEI - Information Element Identifier (Application port addressing scheme, 16 bit port address)
3 | 04 | IEDL - Information Element Data Length
4 | 15 | Information Element Data (octets 4 & 5 --> 158A - destination port)
5 | 8A | Information Element Data
6 | 00 | Information Element Data (octets 6 & 7 --> 0000 - originator port)
7 | 00 | Information Element Data
8 | 00 | IEI - Information Element Identifier (Concatenated short message, 8 bit reference number)
9 | 03 | IEDL - Information Element Data Length
10 | 01 | Information Element Data (Concatenated short message reference number)
11 | 04 | Information Element Data (Total number of (concatenated) messages (0-255))
12 | 04 | Information Element Data (Sequence number of current short message)
13-54 | Value: BFFFFD41009011FC42800001423F88210022FFFFFF440 08441001200000048008280000BFFFFFFD00001 Description: The rest of the OTA bitmap data.

18. How can I encode concatenated SMS message?

The User Data part of an SMS is limited to 140 octets. With some Smart Messaging formats there is more than 140 octets of User Data, and so these must be sent using a series of messages. The User Data parts of these messages are then concatenated (after stripping off the User Data Headers) to form the full message.

The octets which specify the concatenation are defined in the User Data Header of each SMS in the series. There are five (5) octets required as follows:

Table 11. Description of extra octets needed for concatenated messages

Octet number | Value | Description
1 | 00 | IEI - Information Element Identifier (Concatenated short message, 8 bit reference number)
2 | 03 | IEDL - Information Element Data Length
3 | 01 | Information Element Data (Concatenated short message reference number)
4 | 05 | Information Element Data (Total number of (concatenated) messages (0-255))
5 | 01 | Information Element Data (Sequence number of current short message)

The reference number can be anything, so long as it is unique for each series of messages sent. As an example in a 5-part series with the reference number=10 decimal (A hex) these octets would be:

Table 12. Example of "Concatenation octets" for a 5-message series (reference number 10 -> hex A)

SMS number | "Concatenation octets"
1 | 00030A0501
2 | 00030A0502
3 | 00030A0503
4 | 00030A0504
5 | 00030A0505

Note that this set of octets is only one part of the User Data Header. For a full example, please see question 8.

Top of page

19. How can I encode a 72X14 operator logo as a single message, and is it even an acceptable format, as it doesn't seem to follow the specification?

The User Data part of an SMS is limited to 140 octets. The User Data Header takes 7 octets (1 length-of-user-data-header, 1 address, 1 address-length, 4 address itself). The actual bitmap part of a 72x14 OTA bitmap takes 9x14 = 126 octets. The OTA bitmap headers, when constructed according to specifications, take 9 more octets (1 OTA bitmap-version-number, 3 MCC+MNC, 1 Linefeed, 1 InfoField, 1 width, 1 height, 1 depth). (See Table 3a of question 9.) This makes a total of 142 octets - too long by an annoying two octets! This means that according to the specifications, any operator logo would require two SMS messages.

There is a workaround which allows these logos to be sent using only one SMS. This workaround currently works with Nokia phones, but no support for single-message logos can be promised to nor should it be assumed by developers. It must be stressed that functioning of single-message logos in future Nokia terminals or terminals provided by other vendors supporting Smart Messaging cannot be guaranteed. (Note that a 72x13 OTA bitmap will fit into a single SMS message and still comply with specifications! These types of bitmaps will be guaranteed to be compatible, whereas a 72x14 logo sent using the method described below will not.)

In any case, the workaround for a 72x14 logo is such that the two octets on either side of the MCC+MNC octets are left out completely. These octets are the OTA bitmap-version-number and the linefeed character. Thus, the single-SMS version of sending the logo from question 9 is as follows:

Here is the hex coded user data and details of the data are explained in table 13.

0605041582000042F45000480E01FFFFFFFFFFFFFFFFFF00000000
0000000000FFFFFFFFFFFFFFFFFF00000000000000000010F00000
000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000
000000001

Table 13. Single-message operator logo message user data (length 140 octets -> hex 8C)

Octet number | Value | Description
1 | 06 | Length of the User Data Header
2 | 05 | IEI - Information Element Identifier (Application port addressing scheme, 16 bit port address)
3 | 04 | IEDL - Information Element Data Length
4 | 15 | Information Element Data (octets 4 & 5 --> 1582 - destination port)
5 | 82 | Information Element Data
6 | 00 | Information Element Data (octets 6 & 7 --> 0000 - originator port)
7 | 00 | Information Element Data
8 | 42 | MCC (Mobile Country Code), octets 14 and 15, little-endian BCD, filled with F16', 244 -> 42 F4 Notice: To see the logo on the phone's screen, octets 8 and 9 must be defined with the settings of the current operator.
9 | F4
10 | 50 | MNC (Mobile Network Code) coding, little-endian BCD, filled with F16', 05->50
11 | 00 | InfoField, See "Smart Messaging Specification 3.0.0" for details.
12 | 48 | The width of the bitmap. Hex 48->72 decimal
13 | 0E | The height of the bitmap. Hex 0E->14 decimal
14 | 01 | The depth of the bitmap (number of grey sclaes)
15-140 | Value: FFFFFFFFFFFFFFFFFF000000000000000000FFFFFFFFFF FFFFFFFF00000000000000000010F000000000000000000 00000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000 000000000000000 Description: OTA bitmap data.