SMS FORUM
`
`SMPP v3.4 Protocol Implementation
`guide for GSM / UMTS
`
`Version 1.0
`
`Apple 1013
`U.S. Pat. 8,243,723
`
`1 of 27
`
`

`
`www.smsforum.net
`
`SMS FORUM
`
`SMPP v3.4 Protocol Implementation guide for
`GSM / UMTS
`May 30th 2002 Version 1.0
`
`©2001 SMS Forum
`
`COPYRIGHT
`All rights reserved. This document or any part thereof may not, without the prior written
`consent of SMS Forum, be copied, reprinted or reproduced in any material form including,
`but without prejudice to the foregoing and not by way of exception photocopying, transcribing
`or storing in any medium or translating into any language, in any form or by any means,
`including but not limited to, electronics, mechanical, xerographic, optical, magnetic, digital or
`other methodology
`
`DISCLAIMER
`WHILST THE GREATEST CARE HAS BEEN TAKEN TO ENSURE THE ACCURACY OF
`THE INFORMATION AND DATA CONTAINED HEREIN, SMS FORUM DOES NOT
`WARRANT THE ACCURACY OR SUITABILITY OF SAME FOR ANY SPECIFIC USE. SMS
`FORUM EXPRESSLY DISCLAIMS ALL AND ANY LIABILITY TO ANY PERSON,
`WHETHER A PURCHASER OR OTHERWISE, IN RESPECT OF ANY CONSEQUENCES
`OF ANYTHING DONE OR OMITTED TO BE DONE BY ANY SUCH PERSON IN PARTIAL
`OR TOTAL RELIANCE UPON THE WHOLE OR ANY PART OF THE CONTENTS OF THIS
`PUBLICATION OR ANY DERIVATIVE THEREOF.
`THE INFORMATION CONTAINED HEREIN IS BELIEVED TO BE ACCURATE AND
`RELIABLE. HOWEVER, SMS FORUM ACCEPTS NO RESPONSIBILITY FOR IT'S USE BY
`ANY MEANS OR IN ANY WAY WHATSOEVER. SMS FORUM SHALL NOT BE LIABLE
`FOR ANY EXPENSE, COSTS OR DAMAGE THAT MAY RESULT FROM THE
`INFORMATION CONTAINED HOWSOEVER ARISING IN THIS DOCUMENT OR ANY
`DERIVATIVE THEREOF.
`THE INFORMATION CONTAINED IN THE WITHIN DOCUMENT AND ANY DERIVATIVE
`THEREOF IS SUBJECT TO CHANGE WITHOUT NOTICE.
`THE SMS FORUM IS COMPANY NUMBER 309113, REGISTERED OFFICE GARDNER
`HOUSE, WILTON PLACE, DUBLIN 2.
`
`GSM/UMTS Imp Guide V1.0 (cid:148) SMS Forum
`
` 2 of 27
`
`

`
`www.smsforum.net
`
`SMS FORUM
`
`Table of Contents
`1.1 Overview.................................................................................................................. 4
`1.2 Scope....................................................................................................................... 4
`1.3 Glossary................................................................................................................... 5
`1.4 References .............................................................................................................. 5
`2.1 Introduction.............................................................................................................. 6
`2.2 Sending regular text................................................................................................. 6
`2.2.1 Operation and fields to use............................................................................. 7
`2.2.1.1 Operations .......................................................................................... 7
`2.2.1.2 Fields .................................................................................................. 7
`2.2.2 Data coding and size...................................................................................... 8
`2.2.2.1 Data coding......................................................................................... 8
`2.2.2.2 Data size............................................................................................. 9
`2.2.3 Mapping.......................................................................................................... 9
`2.2.3.1 Standard mapping............................................................................... 9
`2.2.3.2 Extended mapping............................................................................ 10
`2.2.3.3 Using financial symbols in a short message..................................... 11
`2.2.4 Long messages and Concatenation............................................................. 11
`2.2.4.1 User data headers ............................................................................ 12
`2.2.4.2 SMPP parameters............................................................................. 13
`2.3 Sending binary data, ring tones and operator logos .............................................. 13
`2.3.1 Operation and fields to use........................................................................... 13
`2.3.1.1 Operations ........................................................................................ 13
`2.3.1.2 Fields ................................................................................................ 14
`2.3.2 Data coding .................................................................................................. 14
`2.3.3 User data header.......................................................................................... 15
`2.4 Enhanced messaging service................................................................................ 16
`2.4.1 User data headers........................................................................................ 16
`2.4.2 Concatenation .............................................................................................. 17
`2.5 Using priority.......................................................................................................... 18
`2.6 Requesting notifications......................................................................................... 20
`2.7 Addressing............................................................................................................. 21
`2.7.1 Addressing a mobile..................................................................................... 21
`2.7.2 Addressing an ESME ................................................................................... 21
`2.8 Route messages on a mobile / direct displaying ................................................... 22
`2.9 Setting indications for voice mail, e-mail and FAX................................................. 22
`2.9.1 Return Call Message.................................................................................... 23
`2.9.2 Data Coding Scheme ................................................................................... 24
`2.9.3 User Data Header, Special SMS Message Indication.................................. 24
`2.10
`Up-to-date messaging via message replacement .......................................... 25
`2.10.1 Message replacement on the SMSC ....................................................... 25
`2.10.2 Message replacement at the mobile itself ............................................... 26
`
`GSM/UMTS Imp Guide V1.0 (cid:148) SMS Forum
`
` 3 of 27
`
`

`
`www.smsforum.net
`
`1 Introduction
`
`1.1 Overview
`
`SMS FORUM
`
`The Short Message Peer To Peer (SMPP) protocol is an open, industry standard protocol
`designed to provide a flexible data communication interface for transfer of short message
`data between a Message Centre and a SMS application system. A Bearer Message Centre
`can be a Short Message Service Centre (SMSC), a GSM Unstructured Supplementary
`Services Data (USSD) Server, a Broadcast Message Service Centre or another type of
`Message Centre.
`This document provides guidelines for getting an application based on the SMPP protocol
`version 3.4 specification working in a SMSC/GSM/UMTS network environment.
`
`1.2 Scope
`
`This document provides practical information for developers building ESME applications that
`communicate with a SMSC working in a GSM environment, using SMPP protocol version
`3.4. SMPP features common to all network types or not specifically SMSC related will not be
`discussed.
`The information about the subjects discussed in this document is retrieved from related
`official specification documents, like the SMPP protocol version 3.4 specification, the GSM
`23.038/23.040 and UCS2 specifications.
`In order to keep the document a practical reference manual, the document will not contain
`specific in-depth information that is available in those specifications, but will include them as
`reference.
`For maximising the reading efficiency, it is advisable to download the referenced
`specifications prior to reading this document.
`
`GSM/UMTS Imp Guide V1.0 (cid:148) SMS Forum
`
` 4 of 27
`
`

`
`SMS FORUM
`
`www.smsforum.net
`
`1.3 Glossary
`
`EMS
`ESME
`GSM
`MS
`
`SM
`
`SMPP
`SMSC
`UCS
`UDH
`UMTS
`
`Enhanced Messaging Service
`External Short Message Entity
`Global System for Mobile Communications
`Mobile Station
`Short message
`Short Message Peer To Peer
`Short Message Service Centre
`Universal Character Set
`User Data Header
`Universal Mobile Telecommunications System
`
`1.4 References
`
`At the time of writing the latest versions of below stated documents were used, but for most
`cases other versions of these documents are also applicable as reference for this
`implementation guide.
`
`Ref.
`[SMPP34]
`
`Document Title
`SMPP protocol specifications
`v3.4
`[GSM23038] Alphabets and language-
`specific information
`Technical realization of the
`Short Message Service
`(SMS)
`UCS-2. ISO/IEC 10646
`encoding form: Universal
`Character Set coded in 2
`octets
`
`[GSM23040]
`
`[UCS2]
`
`Version Number
`Issue 1.2
`
`v4.2.0 (release 4)
`
`v5.0.0 (release 5)
`
`Document Number
`SMPP Forum
`http://www.smpp.org
`3GPP TS 23.038
`http://www.3gpp.org
`3GPP TS 23.040
`http://www.3gpp.org
`
`http://www.unicode.or
`g
`
`Table 1-1: References
`
`GSM/UMTS Imp Guide V1.0 (cid:148) SMS Forum
`
` 5 of 27
`
`

`
`www.smsforum.net
`
`2 How To
`
`2.1 Introduction
`
`SMS FORUM
`
`This chapter provides information that can simplify the implementation of an ESME
`application, which is transferring data via short message to a mobile station in a GSM
`network.
`The discussed items are:
`(cid:120)(cid:3) Sending regular text
`(cid:120)(cid:3) Sending binary data
`(cid:120)(cid:3) Sending ring tones
`(cid:120)(cid:3) Sending operator logos
`(cid:120)(cid:3) Enhanced messaging service
`(cid:120)(cid:3) Using priority
`(cid:120)(cid:3) Requesting notifications
`(cid:120)(cid:3) Addressing a mobile
`(cid:120)(cid:3) Addressing an ESME
`(cid:120)(cid:3) Routing a message on a mobile
`(cid:120)(cid:3) Directly message display
`(cid:120)(cid:3) Setting voice mail, e-mail and FAX indications
`(cid:120)(cid:3) Up-to-date messaging via SMSC message replacement
`(cid:120)(cid:3) Up-to-date messaging via mobile message replacement
`Note: an ESME in the context of this document refers to such external sources and sinks of
`short messages as Voice Processing Systems, WAP Proxy Servers or Message Handling
`computers. It excludes SMEs, which are located within the Mobile Network, i.e., a mobile
`station.
`
`2.2 Sending regular text
`
`When sending regular text the following items are important to consider:
`(cid:120)(cid:3) Operation and fields to use
`(cid:120)(cid:3) Data coding and size
`(cid:120)(cid:3) Character mapping
`(cid:120)(cid:3) Concatenation
`These items will be discussed in the following paragraphs.
`
`GSM/UMTS Imp Guide V1.0 (cid:148) SMS Forum
`
` 6 of 27
`
`

`
`www.smsforum.net
`
`2.2.1 Operation and fields to use
`
`SMS FORUM
`
`Two operations and two fields can be used to submit text data to the SMSC. Which
`operation and fields to use are explained in this paragraph.
`
`2.2.1.1 Operations
`An ESME application can send regular text by using the submit_sm or data_sm operation.
`The operation submit_sm is only used by an ESME to submit a short message to the SMSC
`for onward transmission to a specified SME.
`The operation data_sm is used to transfer data between a SMSC and an ESME. The ESME
`may use this operation to request the SMSC to transfer a message to a mobile station and
`the SMSC may also use this operation to transfer a mobile station originated message to an
`ESME. This operation is an alternative to the submit_sm and deliver_sm operations.
`
`Fields
`2.2.1.2
`When using the submit_sm operation the message text data should be inserted in one of the
`following two fields:
`the short_message field (mandatory field)
`(cid:120)(cid:3)
`the message_payload field (optional field)
`(cid:120)(cid:3)
`Simultaneous use of both fields is not allowed.
`When using the short_message field, the sm_length field indicates the length in octets of the
`short_message field data and must be set. If the message_payload field is used the
`sm_length field must be used as well, but will now be set to 0, which indicates the use of
`message_payload field.
`When using the operation data_sm the message text data can only be inserted in the
`message_payload field and the sm_length field is not present.
`For both operations is defined that up to 254 octets can be inserted in the short_message
`field, while the message_payload field is able to contain up to 64K octets. The GSM
`standard however defines a maximum of 140 octets for a single short message and thus
`does not support the transmission of more than these 140 octets per message.
`Therefore, a receiving SMSC will usually not accept a submit operation which will result in a
`short message of >140 octets, unless it has implemented an automatic concatenation
`mechanism, which divides a long message in multiple parts of 140 octets.
`NOTE: although the following issue is more related to SMPP PDU encoding, it is important
`to realise another difference between the short_message field and the message_payload
`field:
`As the short_message field is a mandatory parameter and is defined as an octet string type,
`it needs a NULL character after the short message text. This is not the case for the
`message_payload field, as it is an optional parameter that is based on TLVs.
`For more information about these subjects see document [SMPP34] paragraphs 3.1, 3.1.1,
`3.2.2, 4.4 and 4.7
`
`GSM/UMTS Imp Guide V1.0 (cid:148) SMS Forum
`
` 7 of 27
`
`

`
`www.smsforum.net
`
`2.2.2 Data coding and size
`
`SMS FORUM
`
`This paragraph discusses the short message data coding and the influence of this coding on
`the available data size.
`
`2.2.2.1 Data coding
`When sending text from ESME to the SMSC, it is important that the coding, for text also
`seen as the alphabet, of the short message text inside the SMPP PDU Field is supported by
`the SMSC and defined in such a way that the SMSC is able to interpret it.
`It is important as well to realise that at the other side of the SMSC, when sending a short
`message from a SMSC to a mobile station, coding of the data takes place as well and this
`coding actually determines what is possible at the ESME side.
`GSM defined the following (text) data coding options:
`(cid:120)(cid:3) GSM Default Alphabet (7-bits),
`(cid:120)(cid:3) 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).
`The SMPP specification offers many coding options, but not every offered coding is by
`default implemented at the SMSC. Usually the following are implemented at the SMSC:
`(cid:120)(cid:3) SMSC default alphabet (7 or 8-bits)
`(cid:120)(cid:3) LATIN 1 (8-bits)
`(cid:120)(cid:3) US ASCII (7-bits)
`(cid:120)(cid:3) UCS2 (16-bits)
`The figure below shows the available coding options between an ESME, a SMSC and a
`mobile station:
`
`Supported SMPP data coding
`for ESME to SMSC:
`
`- SMSC default alphabet
` (7/8 bits)
`- Latin 1 (8-bits)
`- UCS2 (16-bits)
`- Binary (8-bits)
`
`Supported GSM data
`coding for SMSC to
`Mobile Station:
`
`- GSM default alphabet
` (7 bits)
`- UCS2 (16 bits)
`- Binary (8-bits)
`
`ESME
`SMSC
`Mobile Station
`Figure 2-1: Coding options between an ESME, SMSC and a mobile station
`
`GSM/UMTS Imp Guide V1.0 (cid:148) SMS Forum
`
` 8 of 27
`
`

`
`www.smsforum.net
`
`SMS FORUM
`
`When to use which coding?
`When LATIN-1 character based text needs to be send the SMPP data_coding parameter
`can be set to 0x03 for LATIN-1 alphabet. It can also be set to 0x00 for SMSC Default
`Alphabet if the ESME character coding is compatible with this character set (contact your
`SMSC vendor).
`When the needed character is not available in the LATIN-1 character set the UCS2 data
`coding can be used. USC2 ensures that all characters present in the USC2 character set,
`like Japanese, Chinese, Hebrew, Arabic, can be send to and displayed by a mobile that
`supports UCS2.
`It is important to realise that an ESME application needs to format the short message text in
`the application development coding as indicated by the data_coding. For example when
`LATIN-1 is chosen and the used ESME platform is not LATIN-1 based, a mapping on the
`ESME has to take place for the ESME specific platform to LATIN-1.
`
`2.2.2.2 Data size
`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 send 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 send, as the characters are mapped to a 7-bit
`encoding by GSM.
`Summary of data coding and characters:
`Character set
`Data_coding parameter Character set Max available
`characters
`160
`160
`70
`
`GSM default
`GSM default
`UCS2
`
`SMSC default alphabet
`LATIN-1
`UCS2
`
`0x00
`0x03
`0x08
`
`Table 2-1: Maximum available characters
`
`2.2.3 Mapping
`
`This paragraph discusses the standard mapping, the extended mapping and how to use
`financial symbols in a short message.
`
`Standard mapping
`2.2.3.1
`Depending on the chosen ESME data coding the short message text data is send from the
`SMSC to the mobile in one of the following ways:
`(cid:120)(cid:3) Transparently
`(cid:120)(cid:3) Mapped to the default GSM alphabet
`When text is send from ESME to SMSC in USC2 coding the data will be transparently send
`to the mobile.
`When the text is coded for example in LATIN-1 or the SMSC Default Alphabet, usually a
`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
`
`GSM/UMTS Imp Guide V1.0 (cid:148) SMS Forum
`
` 9 of 27
`
`

`
`www.smsforum.net
`
`SMS FORUM
`
`The dollar sign $
`
`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.
`Examples of a possible mapping (vendor dependent):
`Type of character
`Result
`Control characters
`All control characters are converted to inverted question
`marks with exception of the control characters line feed, form
`feed and carriage return
`Changes from code 0x24 to code 0x02 of the GSM alphabet,
`but stays the dollar sign $
`The commercial at sign @ Changes from code 0x40 to code 0x00 of the GSM alphabet,
`but stays the commercial at sign @
`Changes from 0x5B to 0x3C, a less-than-sign <
`Changes from 0x5D to 0x3E, a greater-than-sign >
`Changes from 0x7B to 0x28, a left parenthesis (
`Changes from 0x7D to 0x29, a right parenthesis )
`Changes from 0x5C to 0x2F, a forward slash /
`Changes from 0x5E to 0x14, a lambda ¶
`Changes from 0x60 to 0x27, an apostrophe ‘
`Changes from 0x7C to 0x40, an inverted exclamation mark
`Changes from 0x7E to 0x3D, an equal sign =
`
`The left square bracket [
`The right square bracket ]
`The left curly bracket {
`The right curly bracket }
`
`The backward slash \
`The circumflex accent ^
`The grave accent `
`Vertical line |
`The tilde ~
`
`Table 2-2: Mapping
`NOTE: a quick way of finding out the SMSC default alphabet, is to send the @ character
`(0x00) to a mobile, if the SMSC implemented for example the 7-bit GSM table the same
`character will be shown at the GSM etc…
`
`Extended mapping
`2.2.3.2
`The examples of Table 2-2 make clear that by default not every character can be used. To
`overcome this, the GSM Default Alphabet also contains an extension table, which can be
`used to display most of the characters mentioned above. The escape character of the
`default alphabet table, 0x1B, provides access to the extension table and with that the
`characters. This way the characters: |, ^, {,}, [,~,],\ and the even the Euro sign € can be
`displayed on the mobile.
`
`If the mobile does not support the escape facility it should display a space. In the event that
`a MS receives a code where a symbol is not represented, the MS displays the character
`shown in the main default 7-bit alphabet. This applies also to the Euro sign €. If it is not
`supported by the mobile, it will display the regular e symbol.
`
`GSM/UMTS Imp Guide V1.0 (cid:148) SMS Forum
`
` 10 of 27
`
`

`
`www.smsforum.net
`
`SMS FORUM
`
` Using financial symbols in a short message
`2.2.3.3
`By default the LATIN-1 and the GSM-alphabet allow the displaying of the following financial
`signs: Dollar $, Pound £, Yen ¥. The LATIN-1 field data needed to display these characters
`in the same sequence on a mobile would be:
`0x24 0xA3 0xA5 (converted to GSM: 0x02 0x01 0x03)
`What about the Euro sign €? It is not present in the GSM default alphabet, but it is supported
`via the earlier mentioned GSM alphabet escape character method. For the Euro sign to be
`included in the SMPP PDU it must be converted by the ESME to 0x1B 0x65.
`As the Euro sign is on position A4 in ISO LATIN-9 some implementations may use this code
`to display the Euro sign. When an Euro sign is entered in a Windows application, the Euro
`sign will be represented by 0x80 and a conversion has to take place to 0x1B 0x65.
`NOTE: Making use of the escape character implies that two character positions are used for
`displaying one character (a message containing only Euro signs will have the capacity of 80
`characters).
`Summarised:
`ESME Code ESME Character
`0x24
`Dollar sign
`0xA3
`Pound sign
`0xA5
`Yen sign
`0x1B65
`Escape character + Small letter E
`
`GSM Character
`Dollar sign
`Pound sign
`Yen sign
`Euro currency sign
`
`GSM Code
`0x02
`0x01
`0x03
`0x1B65
`extended
`alphabet
`
`Table 2-3: Financial symbols
`
`2.2.4 Long messages and Concatenation
`
`Applications that require more than 160 characters of information transfer can use the
`message_payload parameter which can hold up to a maximum of 64K. However, the
`maximum size supported is SMSC dependent and the application should take this into
`account.
`Another available method for sending more than 160 characters of information is the GSM
`concatenation mechanism. With concatenation it is possible to send several separate short
`messages to a mobile station and to display them as one message.
`Concatenation is realised at the mobile; multiple separated received messages are stringed
`together and displayed as if it was one single short message. The mobile is able to do this,
`as all involved send messages contain an additional information fields that provides
`information needed for stringing them together. Up to a maximum of 255 short messages
`can be concatenated this way.
`Concatenation is provided via two methods:
`(cid:120)(cid:3) GSM User data headers
`(cid:120)(cid:3) SMPP parameters
`
`GSM/UMTS Imp Guide V1.0 (cid:148) SMS Forum
`
` 11 of 27
`
`

`
`www.smsforum.net
`
`SMS FORUM
`
`2.2.4.1 User data headers
`As defined by the GSM specifications, concatenation is provided by use of User Data
`Headers in each involved message.
`A User Data Header (UDH) contains and sets the following items:
`(cid:120)(cid:3) The reference group the concatenated short message belongs to (two versions are
`available: 8-bits and 16-bits),
`(cid:120)(cid:3) The number of concatenated short messages in that group
`(cid:120)(cid:3) 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.
`In order to enable long messages the UDHI must be set in the SMPP parameter esm_class
`and special user date header information must be present in front of the user data.
`Settings for making use of user data header:
`Esm_class PDU data value User data header indication
`Bit 6=1
`Set
`Bit 6=0
`Not set
`
`Table 2-4: 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
`
`: <text part 1-2>
`UDH SM 2
`
`: UDHL=05 IEI(1)=00 IEIDL(1)=03 IED(1)=64 IED(1)=02 IED(1)=02
`DATA SM 1
`
`: <text part 2-2>
`The user data header is part of the user data. This means the amount of user data is
`decreased. The amount of user data left is dependent of the used data coding:
`Data coding* Max number of characters
`8-bit data
`134
`7-bit data
`153
`16-bit data
`67
`
`Table 2-5: Maximum number of characters when using data headers
`* Uncompressed
`
`GSM/UMTS Imp Guide V1.0 (cid:148) SMS Forum
`
` 12 of 27
`
`

`
`www.smsforum.net
`
`SMS FORUM
`
`SMPP parameters
`2.2.4.2
`The SMPP protocol provides the following optional parameters to enable concatenation. Use
`of these SMPP parameters in a GSM environment result in the use of the User Data
`Headers as described in the previous paragraph as well, but the formatting is left to the
`SMSC and not to the ESME application, which makes it easier to use concatenation.
`
`The following parameters need to be set for each short message:
`Type of parameter
`Description
`Sar_msg_ref_num
`Originator generated reference number allowing the parallel
`transmission of several segmented messages.
`The total number of fragments within the concatenated short
`message.
`Sar_segements_seqnum The sequence number of a particular message within the
`concatenated short message.
`
`Sar_total_segments
`
`Table 2-6: SMPP parameters for concatenation
`Related documents:
`[SMPP34] paragraph 5.2.12 / 5.2.19/ 5.3.2.22 / 5.3.2.23 / 5.3.2.24
`[GSM23040] paragraph 9.2.3.24.1
`[GSM23038] paragraph 6.2.1
`
`2.3 Sending binary data, ring tones and operator logos
`
`When sending binary data like ring tones, operator logo’s the following items are important to
`consider:
`(cid:120)(cid:3) Operation and fields to use
`(cid:120)(cid:3) Data coding
`(cid:120)(cid:3) User data header
`(cid:120)(cid:3) Concatenation
`These items will be discussed in the following paragraphs.
`
`2.3.1 Operation and fields to use
`
`Two operations and two fields can be used to submit binary data to the SMSC. Which
`operation and fields to use are explained in this paragraph.
`
`2.3.1.1 Operations
`An ESME application can send binary data by using the submit_sm or data_sm operation.
`The operation submit_sm is only used by an ESME to submit a short message to the SMSC
`for onward transmission to a specified SME.
`The operation data_sm is used to transfer data between a SMSC and an ESME. The ESME
`may use this operation to request the SMSC to transfer a message to a mobile station and
`
`GSM/UMTS Imp Guide V1.0 (cid:148) SMS Forum
`
` 13 of 27
`
`

`
`www.smsforum.net
`
`SMS FORUM
`
`the SMSC may also use this operation to transfer an mobile station originated message to
`an ESME. This operation is an alternative to the submit_sm and deliver_sm operation.
`
`Fields
`2.3.1.2
`Sending binary data can be done with the SMPP submit_sm or data_sm operation.
`When using the submit_sm operation the binary data should be inserted in one of the
`following two fields:
`the short_message field (mandatory)
`(cid:120)(cid:3)
`the message_payload field (optional)
`(cid:120)(cid:3)
`Simultaneous use of both fields is not allowed.
`When using the short_message field, the sm_length field indicates the length in octets of the
`short_message field data and must be set. If the message_payload field is used the
`sm_length field must be used as well, but will now be set to 0, indicating the use of
`message_payload field.
`When using the operation data_sm the binary data can only be inserted in the
`message_payload field and the sm_length field is not present.
`For both operations is defined that up to 254 octets can be inserted in the short_message
`field, while the message_payload field is able to contain up to 64K octets. The GSM
`standard however defines a maximum of 140 octets for a single short message and thus
`does not support the transmission of more than these 140 octets per message.
`Therefore, a receiving SMSC will usually not accept a submit operation which will result in a
`short message of >140 octets, unless it has implemented an automatic concatenation
`mechanism, which divides a long message in multiple parts of 140 octets.
`
`2.3.2 Data coding
`
`An ESME uses a binary coding to send specific non-text data to a mobile, such as setting a
`ring tone or operator logo. This is done by setting the data_coding parameter to the value
`0x04.
`
`GSM/UMTS Imp Guide V1.0 (cid:148) SMS Forum
`
` 14 of 27
`
`

`
`www.smsforum.net
`
`2.3.3 User data header
`
`SMS FORUM
`
`The binary user data may contain just the plain data itself but it can also contain a header in
`addition to the user data. This header is called the User Data Header (UDH).
`The user data header allows a user to include data in a special format, for example in the
`case of ring tones, operator logo’s etc., and to enable data concatenation (dividing data over
`several short messages).
`It is also used for Enhanced Messaging. For Enhanced Messaging see the topic about the
`Enhanced Messaging Service in section 2.4.
`The esm_class parameter is set to indicate that the binary data includes a user data header.
`Settings to indicate the use of a user data header:
`Esm_class PDU data value User data header indication
`Bit 6=1
`Set
`Bit 6=0
`Not set
`
`Table 2-7: Indicating use of User data header
`A user data header is constructed by information elements that are defined by the GSM
`specification. Each element has its own function, for example the User Data Header
`information element “Application port addressing scheme” is used to route short messages
`to one of multiple applications in the mobile via a predefined port.
`Sending data to such a specific port is often used for setting ring-tones and operator logo’s.
`The ports to address are mobile vendor dependent. Specific information for the mobile that is
`used can be obtained from the mobile phone vendor.
`The following example shows the user data header and a part of the binary data for sending
`a ring tone to a mobile via two short messages:
`
`UDH SM 1
`Data SM 1
`UDH SM 2
`Data SM 2
`Whereby:
`UDHL
`IEI
`
`IEIDL
`IED
`
`
`
`
`
`
`
`: UDHL=0B IEI(1)=05 IEIDL(1)=04 IED(1)=15810000 IEI(2)=00 IEIDL(2)=03 IED(2)=010201
`: 024A3A5DA5D185B1A58… (data partly shown)
`: UDHL=0B IEI(1)=05 IEIDL(1)=04 IED(1)=15810000 IEI(2)=00 IEIDL(2)=03 IED(2)=010202
`: B49C0920930AB12718A… (data partly shown)
`
`= User Date Header Length
`= Information Element Identifier
`= Information Element Identifier Data Length
`= Information Element Data
`
`GSM/UMTS Imp Guide V1.0 (cid:148) SMS Forum
`
` 15 of 27
`
`

`
`www.smsforum.net
`
`SMS FORUM
`
`Explanation of UDH:
`Value
`Meaning
`0B
`Indicating the total UDH length
`05 04 15810000 A 16 bit application port addressing schema is used with destination
`port 1581 and originator port 0000
`Indicates the use of concatenated messaging that is build by two
`messages and this is the first message.
`
`00 03 01 02 01
`
`Table 2-8: Explanation of UDH
`As mentioned before, the user data header is part of the user data itself, meaning that the
`actual available user date will be less than the mentioned maximum. This is an important
`issue.
`For example, in the short messages discussed before, each user data header used 12
`octets of space, meaning that 128 (140-12) octets are left for the user data itself.
`Related documents:
`[SMPP34] paragraph 5.2.12 / 5.2.19
`[GSM23040] paragraph 9.2.3.24
`
`2.4 Enhanced messaging service
`
`The Enhanced Messaging Service (EMS) is the important interim step on the path that
`mobile messaging follows to evolve from mobile plain text messaging to mobile multimedia
`messaging.
`EMS is based upon the standard SMS, but with formatting added to the text. The formatting
`may permit the message to contain objects like animations, pictures, melodies, formatted
`text, vCard and vCalendar. Objects may be mixed together into one message.
`The Enhanced Messaging is builds on two standard mechanisms of GSM SMS messaging:
`(cid:120)(cid:3) User data headers
`(cid:120)(cid:3) Message concatenation
`
`2.4.1 User data headers
`
`User data headers enable to include binary data in a normal