SMPP Sessions

Session Establishment

To initiate communication, an ESME must establish a session with the SMSC using a binding process. This process involves authentication and authorization to ensure that only legitimate ESMEs can connect to the SMSC. The ESME uses a bind request along with its system_id (username) and password to authenticate.
As we already know SMPP defines three types of binding modes for establishing sessions.
When a bind request is sent, the SMSC responds with a bind response to confirm whether the authentication was successful. Upon successful binding, a session is established, allowing the ESME to exchange PDUs with the SMSC.

SMPP Session States

An SMPP session can exist in one of the following states:

• OPEN: The initial state where the TCP/IP connection is established but no bind request has been issued yet.
• BOUND_TX: Indicates a Transmitter session has been successfully established, allowing the ESME to send messages only.
• BOUND_RX: Indicates a Receiver session has been successfully established, allowing the ESME to receive messages only.
• BOUND_TRX: Indicates a Transceiver session has been successfully established, allowing the ESME to both send and receive messages.
• CLOSED: The state after the session has been terminated using an unbind request or if the connection was lost unexpectedly.

An ESME that initiates a bind_transmitter request moves from OPEN -> BOUND_TX upon successful binding. After completing its operations, it returns to CLOSED state upon sending an unbind request and receiving unbind_resp from the SMSC.

Session Maintenance (enquire_link, Timers)

Once a session is established, it must be maintained to ensure a stable and active connection between the ESME and the SMSC. SMPP provides several features that help maintain session stability, prevent congestion, and ensure that the connection remains efficient and reliable:

• Enquire Link PDU: To prevent session timeouts due to inactivity, either the ESME or SMSC can periodically send an enquire_link PDU. This command acts as a heartbeat signal to confirm that the connection is still active. The receiving entity must respond with an enquire_link_resp PDU to acknowledge the link's status.
• Response Timers: SMPP requires that every request PDU sent by an ESME or SMSC must receive a corresponding response PDU within a specific time frame. If a response is not received within the defined timer period, the operation may be retried or the session may be terminated.
• Session Timeout: If no communication occurs between the ESME and SMSC for an extended period, the session may be terminated automatically by either party. Implementing regular enquire_link PDUs helps prevent unintentional timeouts.
• Throttling Control: Limits the rate at which PDUs can be sent from an ESME to an SMSC, often specified as a maximum number of messages per second. Throttling helps prevent overloading the SMSC and ensures fair resource allocation.
• Asynchronous Message Handling: SMPP supports the ability to send multiple PDUs without waiting for a response to each one, which helps to manage high traffic volumes efficiently. Proper handling of asynchronous responses prevents message congestion.
• Link Monitoring & Error Handling: Monitors error codes and response times to identify and respond to potential issues proactively. Effective error handling ensures that session disruptions are minimized.
• Enquire Link Interval Adjustment: Allows for adjusting the frequency of enquire_link PDUs based on traffic volume and network stability to prevent unnecessary overhead. Optimizing this interval helps balance network efficiency and session reliability.
• Delivery Receipt Handling: Ensures efficient management of delivery receipts (deliver_sm PDUs) to avoid session stalls caused by unacknowledged PDUs. Proper handling of delivery receipts ensures that message statuses are accurately tracked and that the session remains responsive.
• Bind and Unbind Timeout Management: Defines timeout settings for responses to bind and unbind requests to prevent orphaned sessions. Proper timeout management ensures that stuck sessions are closed gracefully.

Session Termination

To end an SMPP session gracefully, the ESME must send an unbind PDU to the SMSC, signaling its intention to terminate the connection. The termination process involves the following steps:

1. Sending an Unbind Request. The ESME initiates session termination by sending an unbind PDU to the SMSC.
2. Acknowledgment. Upon receiving the unbind PDU, the SMSC responds with an unbind_resp PDU to acknowledge the termination request.
3. Closing the Connection. After receiving the unbind_resp PDU, both the ESME and SMSC close the TCP/IP connection, formally ending the session.

• Unexpected Termination. If the TCP/IP connection is lost unexpectedly (e.g., due to a network failure), both sides must handle the re-establishment of the session using the appropriate binding process.

Outbind

There is an optional feature provided by the SMPP protocol called Outbind, which is used to support specific use cases such as:

• Proactive Message Delivery: When the SMSC has pending messages to deliver to an ESME that is not currently connected, it can use outbind to prompt the ESME to establish a connection and receive messages.
• Push-Based Communication: Suitable for systems where the SMSC pushes messages to ESMEs based on certain triggers, such as emergency alerts or high-priority notifications.
• Efficient Resource Management: Helps avoid keeping connections open unnecessarily when there is no traffic, which can be useful in resource-constrained environments.

The process works as follows:

1. Initiating Outbind:
   • The SMSC establishes a network connection with the ESME and sends an outbind request to prompt the ESME to connect.
2. Responding to Outbind:
   • Upon receiving the outbind request, the ESME should respond by initiating a bind_receiver request to the SMSC, including system_id and password for authentication.
3. Acknowledgment:
   • If the credentials are correct, the SMSC responds with a bind_receiver_resp PDU to confirm the session. If authentication fails, the ESME should disconnect the network connection immediately.
4. Session Characteristics:
   • Once the session is established, it functions as a normal receiver session with the ESME receiving inbound messages from the SMSC.