Short Message Peer to Peer Protocol Specification v3.4


NOTE (1): ActiveXperts SMS Component provides developers with a fast and reliable SMPP API. Simply connect to the SMPP provider, bind using your credentials and call SubmitSms to send out the messages. Read more »

NOTE (2): ActiveXperts SMS Messaging Server is an SMS messaging framework to allow sending, receiving and processing SMS messages. It is designed to implement any project that requires SMS messaging. Read more »


Table of Content


2. SMPP Protocol Overview


2.1 SMPP Overview

Short Message Peer to Peer (SMPP) protocol is an open message-transfer protocol that enables short message entities (SMEs) outside the mobile network to interface with an SMSC. Nonmobile entities that submit messages to, or receive messages from an SMSC are known as External Short Message Entities (ESMEs).

The SMPP protocol defines:

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 ESME via an interface other than SMPP is beyond the scope of this document. However, examples of such ESME applications include:


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:

The exchange of messages between an ESME and SMSC via SMPP may be categorised under three distinct groups of transactions as follows:

  1. messages sent from the ESME (Transmitter) to the SMSC
  2. messages sent from the SMSC to the ESME (Receiver)
  3. 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.


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 network connections (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_TX

A 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, query or cancel a previously submitted short message.

BOUND_RX

A connected ESME has requested to bind as an ESME Receiver (by issuing a bind_receiver PDU) 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_TRX

A 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).

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.

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 voutbind" 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 or password etc.) 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.


2.3 SMPP PDUs

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

SMPP PDU Name Required SMPP
Session State
Issued by
ESME
Issued by
SMSC
SMPP PDU Name: bind_transmitter Required SMPP Session State: OPEN Issued by ESME: Yes Issued by SMSC: No
SMPP PDU Name: bind_transmitter_resp Required SMPP Session State: OPEN Issued by ESME: No Issued by SMSC: Yes
SMPP PDU Name: bind_receiver Required SMPP Session State: OPEN Issued by ESME: Yes Issued by SMSC: No
SMPP PDU Name: bind_receiver_resp Required SMPP Session State: OPEN Issued by ESME: No Issued by SMSC: Yes
SMPP PDU Name: bind_transceiver Required SMPP Session State: OPEN Issued by ESME: Yes Issued by SMSC: No
SMPP PDU Name: bind_transceiver_resp Required SMPP Session State: OPEN Issued by ESME: No Issued by SMSC: Yes
SMPP PDU Name: outbind Required SMPP Session State: OPEN Issued by ESME: No Issued by SMSC: Yes
SMPP PDU Name: unbind Required SMPP Session State: BOUND_TX
BOUND_RX
BOUND_TRX
Issued by ESME: Yes
Yes
Yes
Issued by SMSC: Yes
Yes
Yes
SMPP PDU Name: unbind_resp Required SMPP Session State: BOUND_TX
BOUND_RX
BOUND_TRX
Issued by ESME: Yes
Yes
Yes
Issued by SMSC: Yes
Yes
Yes
SMPP PDU Name: submit_sm Required SMPP Session State: BOUND_TX
BOUND_TRX
Issued by ESME: Yes
Yes
Issued by SMSC: No
No
SMPP PDU Name: submit_sm_resp Required SMPP Session State: BOUND_TX
BOUND_TRX
Issued by ESME: No
No
Issued by SMSC: Yes
Yes
SMPP PDU Name: submit_sm_multi Required SMPP Session State: BOUND_TX
BOUND_TRX
Issued by ESME: Yes
Yes
Issued by SMSC: No
No
SMPP PDU Name: submit_sm_multi_resp Required SMPP Session State: BOUND_TX
BOUND_TRX
Issued by ESME: No
No
Issued by SMSC: Yes
Yes
SMPP PDU Name: data_sm Required SMPP Session State: BOUND_TX
BOUND_RX
BOUND_TRX
Issued by ESME: Yes
Yes
Yes
Issued by SMSC: Yes
Yes
Yes
SMPP PDU Name: data_sm_resp Required SMPP Session State: BOUND_TX
BOUND_RX
BOUND_TRX
Issued by ESME: Yes
Yes
Yes
Issued by SMSC: Yes
Yes
Yes
SMPP PDU Name: deliver_sm Required SMPP Session State: BOUND_RX
BOUND_TRX
Issued by ESME: No
No
Issued by SMSC: Yes
Yes
SMPP PDU Name: deliver_sm_resp Required SMPP Session State: BOUND_RX
BOUND_TRX
Issued by ESME: Yes
Yes
Issued by SMSC: No
No
SMPP PDU Name: query_sm Required SMPP Session State: BOUND_RX
BOUND_TRX
Issued by ESME: Yes
Yes
Issued by SMSC: No
No
SMPP PDU Name: query_sm_resp Required SMPP Session State: BOUND_TX
BOUND_TRX
Issued by ESME: No
No
Issued by SMSC: Yes
Yes
SMPP PDU Name: cancel_sm Required SMPP Session State: BOUND_TX
BOUND_TRX
Issued by ESME: Yes
Yes
Issued by SMSC: No
No
SMPP PDU Name: cancel_sm_resp Required SMPP Session State: BOUND_TX
BOUND_TRX
Issued by ESME: No
No
Issued by SMSC: Yes
Yes
SMPP PDU Name: replace_sm Required SMPP Session State: BOUND_TX Issued by ESME: Yes Issued by SMSC: No
SMPP PDU Name: replace_sm_resp Required SMPP Session State: BOUND_TX Issued by ESME: No Issued by SMSC: Yes
SMPP PDU Name: enquire_link Required SMPP Session State: BOUND_TX
BOUND_RX
BOUND_TRX
Issued by ESME: Yes
Yes
Yes
Issued by SMSC: Yes
Yes
Yes
SMPP PDU Name: enquire_link_resp Required SMPP Session State: BOUND_TX
BOUND_RX
BOUND_TRX
Issued by ESME: Yes
Yes
Yes
Issued by SMSC: Yes
Yes
Yes
SMPP PDU Name: alert_notification Required SMPP Session State: BOUND_RX
BOUND_TRX
Issued by ESME: No
No
Issued by SMSC: Yes
Yes
SMPP PDU Name: generic_nack Required SMPP Session State: BOUND_TX
BOUND_RX
BOUND_TRX
Issued by ESME: Yes
Yes
Yes
Issued by SMSC: Yes
Yes
Yes
Table 2-1: SMPP PDU Summary List

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.

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.


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:

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:

SMPP PDUs sent to the SMSC by an ESME must, when received, be acknowledged with a PDU response by the SMSC. Refer to Table 2-1 for 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 message identifier (which must be a unique handle assigned to that particular message) and a status which 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 error status.

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


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:

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

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:

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_number parameter) 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:

2.6.2 Typical SMPP session sequence - ESME Receiver

The following diagram illustrates a typical SMPP request/response sequence between an SMSC and an ESME bound as a Receiver.

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

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 and the ESME should be capable of handling responses received out of sequence.


2.7 Duplex message exchange between an SMSC and an ESME

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:

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

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:

SMPP PDUs delivered to an ESME by the SMSC (or vice versa) must be acknowledged with a PDU response when received. Exceptions to this rule are:

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

2.7.1 Typical SMPP session sequence - ESME Transceiver

The following diagram illustrates a typical SMPP request/response sequence between an SMSC and an ESME bound as a Transceiver.

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


2.8 SMPP Error Handling

All SMPP operations consist of a request PDU and associated response PDU, with the exception of the alert_notification PDU (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 a generic_nak PDU 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 communicating SMPP entities as follows:

Further details on implementation of SMPP timers are included in Section 7.2, "Timer Definitions".


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:

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 mode is also supported via the data_sm operation.

The "store and forward" message mode also facilitates subsequent SMPP operations on the stored short message such as query_sm, replace_sm and cancel_sm. The submit_sm PDU also facilitates "replace-if-present" functionality which requires that the original message be stored on the SMSC.

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

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

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 Forward Message 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 the data_sm operation. The esm_class parameter 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 the submit_sm operation to provide easy evolution for existing SMPP applications.

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

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.

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


2.11 Message Types

In addition to "normal" short messages, special messages can be transferred between ESME and the SMSC in a submit_sm, deliver_sm or a data_sm operation. The message type is defined in the esm_class parameter of the above SMPP operations. The following message types are supported in SMPP:

SMSC Delivery Receipt

This message type is used to carry an SMSC delivery receipt. The SMSC, on detecting the final state 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 payload in the SMPP deliver_sm or data_sm operation.

The following fields are relevant in the deliver_sm and data_sm operations when used for transmitting delivery receipts.

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

Support for Intermediate Notification functionality is specific to the SMSC implementation and the 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 short message has arrived at the SME, but rather an indication from the recipient SME that the user has read the short message.

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.

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.

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 a deliver_sm or data_sm PDU.