SMPP explained
SMPP (Short Message Peer-to-Peer) is the open TCP protocol that carries A2P SMS between an application — the ESME — and a mobile operator's SMSC. The ESME opens a persistent bind, submits messages as binary submit_sm PDUs and receives delivery receipts back over the same socket.
Summarised from How does the SMPP protocol work?
How it works
- 1
Bind
The ESME opens a TCP connection (ideally TLS) and sends bind_transceiver with a system_id and password. It can bind as Transmitter, Receiver or Transceiver; a Transceiver bind over SMPP 3.4 is the modern default.
Read the full answer - 2
Submit
Each message goes out as a submit_sm PDU, and the SMSC acknowledges with a submit_sm_resp carrying a message_id. The window — how many PDUs may be in flight unacknowledged — is what most often caps real throughput.
Read the full answer - 3
Receive delivery receipts
Delivery receipts arrive asynchronously as deliver_sm PDUs on the same socket and are matched back to the original message by message_id.
Read the full answer - 4
Keep the session alive
An enquire_link heartbeat every 30 seconds keeps the bind up, the client reconnects with exponential backoff, and unbind closes the session cleanly. A failed submit returns a numeric command_status to decode.
Read the full answer
Key terms
Each term has its own answer page with the full explanation.
- What is SMPP?SMPP (Short Message Peer-to-Peer) is the open-protocol standard for exchanging SMS between SMSCs, ESMEs (External Short Message Entities), and aggregators.
- How does the SMPP protocol work?SMPP (Short Message Peer-to-Peer) is the open TCP protocol that carries A2P SMS between an application — the ESME — and a mobile operator's SMSC.
- What is an ESME?ESME (External Short Messaging Entity) is the SMPP term for any application outside the SMSC that submits or receives SMS.
- What is an SMSC?An SMSC (Short Message Service Center) is the core infrastructure component of a mobile network that stores, forwards, and delivers SMS messages between mobile devices and external applications.
- What is SMPP window size?The window is the number of SMPP PDUs an ESME may have in flight — submitted but not yet acknowledged — on a single bind at any moment.
- SMPP 3.4 vs SMPP 5.0 — what changed and what to useSMPP 3.4 (1999) is still the SMS interconnect protocol that runs almost every A2P bind in production today.
- What is a DLR (Delivery Receipt)?A DLR is the asynchronous confirmation that an SMS has been delivered (or failed to deliver) at the handset.
- What is TPS (Transactions Per Second)?TPS (transactions per second) — also called MPS or send rate — is the throughput ceiling of a messaging bind or account: how many SMS submit_sm PDUs the SMSC accepts per second before it returns throttling errors.
- TLS 1.3 in messaging — what changed and why it matters for SMPPTLS 1.3 (RFC 8446, 2018) replaced TLS 1.2 with a faster handshake, removed every algorithm that had been broken in the previous decade, and made forward secrecy mandatory.
Guides and further reading
- ReferenceSMPP protocol overview
- ReferenceSMPP bind operations and session states
- ReferenceSMPP submit_sm: every mandatory field
- ReferenceSMPP command_status error codes
- GuideSMPP Integration Checklist
- ArticleThe operating cost of an SMS integration: binds, webhooks and failure modes
- ArticleSMS throughput and TPS planning: sizing SMPP binds for high-volume campaigns
- ComparisonSMS API vs SMPP
- Developer docsSMPP integration
- ToolSMPP Error Code Lookup
Frequently asked questions
When should you choose SMPP over REST?
Choose SMPP when you sustain several hundred messages per second or need persistent binds (capacity per bind is agreed with your account team), run latency-critical OTP where every millisecond counts, or integrate into an operator/aggregator ecosystem that already speaks SMPP everywhere. Otherwise a REST SMS API (no fixed per-account rate limit at BroadNet) is simpler to run and delivers over the identical routes.
Read the full answerShould I use SMPP 5.0 for a new integration?
Almost never. Bind SMPP 3.4 over TLS unless a specific counterparty requires 5.0. The install base, tooling, and operator support all sit on 3.4, and 5.0 offers no deliverability advantage on commercial A2P routes.
Read the full answerDoes SMPP 5.0 deliver messages better than 3.4?
No. Deliverability is a function of the operator route, not the SMPP version. The things 5.0 improved (Unicode headers, billing TLVs) are typically handled at the application layer on top of 3.4.
Read the full answerHow do I send Arabic or emoji over SMPP 3.4?
Set data_coding to UCS-2 (0x08), or carry the body in a message_payload TLV. 3.4 handles Unicode content fine; you do not need 5.0 for it.
Read the full answerWhat bind type and port should I use?
A transceiver bind over TLS is the standard for A2P — it sends submit_sm and receives DLRs on one socket. BroadNet offers SMPP 3.4 binds; the host, port and credentials are provided with your test access.
Read the full answer