Example and Description of Message Types supported by TeleSign Mobile

This explanation of message types is independent of particular mobile phone brands and standards. For an explanation of how to set-up specific message types according to the specifications of individual mobile phones, we will be pleased to offer extra assistance.

Browse our HTTP API for more Message Types examples available in our SMS Documentation.

With our HTTP SMS API, or SMPP API it’s quick and easy to integrate SMS messaging services into your applications, websites, software and back-office custom apps.

We provide the high quality delivery characteristics and GSM features as standard, feel free to check: Supported Character Sets, Message Length, Sender ID, Delivery Reporting, Number Porting.

An SMS message can also carry binary data. A binary SMS message has 140 bytes of user data. This user data can be split into two parts; the user data header, and the actual user data. The user data header can be used to inform mobile phones about certain message types. This way SMS can be used to carry operator logos, ringtones, telephone settings and WAP push messages. Examples are available in our documentation.

A Flash SMS appears directly on the phone's screen, instead of the 'Inbox'. It’s a useful alternative to normal SMS when you want to catch the recipient’s attention immediately. The recipient has the option of 'Saving' the Flash SMS to his 'Inbox'.

Multimedia Messaging Service (MMS) is a mobile telephone standard for sending messages that include multimedia objects (images, audio, video, rich text). MMS is an extension of the SMS standard, allowing longer message lengths and using WAP to display the content. Its most popular use is sending photographs from camera-equipped handsets, although it is also popular as a method of delivering ringtones.

Operator logos are graphical images that are displayed on a phone when the phone signs into a GSM network. An operator logo is identified by a country code and a mobile network code. GSM handsets supporting this technology can store more than one image at a time, and when the handset roams between networks, it can display the appropriate operator logo.

When designing operator logos, the designer has to keep in mind that different handsets support operator logos of different dimensions. The most common bitmap size for operator logos is 72x14 pixels.

The OTA or Over The Air Bitmap was defined as part of the Smart Messaging Specification, to send pictures as a series of one or more concatenated SMS text messages. The format has a maximum size of 255x255 pixels. It is very rare for an OTA bitmap to measure anything other than 72x28 pixels (for Picture Messages) or 72x14/72x13 (for Operator Logos). The specification contains a byte of data to be used for indicating a multicolor image. This was to future-proof the standard, but the advent of Multimedia Messaging meant it never got to implementation.

An OTA bitmap is used for various SMS formats; Operator logos, CLI icons, Picture Messages, and Downloadable Profiles. In most phones the maximum size of the operator logo and the CLI icon is 72 x 14 pixels, while the maximum size of the picture message and the screen saver is 72 x 28 pixels. An OTA bitmap consists of a bitmap header and bitmap data. The size of the bitmap is specified in the header.

A typical OTA bitmap (72 x 14 pixels) header is: 00480E01

00	Info field
48	Width of the bitmap is 72 pixels
0E	Height of the bitmap is 14 pixels
00	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. As one row takes 18 semi-octets, the whole 72 x 14 (operator logo and CLI icon) bitmap takes 18 x 14 = 252 semi-octets = 126 octets. Including the picture message and the screen saver, the entire 72 x 28 size bitmap takes 18 x 28 = 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.

Ringtones are little melodies and tunes created to give a unique sound to the GSM phone when the phone is ringing. Ringtones can be composed with an appropriate editor and they can be sent as SMS messages.

You can use this message type to send a business card to a mobile phone. You can include your name, phone numbers (home and work), your fax number, your e-mail and homepage address, your date of birth, as well as a note.

VCalendar defines a transport and platform-independent format for exchanging calendar and schedule information, so that any vCalendar-compliant application can send or receive calender and scheduling information to or from any other vCalendar application. For instance, users with mobile phones running vCalendar-aware applications can schedule meetings automatically over an infrared link or via SMS.

The WAP Push technology makes it possible to send a specially encoded SMS message with a description and link to a WAP address (URL). When a GSM handset receives this WAP Push message, it will automatically give the user the option to access the WAP content. The WAP content can be a WML page, a JAVA application, or multimedia content. WAP Push is also used to send polyphonic ringtones and wallpaper images to phones.
To instruct a phone to go to a certain WAP location, a Service Indication message needs to be used.

WAP Push message is more convenient than a simple text message. In a simple text message the user receives a link to the content, which then has to be entered manually into a browser to be opened. However, if the recipient receives the URL in a WAP Push message, it only takes one or two clicks to open the respective page or content.

You can use this message type to avoid having to commit webpage addresses to memory.

This message type is similar to WAP Push. However, the link sent will be included in the set of bookmarks so you can easily open the page the link leads to in the browser.

OMA OTA settings refer to the setting up of new services, such as GPRS, MMS and Instant Messaging for an existing subscriber of a mobile phone network, and any gateways for standard Internet chat or mail services. Network operators typically send these settings to the subscriber’s handset using SMS or WAP as the mobile operating systems accept.

Browser settings are used to provide handsets with the basic settings needed to establish a connection to be used for browsing, as a method of simplifying the end-user experience.

Using this message type, the necessary parameters can be set by just pressing one or two buttons, avoiding having to manually configure the necessary browser settings.

SyncML settings are used to provide handsets with basic settings needed to establish a sync session with a sync server. These settings may also include authentication information.

SyncML OTA configuration information can be sent to SyncML-compatible mobile phones. This option allows a complete SyncML configuration profile to be sent to a compatible mobile phone.

The WAP Push SL message type makes it possible to send a service loading WAP requests to mobile phones. These requests can contain an URL and a signal level.

Over The Air (OTA) (or Over-The-Air) is a standard for the transmission and reception of application-related information in a wireless communications system. The standard is supported by Nokia, SmartTrust, and others.

OTA is commonly used in conjunction with the Short Messaging Service (SMS), which allows the transfer of small text files even while simultaneously using a mobile phone for more conventional purposes. In addition to short messages and small graphics, such files can contain instructions for subscription activation, banking transactions, ringtones, and Wireless Access Protocol (WAP) settings. OTA messages can be encrypted to ensure user privacy and data security.

This paragraph discusses the short message data coding and the influence of this coding on the available data size.

GSM defines the following (text) data coding options:

• GSM Default Alphabet (7-bits),
• LATIN-1 GSM default 160
• UCS2 (16-bits)

The GSM Default Alphabet looks like the ASCII table (characters 0-127), with the difference that most of the control characters are not present and are replaced by characters from the LATIN-1 upper table (characters 128-255).

As mentioned before, the maximum number of characters is limited to 140 octets. With 140 octets, 160 7-bit, 140 8-bit and 70 16-bit encoded characters can be used. This means when the data coding is set to UCS2, only 70 characters can be sent as the characters are 16-bit encoded by GSM. When the data coding is set to LATIN-1 or SMSC default alphabet, 160 characters can be sent, as the characters are mapped to a 7-bit encoding by GSM.

Max available characters are:

• 1.SMSC default alphabet 0x00 GSM default 160
• 2.LATIN-1 0x03 GSM default 160
• 3.UCS2 0x08 UCS2 70

Depending on the chosen ESME data coding the short message text data is sent from the SMSC to the mobile in one of the following ways:

• Transparently
• Mapped to the default GSM alphabet

When text is sent from ESME to SMSC in USC2 coding the data will be transparently sent to the mobile. When the text is coded in LATIN-1 or the SMSC Default Alphabet, mapping will be performed by the SMSC to the GSM Default Alphabet before sending the text to the mobile. As the GSM Default Alphabet is 7-bit coded and uses other codes for some characters (and in some cases does not even provide a certain character), this implies that during the mapping process not every character can be mapped one-to-one.

As defined by the GSM specifications, concatenation is provided by the use of User Data Headers in each message involved. A User Data Header (UDH) contains and sets the following items:

• The reference group the concatenated short message belongs to (two versions are available: 8-bits and 16-bits)
• The number of concatenated short messages in that group
• The location of the concatenated short message in the complete sequence.

These items enable the receiving application to put the concatenated short messages back together in the right order and determine whether all the short messages have been received.

Table 2: Indicating use of User data header

Example of UDH of two message:

UDH SM 1 : UDHL=05 IEI(1)=00 IEIDL(1)=03 IED(1)=64 IED(1)=02 IED(1)=01

DATA SM 1 :

UDH SM 2 : UDHL=05 IEI(1)=00 IEIDL(1)=03 IED(1)=64 IED(1)=02 IED(1)=02

DATA SM 1 :

The user data header is part of the user data. This means the amount of user data is reduced. The amount of user data left is dependent on the user data coding:

Data coding* Max number of characters

• 1.7-bit data 153
• 2.8-bit data 134
• 3.16-bit data 67