PDUs as Analogous to API Endpoints
Each PDU in SMPP serves a role similar to a REST API endpoint. As we mentioned before, SMPP uses binary PDUs to make operations.
A PDU consists of two main parts:
SMPP Header. The SMPP header is a fixed 16-byte structure present in every SMPP message. Contains metadata for processing the PDU. Fields include command length, command ID, command status, and sequence number.
SMPP Body (Optional, Depends on PDU Type). Some PDUs require a body, while others (like unbind) do not. PDUs like submit_sm include destination address, source address, and message content.
Optional fields (TLVs - Tag-Length-Value) allow for additional parameters like validity period, DLR requests, etc.
Each SMPP PDU follows this general structure:
| SMPP PDU | ||||
| PDU Header (Mandatory) | PDU Body (Optional) | |||
| Command length | Command id | Command status | Sequence number | PDU Body |
Let's have a more detailed look at this construction:
Command Length
Defines the total size of the PDU (including the header and body).
If the PDU contains additional fields, this number increases accordingly.
Command ID
Identifies the type of SMPP PDU. Each request and response PDU has a unique command identifier.
Request Range: 0x00000000 to 0x000001FF (e.g., submit_sm = 0x00000004)
Response Range: 0x80000000 to 0x800001FF (e.g., submit_sm_resp = 0x80000004)
The complete set of SMPP Command IDs and their associated values:
| Command ID | Command Name | Description |
| g0x80000000 | generic_nack | Generic negative acknowledgment sent when a request is invalid or unrecognized by the SMSC. |
| 0x00000001 | bind_receiver | Initiates binding of the client (ESME) as a receiver, allowing the client to receive messages from the SMSC. Includes SMSC system ID if successful. |
| 0x80000001 | bind_receiver_resp | Response to bind_receiver, indicating successful binding or providing an error status. Includes SMSC system ID if successful. |
| 0x00000002 | bind_transmitter | Initiates binding of the client (ESME) as a transmitter, allowing the client to send messages to the SMSC. |
| 0x80000002 | bind_transmitter_resp | Response to bind_transmitter, confirming successful binding or indicating errors. Includes SMSC system ID if successful. |
| 0x00000003 | query_sm | Requests the current status of a previously submitted short message using its Message ID. |
| 0x80000003 | query_sm_resp | Response to query_sm, provides the message status (e.g., delivered, pending, failed). |
| 0x00000004 | submit_sm | Requests the SMSC to deliver a short message from ESME to a single destination (mobile handset). |
| 0x80000004 | submit_sm_resp | Response to submit_sm, provides a message ID on success or an error code on failure. |
| 0x00000005 | deliver_sm | Delivers messages (e.g., delivery receipts, mobile-originated SMS) from SMSC to ESME. |
| 0x80000005 | deliver_sm_resp | Response acknowledging successful reception of deliver_sm. |
| 0x00000006 | unbind | Requests termination of the SMPP session (client initiated). |
| 0x80000006 | unbind_resp | Response confirming termination of the session. |
| 0x00000007 | replace_sm | Requests replacement or update of a previously submitted but pending short message. |
| 0x80000007 | replace_sm_resp | Response confirming replacement of the message or indicating an error. |
| 0x00000008 | cancel_sm | Requests cancellation of a previously submitted short message that hasn't been delivered yet. |
| 0x80000008 | cancel_sm_resp | Response indicating successful cancellation or an error. |
| 0x00000009 | bind_transceiver | Requests binding of the client (ESME) as both transmitter and receiver simultaneously. |
| 0x80000009 | bind_transceiver_resp | Response to bind_transceiver, confirming dual binding or returning an error. Includes SMSC system ID if successful. |
| 0x0000000B | outbind | Initiated by SMSC to establish an SMPP session with the ESME. Used in outbind mode, prompting ESME to bind back. |
| 0x00000015 | enquire_link | Tests the session connectivity (heartbeat) from the initiating entity to ensure the session is alive. |
| 0x80000015 | enquire_link_resp | Response confirming session connectivity is active. |
| 0x00000021 | submit_multi | Requests SMSC to deliver the same short message from the ESME to multiple destination addresses in a single request. |
| 0x80000021 | submit_multi_resp | Response to submit_multi, returns message IDs assigned to each recipient or indicates an error. |
| 0x00000102 | alert_notification | Notification from SMSC to ESME indicating a subscriber is now available (previously unavailable). |
| 0x00000103 | data_sm | Alternative to submit_sm and deliver_sm, used primarily for data messaging or non-text content (binary content). |
| 0x80000103 | data_sm_resp | Response to data_sm, acknowledging message acceptance and returning message ID or an error code. |
Command Status
Indicates whether an SMPP request was successful or failed.
In request PDUs this value must be set to NULL (0x00000000).
For example, if an SMSC rejects a request due to throttling, the response might contain 0x00000045 (Throttling error).
The SMPP Error status codes are returned by the SMSC in the command_status field of the SMPP message header and in the error_status_code field of a submit_multi_resp message.
See the complete list of status codes in Error Handling and Status Codes section
Sequence Number
Correlates requests and responses, allowing SMPP messages to be processed asynchronously.
Range: 0x00000001 to 0x7FFFFFFF
If client sends submit_sm with sequence_number = 1001, the SMSC responds with submit_sm_resp using the same sequence_number = 1001, allowing the client to match the response to the request.
Start innovating with Mobius
What's next? Let's talk!