Short Message Peer to Peer (SMPP) Protocol

SMPP provides a flexible data communication interface to transfer short message data between a Message Center such as Short Message Service Centre (SMSC) and a SMS application system. SMPP is based on the exchange of request and response Protocol Data Units (PDUs) between External Short Message Entity (ESME) and the SMSC over an underlying TCP/IP or X.25 network connection.

SMPP Session States

1. OPEN
   Here the ESME has established a network connection to the SMSC, but has not sent the bind request yet.
2. BOUND_TX
   After connecting the ESME has requested to bind by sending the bind transmitter request. And also it has received a response from the SMSC authorizing the bind request.
3. BOUND_RX
   After connecting the ESME has requested to bind as a receiver by sending a bind receiver request and also has received a response from the SMSC authorizing the bind request.
4. BOUND_TRX
   ESME has requested to bind by sending a bind transceiver request as an ESME Transceiver. Also the ESME has received a response from the SMSC authorizing the bind request. An ESME Transceiver supports almost all the operations supported by a Transmitter ESME and a Receiver ESME.
5. CLOSED
   ESME has unbound from the SMSC and has closed the network connection. SMSC may also unbind from the ESME.

Outbind
Outbind operation is needed to allow the SMSC signal an ESME to generate a bind receiver request to the SMSC. This may be useful when the SMSC has outstanding messages to deliver to the ESME. When a network connection is established the SMSC should send the outbind request to the ESME. Then the ESME should respond with a bind_receiver request where the SMSC would respond with the bind_receiver_resp. ESME should disconnect the network connection if it does not accept the outbind session.

SMPP messages sent from ESME to SMSC

ESME that sends short messages to the SMSC should be connected as a transmitter or a transceiver. submit_sm and data_sm are examples of SMPP message PDUs which belong to this category. In addition to the submission of messages, SMPP performs operations such as query_sm, cancel_sm and replace_sm.
SMPP message response from SMSC to ESME
SMSC sends responses to the ESME informing whether the sent messages are valid or not. Some examples for SMPP responses are submit_sm_resp, data_sm_resp, query_sm_resp, cancel_sm_resp and replace_sm_resp.

SMPP Message Response from SMSC to ESME

Here the ESME should be connected as a receiver or a transceiver. The examples of SMPP message PDUs which may be sent from SMSC to ESME are deliver_sm and data_sm. In applications like email gateway accepting messages generated by mobile stations for delivery to emails, the ESME operates as the receiver. Also in sending the delivery receipt to the ESME by the SMSC returning the delivery status of messages, the ESME operates as the receiver.
SMPP message response from ESME to SMSC
Examples of message responses from ESME to SMSC are deliver_sm_resp and data_sm_resp. These responses are send to preserve the PDU transaction identifier and also to check whether the delivered messages to ESME are valid.

SMPP messages exchanged in both directions

Here the ESME should be connected as a transceiver. In applications such as two-way messages exchange between a mobile station and an ESME, the ESME operates as the transceiver. The examples of SMPP transceiver session PDUs are data_sm, submit_sm and deliver_sm. In addition to the message submission, SMPP performs operations such as query_sm, cancel_sm and replace_sm. SMPP response PDUs are sent to the ESME (or SMSC) by the SMSC (ESME) when the messages are received.

SMPP Error Handling

Every SMPP operation consists of a request PDU and the corresponding response PDU with the exception of the alert_notification PDU for which there is no SMPP response. In all the other situations the receiving entity should return the relevant response PDU for the request. It is assumed that the PDU is not received at the destination until the response is received by the originator. If the original SMPP request PDU is found with an error the receiver should send a response with the relevant error code included in the command_status field of the response PDU header. If an error is found in the PDU header, the receiver should send a generic_nak PDU to the originator.

Message Modes

A message mode option which allows an ESME to select the mechanism for SMSC message delivery is offered by SMPP if supported on SMSC. The
select the SMSC message delivery mechanism. The typical message modes are:-
• Store and Forward
• Datagram
• Transaction mode

Store and Forward Message Mode

Here the approach of storing the messages in a SMSC storage area before forwarding for delivery to the recipients is used. So the messages are stored securely until all the attempts of delivery are made. SMPP supports store and forward mechanism via the submit_sm operation that allows the ESME to send messages to the SMSC by storing them until they are successfully delivered or until the message validity period ends. The submit_sm facilitates ‘replace-if-present’ functionality that needs the original message to be stored on the SMSC. This message mode is also supported by the data_sm operation. Also supports operations such as query_sm, replace_sm and cancel_sm on the stored short messages.

Datagram Message Mode

In this message mode any delivery information is not sent to the message originator. Also the typical SMSC functions such as scheduled delivery, registered delivery are not applied. This message mode is basically designed for high throughput applications where the high secured delivery functionality is not needed. SMPP supports datagram mode via the data_sm operation. In selecting datagram message mode, the esm_class parameter is used. This message mode is also supported in submit_sm operation in order to provide easy evolution for existing SMPP applications.

Transaction Message Mode

This message mode allows the ESME originator to receive delivery acknowledgement within the SMPP response PDU. This mode is designed for applications with real-time messaging where ESME needs synchronous end-to-end delivery outcome. Only the data_sm operation is supported for the transaction message mode. The esm_class parameter is used to select the transaction message mode. The transaction message mode differs from the datagram message mode as here the ESME receives data_sm_resp indicating the end-to-end delivery outcome where in datagram mode the response PDU just indicates that the message is authorized.

Message Types

Special messages can be transferred between the ESME and the SMSC in addition to normal short messages in operations submit_sm, deliver_sm or a data_sm where the message type is defined in the esm_class parameter of these operations.

SMSC Delivery Receipt

This type is used to carry a SMSC delivery receipt. A receipt message should be generated addressing the originator by the SMSC on detecting the final state of a registered message stored in the SMSC. This delivery receipt is carried as the user data payload in deliver_sm or data_sm operation. The following fields are used in deliver_sm and data_sm operations when they are used to transmit delivery receipt.
•source address
The source address would be taken from the destination address of the original message that generated the delivery receipt.
•destination address
This would be extracted from the source address of the original message.
which generated the delivery receipt.
• esm_class
• message_state
• network_error_code
• receipted_message_id

Intermediate Notification

This is a special type of message that the SMSC may send to ESME for a mobile terminated message delivery which can provide the intermediate status of a message delivery attempt. This type is useful for applications such as providing memory capacity exceeded notifications to a Voice Mail System and reporting the outcome of the first delivery attempt that has failed but the message is still in the SMSC for further delivery attempts.

SME Delivery Acknowledgement

This is an indication from the recipient SME that the user has read the message. In a MS-based SME, SME delivery acknowledgement is sent when the MS user/application has read the message from the SMS storage unit such as the SIM card. This messaging function may not be supported on all network types.

SME Manual/User Acknowledgement

This type of messages are application generated reply messages sent as the response to an application request message. This function also may not be supported on all network types.

Conversation Abort

This type of messages are sent by a MS-based SME to indicate unexpected termination of an interactive session. These messges may be carried in a deliver_sm or data_sm PDU. This type is unique to Interactive Teleservice defined by the Korean CDMA carriers organization.