Message Exchange & PDUs

In SMPP, Protocol Data Units (PDUs) are the fundamental communication packets used to exchange information between an ESME and an SMSC. PDUs carry commands, responses, and message data to facilitate the sending, receiving, and managing of SMS messages.

PDU Structure

Each PDU in SMPP consists of two main parts: a mandatory header and an optional body.
PDU Header is a fixed-size structure of 16 octets that contains the following four mandatory parameters:

• Command Length: Specifies the total length of the PDU (header + body) in octets. Ensures that the receiving entity can correctly interpret the end of the PDU.
• Command ID: Identifies the type of operation being requested or responded to, such as submit_sm, deliver_sm, enquire_link, etc.
• Command Status: Indicates the success or failure of an SMPP operation. For request PDUs, this field is set to 0 (ESME_ROK). For response PDUs, it can contain error codes if the request failed.
• Sequence Number: Ensures that PDUs can be tracked and matched between requests and responses. Each request must have a unique sequence number that is echoed in the response PDU.

PDU Body is optional and may contain:

• Mandatory Parameters: Fixed fields that are required for the specific PDU type (e.g., source address, destination address, short message).
• Optional Parameters (TLVs): Flexible Tag-Length-Value (TLV) fields that allow for additional information (e.g., message validity, callback number). TLVs provide enhanced capabilities without altering the core PDU structure.

PDU Types and Their Functions

SMPP defines several types of PDUs for different functions, but the following are the most commonly used:

submit_sm
Used by the ESME to submit SMS messages to the SMSC for delivery to mobile devices.
Fields:
    Source Address: Identifies the sender.
    Destination Address: Identifies the recipient.
    Short Message: Contains the text or binary data to be delivered.
Optional Parameters:
    Validity period, delivery receipts, etc.

deliver_sm
Used by the SMSC to deliver SMS messages to the ESME or to send delivery receipts.
Fields:
    Message ID: Unique identifier for tracking.
    Delivery Receipt: Indicates if the message was delivered, expired, or failed.
    Short Message: Contains the original message or receipt status.

enquire_link
Acts as a heartbeat mechanism to confirm that the connection between the ESME and SMSC is active.
Fields: Contains only a header without a body. Requires a response (enquire_link_resp) to maintain session integrity.

bind_transmitter, bind_receiver, bind_transceiver
Establishes different types of sessions for sending, receiving, or two-way messaging.
Fields:
    System ID: Authentication credential.
    Password: Ensures that only authorized ESMEs can connect.

unbind
Gracefully terminates the SMPP session between the ESME and SMSC.
Fields: Only a header is required for this PDU.

Types of SMPP Operations

SMPP operations are categorized based on their purpose and the type of session. Some operations are specific to ESMEs, others to the Message Center (MC), and some depend on the session type.
Operations are broadly categorized into the following groups:

• Session Management. Designed to enable the establishment of SMPP sessions between an ESME and MC and provide means of handling unexpected errors (bind_transmitter, bind_receiver, bind_transceiver, unbind, enquire_link).
• Message Submission. Explicitly designed for the submission of messages from ESME(s) to the MC (submit_sm, submit_multi).
• Message Delivery. Enable an MC to deliver messages to the ESME (deliver_sm).
• Message Broadcast. Designed to provide Cell Broadcast service within a Message Centre (broadcast_sm (if supported)).
• Ancillary Operations. Provide enhanced features such as cancellation, query, or replacement of messages (query_sm, cancel_sm, replace_sm).

Message Fragmentation (Long Messages & Concatenation)

Since standard SMS is limited to 160 characters for 7-bit encoding (or 70 characters for Unicode), SMPP supports message fragmentation and concatenation to handle long messages.

Segmentation:
Long messages are split into multiple parts, each sent as a separate submit_sm PDU. There is a special header (User Data Header (UDH)) to indicate that a message part is part of a longer message.

Concatenation:
The receiving device reassembles the parts based on information in the UDH. Allows seamless display of long messages to the end-user.
Long messages have their own optional parameters:

• message_payload (TLV). Used to send long messages without segmentation by placing the entire message in a single PDU.
• sar_msg_ref_num (TLV). Provides a unique reference for all parts of a segmented message to ensure proper reassembly.