SMPP Protocol v34

5/23/2018 SMPP Protocol v34

1/169

Page 1 of 169 Issue 1.2

Short Message Peer to Peer

Protocol Specification v3.4

Document Version:- 12-Oct-1999 Issue 1.2


2/169

Page 2 of 169 SMPP Developers Forum Issue 1.2

SMPP Protocol Specification v3.4

Short Message Peer to Peer Protocol Specification v3.4

12-Oct-1999 Issue 1.2

1999 SMPP Developers Forum.

COPYRIGHT

All rights reserved. This document or any part thereof may not, without the prior written

consent of SMPP Developers 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, transmitting or storing in any medium or translating into any language, in any form

or by any means, including but not limited to, electronic, 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, SMPP DEVELOPERS FORUM DOES NOT

WARRANT THE ACCURACY OR SUITABILITY OF SAME FOR ANY SPECIFIC USE. SMPPDEVELOPERS FORUM EXPRESSLY DISCLAIMS ALL AND ANY LIABILITY TO ANY PERSON,

WHETHERA PURCHASEROROTHERWISE, INRESPECTOF ANYCONSEQUENCESOFANYTHING

DONEOROMITTEDTOBEDONEBYANYSUCHPERSONINPARTIALORTOTALRELIANCEUPON

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, SMPP DEVELOPERS FORUM ACCEPTS NO RESPONSIBILITY FOR ITS USE BY ANY

MEANSORINANYWAYWHATSOEVER. SMPP DEVELOPERSFORUMSHALLNOTBELIABLEFOR

ANYEXPENSES, COSTSORDAMAGETHATMAYRESULTFROMTHEUSEOFTHEINFORMATION

CONTAINEDHOWSOEVERARISINGINTHISDOCUMENTORANYDERIVATIVETHEREOF.

NOTE 1:THE INFORMATION CONTAINED IN THE WITHIN DOCUMENT AND ANY

DERIVATIVE THEREOF IS SUBJECT TO CHANGE WITHOUT NOTICE.

NOTE 2:THE CORPORATE NAME OF SMPP DEVELOPERS FORUM IS NORTHGROVE

LIMITED, COMPANY NUMBER 309113, REGISTERED OFFICE GARDNER HOUSE,

WILTON PLACE, DUBLIN 2.


3/169

SMPP Protocol Specification v3.4 Errata

Issue 1.2 SMPP Developers Forum Page 3 of 169

Errata

ErratumDescription of Correction to

address Erratum

ChangeRequest

Reference

In the SMPP Protocol Specificationv3.4. version 30-July-1999 Issue 1.1section 4.1.5 Bind_Transceiverthe interface_version fieldwasinadvertently not included in the

bind_transceiver PDU.

The erratum was corrected in theSMPP Protocol Specification v3.4version 12-Oct-1999 Issue 1.2 asfollows:

In section 4.1.5 Bind_Transceiverthe interface_version fieldwasadded as a mandatoryfield to the

bind_transceiver PDU.

Since it is a mandatory field allimplementations of the SMPPProtocol Specification v3.4 mustinclude the interface_version fieldwhen usingthebind_transceiverPDU.

SMPPV3.4-05Oct99-01


4/169


Table of Contents SMPP Protocol Specification v3.4

Table of Contents

1. Introduction .................................................................................................................81.1 SMPP Overview...............................................................................................8

1.2 Scope................................................................................................................9

1.3 Glossary .........................................................................................................10

1.4 References......................................................................................................11

2. SMPP Protocol Overview .........................................................................................12

2.1 SMPP Protocol Definition .............................................................................13

2.2 SMPP Session Description ............................................................................14

2.2.1 Outbind .........................................................................................16

2.3 SMPP PDUs...................................................................................................17

2.4 SMPP Network Layer Connections ...............................................................19

2.5 SMPP messages sent from ESME to SMSC..................................................202.5.1 SMPP Message Response from SMSC to ESME.........................20

2.5.2 Typical SMPP session sequence - ESME Transmitter .................21

2.6 SMPP messages sent from SMSC to ESME..................................................23

2.6.1 SMPP Message Response from ESME to SMSC.........................23

2.6.2 Typical SMPP session sequence - ESME Receiver......................24

2.7 Duplex message exchange between an SMSC and an ESME .......................26

2.7.1 Typical SMPP session sequence - ESME Transceiver .................27

2.8 SMPP Error Handling ....................................................................................29

2.9 SMPP Timers.................................................................................................29

2.10 Message Modes..............................................................................................30

2.10.1 Store and Forward Message Mode ...............................................30

2.10.2 Datagram Message Mode .............................................................32

2.10.3 Transaction Message Mode ..........................................................33

2.11 Message Types...............................................................................................34

3. SMPP PDU Type and Format Definitions ..............................................................36

3.1 SMPP PDU - Type Definitions...................................................................... 36

3.1.1 SMPP Parameter Field Size Notation ........................................... 37

3.2 SMPP PDU Format - Overview.....................................................................38

3.2.1 SMPP PDU Layout .......................................................................39

3.2.2 SMPP PDU Length .......................................................................41

3.2.3 SMPP Message length and extended message length...................41

3.2.4 Optional Parameters...................................................................... 423.2.4.1 Optional Parameter Format.....................................42

3.3 Guidelines for SMPP Forward Compatibility................................................43

3.4 Guidelines for SMPP Backward Compatibility .............................................44

4. SMPP PDU Definition ..............................................................................................45

4.1 BIND Operation .........................................................................................45

4.1.1 BIND_TRANSMITTER Syntax ...............................................46

4.1.2 BIND_TRANSMITTER_RESP Syntax....................................474.1.3 BIND_RECEIVER Syntax........................................................484.1.4 BIND_RECEIVER_RESP ........................................................50

4.1.5 BIND_TRANSCEIVER Syntax................................................51

4.1.6 BIND_TRANSCEIVER_RESP ................................................53


5/169

SMPP Protocol Specification v3.4 Table of Contents


4.1.7 OUTBIND Operation. ...............................................................54

4.1.7.1 OUTBIND Syntax..............................................544.2 UNBIND Operation....................................................................................55

4.2.1 UNBIND ...................................................................................56

4.2.2 UNBIND_RESP.......................................................................564.3 GENERIC_NACK PDU ............................................................................57

4.3.1 GENERIC_NACK Syntax ........................................................574.4 SUBMIT_SM Operation ............................................................................58

4.4.1 SUBMIT_SM Syntax................................................................59

4.4.1.1 Source and Destination Addressing .......................664.4.1.2 Message Replace operation in SUBMIT_SM.....66

4.4.2 SUBMIT_SM_RESP.................................................................67

4.5 SUBMIT_MULTI Operation .....................................................................684.5.1 SUBMIT_MULTI Syntax .........................................................69

4.5.1.1 Destination Address definition ...............................75

4.5.1.2 Distribution List (DL) definition ............................75

4.5.2 SUBMIT_MULTI_RESP Syntax..............................................764.5.2.1 Unsuccessful deliveries ..........................................77

4.6 DELIVER_SM Operation ..........................................................................784.6.1 DELIVER_SM Syntax..............................................................794.6.2 DELIVER_SM_RESP Syntax ..................................................85

4.7 DATA_SM Operation ................................................................................864.7.1 DATA_SM Syntax....................................................................874.7.2 DATA_SM_RESP Syntax ........................................................93

4.8 QUERY_SM Operation..............................................................................944.8.1 QUERY_SM Syntax .................................................................95

4.8.2 QUERY_SM_RESP Syntax......................................................96

4.9 CANCEL_SM Operation ...........................................................................974.9.1 CANCEL_SM Syntax ...............................................................984.9.2 CANCEL_SM_RESP Syntax..................................................100

4.10 REPLACE_SM Operation........................................................................101

4.10.1 REPLACE_SM Syntax ...........................................................1024.10.2 REPLACE_SM_RESP Syntax................................................104

4.11 ENQUIRE_LINK Operation....................................................................1054.11.1 ENQUIRE_LINK Syntax........................................................1064.11.2 ENQUIRE_LINK_RESP Syntax ............................................106

4.12 ALERT_NOTIFICATION Operation......................................................1074.12.1 ALERT_NOTIFICATION Syntax..........................................108

5. SMPP Parameter Definition...................................................................................1095.1 Command Header Parameters.....................................................................109

5.1.1 command_length.........................................................................109

5.1.2 command_id................................................................................1095.1.2.1 SMPP Command set .............................................110

5.1.3 command_status..........................................................................1125.1.4 sequence_number........................................................................115

5.2 Mandatory SMPP Parameters ......................................................................116

5.2.1 system_id ....................................................................................1165.2.2 password .....................................................................................1165.2.3 system_type.................................................................................116

5.2.4 interface_version.........................................................................116


6/169


Table of Contents SMPP Protocol Specification v3.4

5.2.5 addr_ton, source_addr_ton, dest_addr_ton, esme_addr_ton.......117

5.2.6 addr_npi, source_addr_npi, dest_addr_npi, esme_addr_npi.......118

5.2.7 address_range..............................................................................118

5.2.8 source_addr.................................................................................119

5.2.9 destination_addr..........................................................................1195.2.10 esme_addr ...................................................................................119

5.2.11 service_type ................................................................................120

5.2.12 esm_class ....................................................................................121

5.2.13 protocol_id ..................................................................................123

5.2.14 priority_flag ................................................................................123

5.2.15 schedule_delivery_time ..............................................................124

5.2.16 validity_period ............................................................................ 124

5.2.17 registered_delivery......................................................................124

5.2.18 replace_if_present_flag...............................................................125

5.2.19 data_coding .................................................................................126

5.2.20 sm_default_msg_id .....................................................................127

5.2.21 sm_length....................................................................................128

5.2.22 short_message .............................................................................128

5.2.23 message_id..................................................................................128

5.2.24 number_of_dests .........................................................................128

5.2.25 dest_flag......................................................................................129

5.2.26 no_unsuccess...............................................................................129

5.2.27 dl_name.......................................................................................129

5.2.28 message_state..............................................................................130

5.3 SMPP Optional Parameter Description........................................................131

5.3.1 Optional Parameter Tag Identifiers.............................................131

5.3.2 SMPP Optional Parameter Tag definitions.................................132

5.3.2.1 dest_addr_subunit.................................................1345.3.2.2 source_addr_subunit .............................................134

5.3.2.3 dest_network_type................................................135

5.3.2.4 source_network_type............................................135

5.3.2.5 dest_bearer_type...................................................136

5.3.2.6 source_bearer_type ...............................................136

5.3.2.7 dest_telematics_id.................................................137

5.3.2.8 source_telematics_id............................................. 137

5.3.2.9 qos_time_to_live...................................................138

5.3.2.10 payload_type.........................................................138

5.3.2.11 additional_status_info_text...................................139

5.3.2.12 receipted_message_id...........................................1395.3.2.13 ms_msg_wait_facilities ........................................ 140

5.3.2.14 privacy_indicator ..................................................141

5.3.2.15 source_subaddress ................................................142

5.3.2.16 dest_subaddress ....................................................143

5.3.2.17 user_message_reference .......................................143

5.3.2.18 user_response_code ..............................................144

5.3.2.19 language_indicator................................................144

5.3.2.20 source_port ........................................................... 145

5.3.2.21 destination_port ....................................................145

5.3.2.22 sar_msg_ref_num ................................................. 146

5.3.2.23 sar_total_segments................................................147

5.3.2.24 sar_segment_seqnum............................................147


7/169

SMPP Protocol Specification v3.4 Table of Contents


5.3.2.25 sc_interface_version .............................................148

5.3.2.26 display_time.......................................................... 148

5.3.2.27 ms_validity ........................................................... 149

5.3.2.28 dpf_result..............................................................149

5.3.2.29 set_dpf...................................................................1505.3.2.30 ms_availability_status...........................................151

5.3.2.31 network_error_code..............................................152

5.3.2.32 message_payload ..................................................153

5.3.2.33 delivery_failure_reason ........................................153

5.3.2.34 more_messages_to_send....................................... 154

5.3.2.35 message_state .......................................................154

5.3.2.36 callback_num........................................................155

5.3.2.37 callback_num_pres_ind........................................156

5.3.2.38 callback_num_atag ...............................................157

5.3.2.39 number_of_messages............................................158

5.3.2.40 sms_signal.............................................................158

5.3.2.41 alert_on_message_delivery...................................159

5.3.2.42 its_reply_type .......................................................159

5.3.2.43 its_session_info.....................................................160

5.3.2.44 ussd_service_op....................................................161

6. Network Implementation........................................................................................162

6.1 Network Error Codes ...................................................................................162

6.2 Maximum Message Length..........................................................................162

7. General Definitions .................................................................................................163

7.1 Time Definitions ..........................................................................................163

7.1.1 Time Format................................................................................163

7.1.1.1 Absolute Time format...........................................1637.1.1.2 Relative Time Format...........................................164

7.2 Timer Definitions.........................................................................................165

Appendix A ..........................................................................................................................166

Appendix B ..........................................................................................................................167

Appendix C ..........................................................................................................................169


8/169


Introduction SMPP Protocol Specification v3.4

1. Introduction

1.1 SMPP Overview

The Short Message Peer to Peer (SMPP) protocol is an open, industry standard protocol

designed to provide a flexible data communications interface for transfer of short message data

between a Message Center, such as a Short Message Service Centre (SMSC), GSM

Unstructured Supplementary Services Data (USSD) Server or other type of Message Center

and a SMS application system, such as a WAP Proxy Server, EMail Gateway or other

Messaging Gateway.

Note: For sake of brevity, the term SMSC will be used throughout this document to describe

any SMPP server entity to which an SMPP client, termed an External ShortMessage Entity (ESME), can be connected.

SMPP Release v3.4 supports Digital Cellular Network technologies including:-

GSM

IS-95 (CDMA)

ANSI-136 (TDMA)

iDEN

Using the SMPP protocol, an SMS application system called the External Short Message

Entity (ESME) may initiate an application layer connection with an SMSC over a TCP/IP orX.25 network connection and may then send short messages and receive short messages to and

from the SMSC respectively. The ESME may also query, cancel or replace short messagesusing SMPP.

SMPP supports a full featured set of two-way messaging functions such as:-

Transmit messages from an ESME to single or multiple destinations via the SMSC

An ESME may receive messages via the SMSC from other SMEs (e.g. mobile

stations).

Query the status of a short message stored on the SMSC

Cancel or replace a short message stored on the SMSC Send a registered short message (for which a delivery receipt will be returned by the

SMSC to the message originator)

Schedule the message delivery date and time

Select the message mode, i.e. datagram or store and forward

Set the delivery priority of the short message

Define the data coding type of the short message

Set the short message validity period

Associate a service type with each message e.g. voice mail notification


9/169

SMPP Protocol Specification v3.4 Introduction


1.2 Scope

This document defines Version 3.4 of the SMPP protocol and specifies the command and

response format to be used when implementing an SMPP v3.4 protocol interface.

It is intended for designers and implementers of an SMPP v3.4 interface between an SMSC and

an External Short Message Entity (ESME), as illustrated in the following diagram.

Figure 1-1: Context of SMPP in a Mobile Network

GSM

Telep SMS

Mobile

VMS

WAP

Paging

Bureau

ESMEs

MobileNetwork

SMSC

Station

SMPP

SMPP

SMPP

Proxy Server


10/169


Introduction SMPP Protocol Specification v3.4

1.3 Glossary

Note 1: In the context of this document ESME refers to such external sources and sinks of short

messages as Voice Processing Systems, WAP Proxy Servers or Message Handling

computers. It specifically excludes SMEs which are located within the Mobile

Network, i.e., a mobile station (MS).

ACK Acknowledgement

API Application Programming InterfaceCDR Call Detail Record

ESME External Short Message Entity. Refer to note[1]

ETSI European Telecommunications Standards Institute

HEADER Leading portion of the SMPP message, common to all SMPP PDUs

MB Message Bureau - This is typically an operator message bureau.

MSB Most Significant Byte

MSC Mobile Switching Centre

MS Mobile Station

MWI Message Waiting Indication

NACK Negative Acknowledgement

NSAP Network Service Access Point

PDU Protocol Data Unit

PSSD Process Unstructured Supplementary Services Data

PSSR Process Unstructured Supplementary Services Request

SME Short Message Entity

SMSC Short Message Service Centre

SMPP Short Message Peer to Peer Protocol

UDHI User Data Header Indicator

URL Uniform Resource Locator

USSN Unstructured Supplementary Services Notification

USSR Unstructured Supplementary Services Request

VMA VoiceMail Alert

VPS Voice Processing System

TIA Telecommunications Industry Association

WAP Wireless Application Protocol (http://www.wapforum.org)

WCMP Wireless Control Message Protocol

WDP Wireless Datagram Protocol


11/169

SMPP Protocol Specification v3.4 Introduction


1.4 References

Ref. Document Title Document NumberVersion

Number

[GSM 03.40] Technical Realisation of the Short

Message Service Point to Point

GSM 03.40

http://www.etsi.fr

v5.7.1

[GSM 03.38] Digital Cellular telecommunica-

tions system (Phase 2+); Alphabets

and language specific information.

[GSM 03.38]

http://www.etsi.fr

v5.5.1

Sept. 97

[GSM MAP

09.02]

GSM Mobile Application Part [GSM MAP 09.02]

http://www.etsi.fr

v5.11.0

[IS637] Short Message Service for Spread

Spectrum Systems

TIA/EIA/IS-637-A Rev A

[TSAR] Teleservice Segmentation and Reas-

sembly (TSAR)

TIA/EIA-136-620 Rev 0

[CMT-136] Short Message Service - Cellular

Messaging Teleservice

TIA/EIA-136-710-A Rev A

[GUTS] General UDP Transport Service

(GUTS)

TIA/EIA-136-750 Rev 0

[WAPARCH] Wireless Application ProtocolArchitecture Specification WAP Forumhttp://www.wapforum.org Version30-Apr.-

1998

[WCMP] Wireless Control Message Protocol

Specification

WAP Forum

http://www.wapforum.org

Version

12-June-

1998

[WDP] Wireless Datagram Protocol Specifi-

cation

WAP Forum

http://www.wapforum.org

Version

10-Feb.-

1999

[ITUT X.213] Open Systems Interconnection - Net-work Service Definition

[ITUT X.213] 11/95

[KOR ITS] PCS operators common standards for

handset-SMS functionalities

PCS standardization com-

mittee

PCS-SMS-97-05-28

1.06 Rev

99-04-30


12/169


SMPP Protocol Overview SMPP Protocol Specification v3.4

2. SMPP Protocol Overview

Short Message Peer to Peer (SMPP) protocol is an open message-transfer protocol that enablesshort message entities (SMEs) outside the mobile network to interface with an SMSC. Non-

mobile entities that submit messages to, or receive messages from an SMSC are known as

External Short Message Entities (ESMEs).

The SMPP protocol defines:

a set of operations for the exchange of short messages between an ESME and an SMSC

the data that an ESME application must exchange with an SMSC during SMPP operations.

Subscribers to an SMS-capable Cellular Network may receive short messages on a Mobile

Station (MS) from one or more ESMEs. The means whereby these messages arrive at the ESMEvia an interface other than SMPP is beyond the scope of this document. However, examples ofsuch ESME applications include:-

Voicemail alerts originating from a VPS (Voice Processing System), indicating voice

messages at a customers mailbox.

Numeric and alphanumeric paging services

Information services. For example, an application that enables mobile subscribers to query

currency rates or share-price information from a database or the WWW and have itdisplayed as a short message on the handsets.

Calls directly dialled or diverted to a message-bureau operator, who forwards the messageto the SMSC, for onward delivery to a subscribers handset.

A fleet management application that enables a central station to use the SMSC to

determine the location of its service vehicles and notify the closest vehicle of a service

request in their area.

Telemetry applications. For example, a house-hold meter that transmits a short message toa utility companys billing system to automatically record customer usage.

WAP Proxy Server. A WAP Proxy Server acts as the WAP gateway for wireless internet

applications. A WAP Proxy Server may select an SMS or USSD bearer for sending WDPdatagrams to and receiving WDP datagrams from a mobile station.


13/169

SMPP Protocol Specification v3.4 SMPP Protocol Overview


2.1 SMPP Protocol Definition

SMPP is based on the exchange of request and response protocol data units (PDUs) between

the ESME and the SMSC over an underlying TCP/IP or X.25 network connection. The SMPP

protocol defines:

a set of operations and associated Protocol Data Units (PDUs) for the exchange of shortmessages between an ESME and an SMSC

the data that an ESME application can exchange with an SMSC during SMPP operations.

Note* Every SMPP operation must consist of a request PDU and associated response PDU.

The receiving entity must return the associated SMPP response to an SMPP PDUrequest.

* The only exception to this rule is

- thealert_notificationPDU for which there is no response

The exchange of messages between an ESME and SMSC via SMPP may be categorised under

three distinct groups of transactions as follows:

i) messages sent from the ESME (Transmitter) to the SMSC

ii) messages sent from the SMSC to the ESME (Receiver)

iii) messages sent from the ESME (Transceiver) to the SMSC and messages sent from the

SMSC to the ESME (Transceiver)

The following Figure 2-1 illustrates the above categories, which are explained in more detail in

subsequent sections.

Figure 2-1: SMPP interface between SMSC and ESME

SMPP Transmitter

SMPP messages sent from ESME to SMSC

SMPP Receiver

SMPP messages sent from SMSC to ESME

ESME-001 (e.g. WAP Proxy/Server)

SMSC

ESME-002 (e.g. VPS)

ESME-003 (e.g. Email Gateway)

SMPP I/F

N

e

t

w

o

r

k

SMPP

SMPP

SMPP

Transceiver

Transmitter

ReceiverSMPP Transceiver

SMPP messages sent from ESME to SMSC

SMPP messages sent from SMSC to ESME


14/169



2.2 SMPP Session Description

An SMPP session between an SMSC and an ESME is initiated by the ESME first establishing

a network connection with the SMSC and then issuing an SMPP Bind request to open an SMPP

session. An ESME wishing to submit and receive messages is required to establish two networkconnections (TCP/IP or X.25) and two SMPP sessions (Transmitter and Receiver).

Alternatively, in this version of the protocol an ESME may establish an SMPP Transceiver

session over a single network connection.

During an SMPP session, an ESME may issue a series of requests to an SMSC and shall receive

the appropriate responses to each request, from the SMSC. Likewise, the SMSC may issue

SMPP requests to the ESME, which must respond accordingly.

The SMPP session may be defined in terms of the following possible states:

OPEN(Connected and Bind Pending)An ESME has established a network connection to the SMSC but has not yet issued a

Bind request.

BOUND_TXA connected ESME has requested to bind as an ESME Transmitter (by issuing a

bind_transmitter PDU) and has received a response from the SMSC authorising its

bind request.

An ESME bound as a transmitter may send short messages to an SMSC for onward

delivery to a Mobile Station or to another ESME. The ESME may also replace, queryor cancel a previously submitted short message.

BOUND_RXA connected ESME has requested to bind as an ESME Receiver (by issuing a

bind_receiverPDU) and has received a response from the SMSC authorising its Bind

request.

An ESME bound as a receiver may receive short messages from an SMSC which may

be originated by a mobile station, by another ESME or by the SMSC itself (for example

an SMSC delivery receipt).

BOUND_TRXA connected ESME has requested to bind as an ESME Transceiver (by issuing a

bind_transceiver PDU) and has received a response from the SMSC authorising its

Bind request. An ESME bound as a Transceiver supports the complete set of operations

supported by a Transmitter ESME and a Receiver ESME.

Thus an ESME bound as a transceiver may send short messages to an SMSC for onward

delivery to a Mobile Station or to another ESME. The ESME may also receive short

messages from an SMSC which may be originated by a mobile station, by another

ESME or by the SMSC itself (for example an SMSC delivery receipt).


15/169



CLOSED (Unbound and Disconnected)An ESME has unbound from the SMSC and has closed the network connection. The

SMSC may also unbind from the ESME.


16/169



2.2.1 Outbind

The purpose of the outbind operation is to allow the SMSC signal an ESME to originate a

bind_receiver request to the SMSC. An example of where such a facility might be applicable

would be where the SMSC had outstanding messages for delivery to the ESME.

An outbind SMPP session between an SMSC and an ESME can be initiated by the SMSC first

establishing a network connection with the ESME.

Once a network connection has been established, the SMSC should bind to the ESME by

issuing an outbind request. The ESME should respond with a bind_receiver request to

which the SMSC will reply with a bind_receiver_resp.

If the ESME does not accept the outbind session (e.g. because of an illegal system_id orpasswordetc.) the ESME should disconnect the network connection.

Once the SMPP session is established the characteristics of the session are that of a normal

SMPP receiver session.

Figure 2-2: Sample Outbind Sequence

ESME SMSC

bind_receiver_resp

outbind

bind_receiver

deliver_sm

deliver_sm_resp


17/169



2.3 SMPP PDUs

The following table lists the SMPP PDU set and the context in which each PDU may be used:

SMPP PDU NameRequired SMPP

Session State

Issued by

ESME

Issued by

SMSC

bind_transmitter OPEN Yes No

bind_transmitter_resp OPEN No Yes

bind_receiver OPEN Yes No

bind_receiver_resp OPEN No Yes

bind_transceiver OPEN Yes No

bind_transceiver_resp OPEN No Yes

outbind OPEN No Yes

unbind BOUND_TXBOUND_RXBOUND_TRX

YesYesYes

YesYesYes

unbind_resp BOUND_TXBOUND_RXBOUND_TRX

YesYesYes

YesYesYes

submit_sm BOUND_TXBOUND_TRX

YesYes

NoNo

submit_sm_resp BOUND_TX

BOUND_TRX

No

No

Yes

Yes

submit_sm_multi BOUND_TXBOUND_TRX

YesYes

NoNo

submit_sm_multi_resp BOUND_TXBOUND_TRX

NoNo

YesYes

data_sm BOUND_TXBOUND_RXBOUND_TRX

YesYesYes

YesYesYes

data_sm_resp BOUND_TXBOUND_RXBOUND_TRX

YesYesYes

YesYesYes

deliver_sm BOUND_RXBOUND_TRX

NoNo

YesYes

deliver_sm_resp BOUND_RXBOUND_TRX

YesYes

NoNo

query_sm BOUND_TXBOUND_TRX

YesYes

NoNo

query_sm_resp BOUND_TXBOUND_TRX

NoNo

YesYes

Table 2-1: SMPP PDU Summary List


18/169



cancel_sm BOUND_TX

BOUND_TRX

Yes

Yes

No

No

cancel_sm_resp BOUND_TXBOUND_TRX

NoNo

YesYes

replace_sm BOUND_TX Yes No

replace_sm_resp BOUND_TX No Yes

enquire_link BOUND_TXBOUND_RXBOUND_TRX

YesYesYes

YesYesYes

enquire_link_resp BOUND_TXBOUND_RX

BOUND_TRX

YesYes

Yes

YesYes

Yes

alert_notification BOUND_RXBOUND_TRX

NoNo

YesYes

generic_nack BOUND_TXBOUND_RXBOUND_TRX

YesYesYes

YesYesYes

SMPP PDU NameRequired SMPP

Session State

Issued by

ESME

Issued by

SMSC

Table 2-1: SMPP PDU Summary List


19/169



2.4 SMPP Network Layer Connections

The underlying transport interface between the SMSC and ESME may be based on a TCP/IP

or X.25 network connection.

SMPP is an application layer protocol and is not intended to offer transport functionality. It is

therefore assumed that the underlying network connection will provide reliable data transfer

from point to point including packet encoding, windowing, flow control and error handling.

Thus, at the SMPP level, the ESME and SMSC should treat the network connection as a reliable

transport which manages delivery and receipt of SMPP PDUs.

The following diagram illustrates a generic SMPP interface implementation between an ESME

and SMSC.

Figure 2-3: Model of SMPP SMSC-ESME Interface

If required, it is expected that the network layer at the sending entity will handle the

segmentation of the SMPP PDUs for transmission as a series of fragmented packets over the

network connection. Likewise, the network layer of the receiving entity, shall re-assemble a

fragmented SMPP PDU before passing the entire SMPP PDU to the SMPP layer.

SMSCESME

N/WLayer

N/WLayer

SMPP Encoding/Decoding by ESME/SMSC

Packet encoding,

Fragmentation,

windowing & Error

Handling of N/W Layer

TCP/IP orX.25

TCP/IP or X.25

SMPP SMPP

InterfaceSMPPSMPP

Interface


20/169



2.5 SMPP messages sent from ESME to SMSC

An ESME which sends short messages to an SMSC must be connected to the SMSC as an

ESME Transmitter or an ESME Transceiver.

Examples of SMPP message Protocol Data Units (PDUs) which may be sent from an ESME

transmitter to the SMSC include:

submit_sm

data_sm

In addition to submission of messages to the SMSC, an ESME may perform the following

SMPP operations using the message identifier returned by the SMSC in the message

acknowledgement:

query_sm - Query the SMSC for the status of a previously submitted message

cancel_sm - Cancel delivery of a previously submitted message

replace_sm - Replace a previously submitted message

SMPP PDUs sent to the SMSC by an ESME must, when received, be acknowledged with aPDU response by the SMSC.

Refer to Table 2-1for details on the SMPP operations which may be sent from an ESME to the

SMSC.

2.5.1 SMPP Message Response from SMSC to ESME

The SMPP PDU response for a message submission to the SMSC will include a messageidentifier (which must be a unique handle assigned to that particular message) and a statuswhich informs the ESME whether the submitted message is valid (i.e. accepted by the SMSC

for onward delivery) or invalid. In the latter case, the SMSC will return an appropriate errorstatus.

submit_sm_resp

data_sm_resp

query_sm_resp

cancel_sm_resp

replace_sm_resp


21/169



2.5.2 Typical SMPP session sequence - ESME Transmitter

The following diagram illustrates a typical SMPP request/response sequence between an SMSC

and an ESME bound as a Transmitter.

Figure 2-4: Typical SMPP request/response sequence for an ESME Transmitter

The exchange of SMPP request and response PDUs between an ESME Transmitter and

SMSC may occur synchronously or asynchronously as shown above. Thus an ESME may,if desired, send multiple requests to the SMSC, without synchronously waiting for the

associated response PDUs.

A series of successive SMPP requests issued asynchronously by an ESME (as denoted bythe number in parentheses in Figure 2-4 above) must be followed shortly after by a series

of associated responses from the SMSC.

SMPP responses should be returned by the SMSC in the same order in which the originalrequests were received from the ESME. However this is not mandatory within SMPP and

the ESME should be capable of handling responses received out of sequence.

ESME SMSC

submit_sm(2)

submit_sm_resp(2)

submit_sm_resp(3)

query_sm(5)

submit_sm(6)

query_sm_resp(5)

submit_sm_resp(6)

bind_transmitter(1)

bind_transmitter_resp(1)

submit_sm(3)

submit_sm(4)

submit_sm_resp(4)

unbind(7)

unbind_resp(7)


22/169



The ESME should return SMPP responses to the SMSC in the same order in which the

original requests were received. The only relevant PDU response that an ESMETransmitter returns in a transmitter session is an enquire_link_resp.

Note: The maximum number of outstanding (i.e. unacknowledged) SMPP operations

between an ESME and SMSC and vice versa is not specified explicitly in the SMPPProtocol Specification and will be governed by the SMPP implementation on the

SMSC.

However, as a guideline it is recommended that no more than 10 (ten) SMPP messages

are outstanding at any time.


23/169



2.6 SMPP messages sent from SMSC to ESME

The SMSC may deliver short messages to an ESME. In this case the ESME must be connected

to the SMSC as an ESME Receiver or as an ESME Transceiver.

Typical applications in which an ESME would operate as an SMPP Receiver include:-

an e-mail gateway accepting messages originated by mobile stations for onward deliveryto internet e-mail boxes.

The SMSC may also send a delivery receipt to the ESME which contains a returneddelivery status of a previously submitted short message.

Examples of SMPP message Protocol Data Units (PDUs) which may be sent from an SMSC to

an ESME receiver include:

deliver_sm

data_sm

SMPP PDUs delivered to an ESME by the SMSC must be acknowledged with a SMPP PDU

response by the ESME when received*.

* Exceptions to this rule are:

- thealert_notificationPDU.

Refer to Table 2-1 for details on the SMPP operations which may be sent from an SMSC to an

ESME.

2.6.1 SMPP Message Response from ESME to SMSC

The SMPP PDU response from an ESME Receiver must preserve the PDU transaction

identifier (contained in the sequence_numberparameter) sent by the SMSC. The response must

also include the command status which informs the SMSC whether the message delivered to

the ESME was valid (i.e. accepted by the ESME) or invalid. In the latter case, the ESME should

return an appropriate SMPP error status.

Examples of SMPP message responses which may be sent from an ESME receiver to the SMSC

include:

deliver_sm_resp

data_sm_resp


24/169



2.6.2 Typical SMPP session sequence - ESME Receiver


and an ESME bound as a Receiver.

Figure 2-5: Typical SMPP request/response sequence for an ESME Receiver

The exchange of SMPP request and response PDUs between an SMSC and ESMEReceiver may be implemented synchronously or asynchronously as shown above. Thus

the SMSC may send multiple deliver_smrequests to the ESME, without synchronouslywaiting for the associated response PDUs.

A series of successive SMPP requests issued asynchronously by an SMSC (as denoted by

the number in parentheses) must be followed shortly after by a series of associatedresponses from the ESME.

The ESME should always return SMPP responses to the SMSC in the same order in which

the original requests were received. However this is not mandatory within SMPP and theSMSC should be capable of handling responses received out of sequence.

ESME SMSC

deliver_sm(1)

deliver_sm(2)

deliver_sm_resp(1)

deliver_sm_resp(2)

deliver_sm(3)

deliver_sm(4)

deliver_sm_resp(3)

deliver_sm_resp(4)

bind_receiver(1)

bind_receiver_resp(1)

unbind(2)

unbind_resp(2)


25/169



SMPP responses should be returned by the SMSC in the same order in which the original

requests were received from the ESME. However this is not mandatory within SMPP andthe ESME should be capable of handling responses received out of sequence.



SMSC.

However, as a guideline it is recommended that no more than 10 (ten) SMPP messages

are outstanding at any time.


26/169



2.7 Duplex message exchange between an SMSC and anESME

The SMSC and ESME may operate a duplex messaging session, i.e. messages are exchanged

in both directions. In this case the ESME must be connected to the SMSC as an ESME

Transceiver.

Typical applications in which an ESME would operate as an SMPP Transceiver include:-

Two-way message exchange between a mobile station and an ESME, e.g a WAP Proxy/Server. The mobile subscriber initiates an information request to the WAP Proxy Server

and the information response is returned via the SMSC to the mobile station.

Examples of SMPP message Protocol Data Units (PDUs) which may be sent on an SMPPTransceiver session include:

data_sm

submit_sm

deliver_sm

In addition to submission of messages to the SMSC, an ESME may perform the following

SMPP operations using the message identifier returned by the SMSC in the message

acknowledgement:

query_sm - Query the SMSC for the status of a previously submitted message

cancel_sm - Cancel delivery of a previously submitted message

replace_sm - Replace a previously submitted message

SMPP PDUs delivered to an ESME by the SMSC (or vice versa) must be acknowledged witha PDU response when received*.

* Exceptions to this rule are:

- thealert_notificationPDU.

Refer to Table 2-1 for details on the SMPP operations which may be sent on an SMPPTransceiver session.


27/169



2.7.1 Typical SMPP session sequence - ESME Transceiver


and an ESME bound as a Transceiver.

Figure 2-6: Typical SMPP request/response sequence for an ESME Transceiver

The exchange of SMPP request and response PDUs between an SMSC and ESME

Transceiver may be implemented synchronously or asynchronously as shown above. Thus

the SMSC may send multiple data_sm requests to the ESME, without synchronouslywaiting for the associated response PDUs.

A series of successive SMPP requests issued asynchronously by an SMSC (as denoted by

the number in parentheses) must be followed shortly after by a series of associatedresponses from the ESME. The sequence_number parameter in the SMPP header is used

to correlate the SMPP response PDU with the SMPP request PDU.

ESME SMSC

data_sm(1)

data_sm (3)

data_sm_resp (1)

data_sm_resp(3)

data_sm(2)

data_sm(3)

data_sm_resp(2)

data_sm_resp (3)

bind_transceiver (1)

bind_transceiver_resp(1)

unbind(4)

unbind_resp(4)

data_sm(2)

data_sm_resp (2)


28/169



The ESME should always return SMPP PDU responses to the SMSC in the same order in

which the original requests were received. However this is not mandatory within SMPPand the SMSC should be capable of handling responses received out of sequence

SMPP responses should be returned by the SMSC in the same order in which the original

requests were received from the ESME. However this is not mandatory within SMPP andthe ESME should be capable of handling responses received out of sequence.



SMSC.

However, as a guideline it is recommended that no more than 10 (ten) SMPP messagesare outstanding at any time.


29/169



2.8 SMPP Error Handling

All SMPP operations consist of a request PDU and associated response PDU, with the

exception of thealert_notificationPDU (for which there is no SMPP response).

In all other cases, the receiving entity must return the associated SMPP response PDU to an

SMPP request PDU, indicating that the original PDU has been received at the destination. Until

such a response is received by the originator, it must be assumed that the PDU has not been

received at the destination.

In the event that the original SMPP request PDU is found to contain an error, the receiving

entity must return a response with an appropriate error code inserted in the command_status

field of the response PDU header (Ref.Section 3.2, SMPP PDU Format - Overview).

If the receiving entity finds an error in the PDU header, it should return ageneric_nakPDU to

the originator (Ref. Section 4.3, GENERIC_NACK PDU).

2.9 SMPP Timers

To ensure the efficient exchange of SMPP transactions, it is recommended that each SMPP

session be managed using configurable timers on both the ESME and SMSC communicatingSMPP entities as follows:-

An SMPP session initiation timer to ensure that when an ESME initiates an SMPP session,that this occurs within a specified period after opening a network connection to the SMSC.

An SMPP session timer to enable either the ESME or SMSC request the SMPP session

status of the other communicating SMPP entity via the enquire_linkcommand.

An SMPP inactivity timer which should specify the maximum period after which time, ifno SMPP messages are exchanged, the SMPP session may be dropped gracefully.

An SMPP transaction timer which specifies the time lapse allowed between an SMPPrequest and the corresponding SMPP response.

Further details on implementation of SMPP timers are included inSection 7.2, TimerDefinitions .


30/169



2.10 Message Modes

SMPP offers a Message Mode option which, if supported on the SMSC, allows an ESME to

select the SMSC message delivery mechanism. The typical delivery mechanisms that may be

offered by an SMSC are:-

Store and Forward

Datagram

Transaction mode

These Message Modes are described in more detail in the following sections.

2.10.1 Store and Forward Message Mode

The conventional approach to SMS has been to store the message in a SMSC storage area (e.g.message database) before forwarding the message for delivery to the recipient SME. With this

model, the message remains securely stored until all delivery attempts have been made by the

SMSC. This mode of messaging is commonly referred to as store and forward.

SMPP supports the store and forward delivery mechanism via the submit_sm operation,

which enables the ESME to send a message to the SMSC where it is stored until it is

successfully delivered or until the message validity period expires. The store and forward modeis also supported via thedata_smoperation.

The store and forward message mode also facilitates subsequent SMPP operations on the

stored short message such as query_sm,replace_smandcancel_sm. Thesubmit_smPDU alsofacilitates replace-if-present functionality which requires that the original message be stored

on the SMSC.

Note: To determine the eventual outcome of the SMS delivery, the ESME must request anSMSC Delivery Receipt in thesubmit_smordata_smoperation.

The following diagram shows the message flow for a store and forward message where theESME is bound both as a Transmitter and as a Receiver. The ESME has requested an SMSCDelivery Receipt.


31/169



Figure 2-7: Typical SMPP sequence for a registered store and forward message

ESME SMSC

bind_transmitter

bind_transmitter_resp

MS

Network Delivery Attempt

NACK


ACK


deliver_sm_resp

submit_sm(registered_delivery

submit_sm_resp

bind_receiver

bind_receiver_resp

= SMSC Delivery Receipt)

deliver_sm (esm_class= SMSC Delivery Receipt)

deliver_sm_resp

deliver_sm (esm_class= SMSC Delivery Receipt)

submit_sm(registered_delivery

submit_sm_resp

= SMSC Delivery Receipt)

Wireless Network ProtocolSMPP

ACK


32/169



2.10.2 Datagram Message Mode

The Datagram Message Mode emulates the datagram paradigm used in other data

communication protocols such as UDP datagram packet transfer and focuses on high message

throughput without the associated secure storage and retry guarantees of Store and ForwardMessage Mode. In Datagram Message Mode the message originator (i.e. the ESME) does not

receive any form of delivery acknowledgement.

In Datagram Message Mode, typical SMSC functions such as scheduled delivery, registered

delivery etc. do not apply. Datagram Message Mode is designed for high throughput

applications that may not require the highly secure delivery functionality offered by the Store

and Forward message mode. It is ideally suited for applications where the data content is

transient in nature, for example, vehicle tracking applications.

SMPP supports datagram mode via thedata_smoperation. The esm_classparameter is used to

select Datagram Message Mode. Refer to section 5.2.12, esm_class for details on the

esm_class parameter.

The datagram mode is also supported in thesubmit_smoperation to provide easy evolution forexisting SMPP applications.

Figure 2-8: Typical SMPP sequence for message delivery in Datagram message mode

ESME SMSC

data_sm (esm_class = datagram)

bind_transceiver

bind_transceiver_resp

MS


ACK

Wireless Network ProtocolSMPP

data_sm_resp


33/169



2.10.3 Transaction Message Mode

Transaction Message Mode allows the ESME message originator to receive a form of delivery

acknowledgment (that indicates if the message has been successfully or unsuccessfully

delivered to the destination MS) within the SMPP response PDU.

Transaction Message Mode is designed for applications that involve real-time messaging where

an ESME requires a synchronous end-to-end delivery outcome, without the need for long term

SMSC storage. Such applications could include for example multicast of dispatch information

to vehicle fleets, etc.

SMPP supports Transaction Message Mode via the data_sm operation only. The esm_class

parameter is used to select Transaction Message Mode. Refer to section 5.2.12, for details on

the esm_class parameter.

Note: The fundamental difference between the Datagram and Transaction Message Modes is

that in Transaction Message Mode, the ESME receives adata_sm_resp indicating the

end-to-end delivery outcome. In Datagram Message Mode, the response PDU just

indicates that the message has been accepted by the SMSC over the SMPP connection.

Figure 2-9: Typical SMPP sequence for message delivery in Transaction message mode

ESME SMSC

data_sm(esm_class = forward)

bind_transmitter

bind_transmitter_resp

MS


ACK

data_sm_resp

Wireless Data ProtocolSMPP


34/169



2.11 Message Types

In addition to normal short messages, special messages can be transferred between ESMEand the SMSC in asubmit_sm, deliver_sm or adata_sm operation. The message type is defined

in the esm_classparameter of the above SMPP operations.

The following message types are supported in SMPP:

SMSC Delivery Recei

pt

This message type is used to carry an SMSC delivery receipt. The SMSC, on detecting the finalstate of a registered message stored in the SMSC, should generate a receipt message addressed

to the originator of the message. The SMSC Delivery Receipt is carried as the user data payloadin the SMPPdeliver_sm ordata_sm operation.

The following fields are relevant in thedeliver_sm

and data_sm

operations when used fortransmitting delivery receipts.

source address (i.e. source_addr_ton, source_addr_npi, source_addr)

The source address will be taken from the destination address of the original short messagewhich generated the delivery receipt.

destination address (i.e. dest_addr_ton, dest_addr_npi, destination_addr)

The destination address will be taken from the source address of the original short messagewhich generated the delivery receipt.

esm_class

message_state

network_error_code

receipted_message_id

Intermediate Notification

An intermediate notification is a special form of message that the SMSC may send to an ESME

for a mobile terminated message delivery. It provides an intermediate status of a message

delivery attempt.

Typical uses are

to provide a memory capacity exceeded notification to a Voice Mail System.

to report the outcome of the first delivery attempt that has failed but the message is still

held in the SMSC for further delivery attempts.

Support for Intermediate Notification functionality is specific to the SMSC implementation andthe SMSC Service Provider and is beyond the scope of this specification.

SME Delivery Acknowledgement

Despite its name, an SME Delivery Acknowledgement is not an indication that the shortmessage has arrived at the SME, but rather an indication from the recipient SME that the user

has read the short message.


35/169



For an MS-based SME, an SME Delivery Acknowledgement is sent when the MS user or MS

application has read the message from the SMS storage unit (e.g. SIM card).

For a fixed SME (i.e. ESME) the circumstances in which an SME Delivery Acknowledgement

may be sent are beyond the scope of this specification.

Note: The SME Delivery Acknowledgement function may not be supported on all network

types.

SME Manual/User Acknowledgement

A Manual/User Acknowledgement is an application generated reply message sent in response

to an application request message. For example, this message type could contain a selected

menu item number from a menu list sent in an application request message.

Note: The Manual/User Acknowledgement function may not be supported on all network

types.

Conversation Abort

This message type is unique to Interactive Teleservice defined by the Korean CDMA carriers

organization. It is sent by a MS-based SME to indicate the unexpected termination of an

interactive session. A Conversation Abort may be carried in adeliver_smordata_sm PDU.

Note: The Conversation Abort function is not supported on all network types.


36/169


SMPP PDU Type and Format Definitions SMPP Protocol Specification v3.4

3. SMPP PDU Type and Format Definitions

3.1 SMPP PDU - Type Definitions

The following SMPP PDU data type definitions are used to define the SMPP parameters:

Notes: (i) Reference made to NULL settings of Octet-String fields implies that the field

consists of a single NULL character, i.e., an octet encoded with value 0x00 (zero).

(ii) Where reference is made to NULL settings of Integer fields, this implies that the

field is zero filled.

(iii) In the case of all C-Octet String formats, the maximum field size is shown as a

combination of string length and the NULL terminator, i.e., an 8-character C-Octet

String is encoded in 9 octets when the NULL terminator is included.

Integer An unsigned value with the defined number of octets.

The octets will always be transmitted MSB first (Big Endian).

C-Octet String A series of ASCII characters terminated with the NULL character.

C-Octet String

(Decimal)

A series of ASCII characters, each character representing a

decimal digit (0 - 9) and terminated with the NULL character.

C-Octet String

(Hex)

A series of ASCII characters, each character representing a

hexadecimal digit (0 - F) and terminated with the NULL character.

Octet String A series of octets, not necessarily NULL terminated.


37/169

SMPP Protocol Specification v3.4 SMPP PDU Type and Format Definitions


3.1.1 SMPP Parameter Field Size Notation

The following notation style is used throughout. Note that some SMPP strings are optional and

others mandatory.

Size octets Type Description of String type specified

4 Integer Fixed size integer field. In this example the integer is of size 32

bits (4 octets)

Var

Max 16

C-Octet

String

This string is of variable length from 1-15 ASCII characters,

followed by an octet containing the NULL terminator.

An empty string is encoded as a single octet containing the

NULL character (0x00).

Fixed

1 or 17

C-Octet

String

This string has two possible lengths:-

1 octet containing the NULL character or

a fixed number of characters terminated with the NULL

character (in this example 16 characters plus the NULL

character).

Var

0 - 254

Octet

String

Variable size octet string field. In this example the size of the

octet string field can vary from 0 to 254 octets.

Table 3-1: C-Octet String Notation


38/169



3.2 SMPP PDU Format - Overview

The general format of an SMPP PDU consists of a PDU header followed by a PDU body as

outlined in the following table.

The SMPP Header is a mandatory part of every SMPP PDU and must always be present. The

SMPP PDU Body is optional and may not be included with every SMPP PDU.

The format of each SMPP PDU is described in more detail in the following section 4. "SMPP

PDU Definition".

SMPP PDU

PDU Header (mandatory) PDU Body (Optional)

command

length

command

id

command

status

sequence

number

PDU Body

4 octets Length = (Command Length value - 4) octets

Table 3-2: SMPP PDU Format Overview


39/169



3.2.1 SMPP PDU Layout

H

E

A

D

ER

SMPP PDU FieldSize

octetsType Description

command_length 4 Integer Thecommand_lengthfield defines the total

octet length of the SMPP PDU packet

including the length field.

command_id 4 Integer The command_idfield identifies the particular

SMPP PDU, e.g.,submit_sm, query_sm,etc.

A unique command identifier is allocated to

each SMPP request PDU in the range:

0x00000000 to 0x000001FF

A unique command identifier is also allocated

to each SMPP response PDU in the range:0x80000000 to 0x800001FF

(Note that an SMPP response command_idis

identical to the corresponding request SMPP

command_id, but with bit 31 set).

Refer to chapter 5.for details of the complete

SMPP Command IDset.

command_status 4 Integer The command_statusfield indicates the

success or failure of an SMPP request.

It is relevant only in the SMPP response PDU

and it must contain a NULL value in an SMPP

request PDU.

The complete list of SMPP Error codes is

defined in Chapter 5.

sequence_number 4 Integer This field contains a sequence number which

allows SMPP requests and responses to be

associated for correlation purposes. The use of

sequence numbers for message correlation

allows SMPP PDUs to be exchanged

asynchronously.

Assignment of the sequence_numberis the

responsibility of the SMPP PDU originator.

The sequence_numbershould be increased

monotonically for each submitted SMPP

request PDU and must be preserved in the

associated SMPP response PDU.

The sequence_number may range from:

0x00000001 to 0x7FFFFFFF.

Table 3-3: SMPP PDU Format Description


40/169



Note: Some SMPP PDUs may only have a Header part only, for example, the enquire_link

PDU.

B

O

D

Y

Mandatory

Parameters

var. mixed A list of mandatory parameters corresponding

to that SMPP PDU defined in thecommand_id

field.

The complete list of mandatory parameters isdetailed in section 4. "SMPP PDU Definition"

with the description of each SMPP PDU.

Optional

Parameters

var. mixed A list of Optional Parameters corresponding to

that SMPP PDU defined in thecommand_id

field and included as required.

The complete list of optional parameters is

detailed in section 4. "SMPP PDU

Definition"with the description of each SMPP

PDU.

Table 3-3: SMPP PDU Format Description


41/169



3.2.2 SMPP PDU Length

The command_length field at the beginning of the SMPP PDU header, indicates the total

number of octets contained in that SMPP PDU. The command_lengthfield contains a 4-octet

integer transmitted in Big Endian format.

To decode an SMPP PDU, the ESME or SMSC should first read the command_lengthfield (4

octets) to determine the PDU length. The amount of remaining data is then determined by

subtracting the length of the command_length field (4 octets) from this total PDU length as

provided by the command_lengthfield value. Thus, extracting a command length of value N,

indicates that N-4 octets are remaining for the given PDU.

Example:-

The following data-stream example illustrates how the SMPP PDU header isencoded:

00 00 00 2F 00 00 00 02 00 00 00 00 00 00 00 01 53 4D 50 50 33 54 45 53 54 00

73 65 63 72 65 74 30 38 00 53 55 42 4D 49 54 31 00 00 01 01 00

Note: Values are shown in Hex format.

The header would be decoded as follows:

00 00 00 2F Command Length 0x0000002F

00 00 00 02 Command ID 0x00000002 (bind_transmitter)

00 00 00 00 Command Status 0x00000000

00 00 00 01 Sequence Number 0x00000001

The remaining data represents the PDU body (which in this example relates to the

bind_transmitterPDU).

3.2.3 SMPP Message length and extended message length

The length of the short message text (or user data) is defined in the sm_length field of the

submit_sm, submit_multi,deliver_smandreplace_sm SMPP PDUs.

The maximum message length which can be specified in sm_lengthfield (see section 5.2.21) is

254 octets. If an ESME wishes to submit a message of length greater than 254 octets, the

sm_length field must be set to NULL and the message_payloadoptional parameter must be

populated with the message length value and user data.

SMPP supports extended message lengths in the submit_sm, submit_multi, data_sm and

deliver_sm PDUs.

Refer to section 3.2.4 "Optional Parameters"for detail on Optional Parameters.

Note: The actual short message length which can be transmitted to a MS may vary according

to the underlying network.


42/169



3.2.4 Optional Parameters

Optional Parameters are fields, which may be present in a message. Optional Parameters

provide a mechanism for the future introduction of new parameters, as and when defined in

future versions of the SMPP protocol.

Optional Parameters must always appear at the end of a PDU , in the "Optional Parameters"

section of the SMPP PDU. However, they may be included in any convenient order within the

"Optional Parameters" section of the SMPP PDU and need not be encoded in the order

presented in this document.

For a particular SMPP PDU, the ESME or SMSC may include some, all or none of the defined

optional parameters as required for the particular application context. For example a paging

system may only need to include the callback number related optional parameters in asubmit_smoperation.

3.2.4.1 Optional Parameter Format

All optional parameters have the following general TLV (Tag, Length, Value) format. The

definition of the Tag, Length and Value for each optional parameter is defined in chapter5.

Parameter Name Size Type Description

Tag 2 Integer The Tagfield is used to uniquely identifythe particular optional parameter in

question.

The optional parameter Tagfield isalways 2 octets in length.

Length 2 Integer TheLengthfield indicates the length of

the Valuefield in octets.Note that this length does not include thelength of the TagandLengthfields.

The optional parameterLengthfield is

always 2 octets in length.

Value variable variable TheValuefield contains the actual datafor the optional parameter in question.

Table 3-4: Optional Parameter Format


43/169



3.3 Guidelines for SMPP Forward Compatibility

Forward Compatibility procedures allow a functional entity (i.e. SMSC or ESME) using one

version of the SMPP protocol to easily communicate with an entity using a later, more enhanced

version of the protocol. Hence, new enhancements to existing SMPP PDUs are implementedusing optional parameters.

The following guidelines must be followed in SMPP implementations to ensure that this

process is implemented successfully and consistently:

If an SMPP entity receives an unrecognized PDU/command, it must return ageneric_nackPDU indicating an invalid command_idin the command_statusfield of the

header.

The SMPP entity receiving a message which includes Optional Parameters shall firstinspect the Tagfield of the Operational Parameter, as follows:

- If the Optional Parameter Tagis recognized and supported by the receiving SMPPentity for the particular SMPP operation, the Optional Parameter shall be processed.

- If an Optional Parameter Tag is recognized but not expected for the particular SMPP

operation, the optional parameter shall be ignored.

- If the Optional Parameter Tag is unrecognized or unsupported by the receiving SMPP

entity, that particular Optional Parameter shall be ignored and the next Optional

Parameter in the sequence shall be processed.

An SMPP entity receiving a parameter value defined as reserved should use the default

value if a default setting is defined, otherwise the parameter should be ignored.

If the Parameter value is otherwise unrecognized or invalid, the SMPP entity should return

an error indicating the Parameter Value is invalid.

An SMPP entity detecting that an Optional Parameter, which is required in the context of

the operation, is not present should return a response message with an Expected Optional

Parameter missing error.

A Variable length field Parameter may have its maximum length definition extended in

subsequent versions of the SMPP protocol. An SMPP entity receiving a variable lengthParameter whose length is greater than the maximum length the entity supports for thatParameter should reject the Parameter with an error indicating invalid parameter length.


44/169



3.4 Guidelines for SMPP Backward Compatibility

Backward Compatibility procedures allow a functional entity using one version of the SMPP

protocol to communicate with an entity using an older version of the protocol.

The following guidelines must be followed in SMPP implementations to ensure that this

process is implemented successfully and consistently:

Existing SMPP PDUs must not be removed from the protocol.

The effect of receiving any existing message in a new modified format must be same asthat in previous versions. Thus the addition of new parameters or parameter values ispurely additive.

Optional parameters shall not become mandatory parameters.

Mandatory parameters shall not become optional parameters.

Additional mandatory parameters shall not be added to an existing SMPP PDU.

Existing mandatory parameters shall not be removed from an existing SMPP PDU.

The meaning of any existing parameter value shall not be changed in the new version ofthe protocol.

As the concept of Optional Parameters was introduced in this version of the protocol, thefollowing special guidelines are defined:

An SMSC that implements SMPP v3.4 or a later version of this protocol must not sendoptional parameters to an ESME that implements an earlier SMPP version (e.g. v3.3). AnSMSC shall determine the SMPP version supported by an ESME during the bind

operation. An ESME supporting SMPP v3.3 or earlier will set the interface_versionparameter in the bind operation to a value less than 0x34.

An SMSC supporting v3.4 or later should return the SMPP version it supports in the

sc_interface_versionparameter of the bind response PDU. If a bind response does not

contain the sc_interface_version parameter, then the ESME should assume that the SMSCdoes not support the use of optional parameters.

An ESME that implements SMPP v3.4 or a later version of this protocol must not send

optional parameters to an SMSC that implements an earlier version of this protocol. TheESME shall determine the SMSC version support from the SMPP bind response PDU.

An SMSC that implements SMPP v3.4 or later must not generate message IDs greater than8 octets when communicating with an ESME that supports SMPP v3.3 or earlier.


45/169

SMPP Protocol Specification v3.4 SMPP PDU Definition


4. SMPP PDU Definition

4.1 BIND Operation

The purpose of the SMPP bind operation is to register an instance of an ESME with the SMSC

system and request an SMPP session over this network connection for the submission or

delivery of messages. Thus, the Bind operation may be viewed as a form of SMSC login request

to authenticate the ESME entity wishing to establish a connection.

As described previously, an ESME may bind to the SMSC as either a Transmitter (called ESME

Transmitter), a Receiver (called ESME Receiver) or a Transceiver (called ESME Transceiver).

There are three SMPP bind PDUs to support the various modes of operation, namely

bind_transmitter,bind_transceiverandbind_receiver. The command_idfield setting specifies

which PDU is being used.

An ESME may bind as both an SMPP Transmitter and Receiver using separate

bind_transmitterandbind_receiveroperations (having first established two separate network

connections). Alternatively an ESME can also bind as a Transceiver having first established a

single network connection.

If an SMSC does not support thebind_transmitter and bind_receiveroperations then it should

return a response message with an Invalid Command ID error and the ESME should

reattempt to bind using thebind_transceiver operation. Similarly if an SMSC does not supportthe bind_transceiver command then it should return a response message with an InvalidCommand ID error and the ESME should reattempt to bind using the bind_transmitteror

bind_receiver operations or both bind_transmitter and bind_receiver operations as

appropriate.

ESME Transmitter

An ESME bound as a Transmitter is authorised to send short messages to the SMSC and to

receive the corresponding SMPP responses from the SMSC.

An ESME indicates its desire not to receive (mobile) originated messages from other SMEs(e.g. mobile stations) by binding as a Transmitter.

Refer to section 2.3for a summary list of the SMPP PDUs available to an ESME Transmitter.

ESME Receiver

An ESME bound as a Receiver is authorised to receive short messages from the SMSC and toreturn the corresponding SMPP message responses to the SMSC.

Refer to section 2.3for a summary list of the SMPP PDUs available to an ESME Receiver.

ESME Transceiver

An ESME bound as a Transceiver is allowed to send messages to the SMSC and receivemessages from the SMSC over a single SMPP session.

Refer to section 2.3for a summary list of the SMPP PDUs available to an ESME Transceiver.


46/169


SMPP PDU Definition SMPP Protocol Specification v3.4

4.1.1 BIND_TRANSMITTER Syntax

The format of the SMPPbind_transmitter PDU is defined in the following table.

H

E

A

D

E

R

Field Name Sizeoctets

Type Description Ref.

command_length 4 Integer Defines the overall length of the

bind_transmitter PDU.

5.1.1

command_id 4 Integer Value corresponding to

bind_transmitter request.

5.1.2

command_status 4 Integer Not used inbind_transmitter PDU.

Must be set to NULL.

5.1.3

sequence_numbera

a. There is no specific requirement on how the sequence_number should be set. However, it is recommended

that the sequence number be a monotonically increasing number.

4 Integer Set to a unique sequence number.

The associatedbind_transmitter_respPDU will echo the same sequence

number.

5.1.4

B

O

D

Y

system_idb

b. The recommended use of system_idis to identify the binding entity, e.g., InternetGW in the case of an

Internet Gateway or VMS for a Voice Mail System.

Var.

max

16

C-

Octet

String

Identifies the ESME system

requesting to bind as a transmitter

with the SMSC.

5.2.1

passwordc

c. Thepasswordis used for authentication to secure SMSC access. The ESME may set the password to NULL

to gain insecure access (if allowed by SMSC administration).

Var.

max

9

C-

Octet

String

The password may be used by the

SMSC to authenticate the ESME

requesting to bind.

5.2.2

system_typed

d. The system_type(optional) may be used to categorise the system, e.g., EMAIL, WWW, etc.

Var.

13

C-

Octet

String

Identifies the type of ESME system

requesting to bind as a transmitter

with the SMSC.

5.2.3

interface_version 1 Integer Indicates the version of the SMPP

protocol supported by the ESME.

5.2.4

addr_ton 1 Integer Indicates Type of Number of the

ESME address.

If not known set to NULL

5.2.5

addr_npi 1 Integer Numbering Plan Indicator for ESME

address.

If not known set to NULL.

5.2.6

address_range Var.

max

41

C-

Octet

String

The ESME address.

If not known set to NULL.

5.2.7

Table 4-1: SMPPbind_transmitterPDU


47/169

SMPP Protocol Specification v3.4 SMPP PDU Definition


4.1.2 BIND_TRANSMITTER_RESP Syntax

The SMPP bind_transmitter_respPDU is used to reply to a bind_transmitter request. The

format of the SMPPbind_transmitter_respPDU is defined in the following table.

Note: The body portion of the SMPP bind_transmitter_resp PDU is not returned if the

command_statusfield contains a non-zero value; i.e., if there is an error in the original

bind_transmitterrequest, the SMSC system_idis not returned.

H

E

A

D

E

R

Field NameSize

octetsType Description Ref.

command_length 4 Integer Defines the overall length of the

bind_transmitter_respPDU.

5.1.1


bind_transmitter_resp.

5.1.2

command_status 4 Integer Indicates status (success or error

code) of originalbind_transmitterrequest.

5.1.3

sequence_number 4 Integer Set to sequence number of original

bind_transmitter request.

5.1.4

B

O

D

Y

system_id Var.

max

16

C-

Octet

String

SMSC identifier.

Identifies the SMSC to the ESME.

5.2.1

OPTIONAL PARAMETERS for BIND_TRANSMITTER_RESP

sc_interface_version TLV SMPP version supported by SMSC 5.3.2.25

Table 4-2: bind_transmitter_respPDU


48/169


SMPP PDU Definition SMPP Protocol Specification v3.4

4.1.3 BIND_RECEIVER Syntax

The format of the SMPPbind_receiver PDU is defined in the following table.

H

E

A

D

E

R

Field Name Sizeoctets

Type Description Ref.

command_length 4 Integer Defines the overall length of the PDU

in octets.

5.1.1


bind_receiverrequest.

5.1.2

command_status 4 Integer Not used inbind_receiver PDU.

Set toNULL.

5.1.3

sequence_numbera 4 Integer Set to a unique sequence number.

The associatedbind_receiver_respPDU will echo the same sequence

number.

5.1.4

B

O

D

Y

system_idb Var.

max

16

C-

Octet

String

Identifies the ESME system

requesting to bind as a receiver with

the SMSC.

5.2.1

passwordc Var.

max

9

C-

Octet

String

The password may be used by the

SMSC for security reasons to

authenticate the ESME requesting to

bind.

5.2.2

system_typed Var.

max

13

C-

Octet

String

Identifies the type of ESME system

requesting to bind as a receiver with

the SMSC.

5.2.3

interface_version 1 Integer Identifies the version of the SMPP

protocol supported by the ESME.

5.2.4

addr_tone 1 Integer Type of Number (TON) for ESME

address(es) served via this SMPP

receiver session.

Set to NULL if not known.

5.2.5

addr_npie 1 Integer Numbering Plan Indicator (NPI) forESME address(es) s

Documents

SMPP Protocol v34