An SMPP bind is an authenticated session between your platform and the SMS supplier, and TPS (transactions or messages per second) is how many messages you may submit per second on it. Suppliers set a TPS limit per bind or per account and a maximum number of binds; exceeding it returns throttling errors, so size your connection to your peak traffic, counting every segment.
Bind types
SMPP 3.4 defines three ways to bind to an SMSC, each opened with its own command and system_id and password:
| Bind | Command | Direction |
|---|---|---|
| Transmitter (TX) | bind_transmitter | You send messages (submit_sm) |
| Receiver (RX) | bind_receiver | You receive delivery reports and inbound messages (deliver_sm) |
| Transceiver (TRX) | bind_transceiver | Both on one session |
Most A2P connections today use transceiver binds. With separate TX and RX binds, make sure at least one receiver is always connected, or delivery reports queue up at the supplier. The basics of SMPP are in SMPP vs HTTP API for A2P SMS.
What TPS means
TPS is the number of submit_sm operations allowed per second. A few points that cause confusion:
- Segments count: a 3-part long SMS uses 3 transactions.
- Per bind or per account: a limit of 50 TPS may apply to each bind or to all binds together. Ask which.
- Burst vs sustained: some suppliers allow short bursts above the limit, others enforce it strictly per second.
- Destination limits: the supplier's own upstream can have lower limits for some countries or networks, so your account TPS is not always available everywhere.
Typical figures range from 10 to 100 TPS per bind for normal A2P accounts, with more for large senders. A campaign of 360,000 messages at 100 TPS takes one hour; at 20 TPS it takes five.
Windowing
SMPP is asynchronous: you can send several submit_sm before receiving the responses. The window size is how many requests may be outstanding at once. A window that is too small limits throughput when latency is high (with 200 ms round trip and a window of 1, you cannot exceed 5 TPS). A window that is too large can overload the supplier. Values around 10 to 50 are common; agree them with the supplier.
What happens when you exceed limits
- ESME_RTHROTTLED (0x58): too many messages per second. Slow down and retry later.
- ESME_RMSGQFUL (0x14): the supplier's queue is full. Retry after a pause.
- ESME_RALYBND (0x05) or ESME_RBINDFAIL (0x0D): often returned when you open more binds than allowed or with wrong credentials.
Your platform should back off on throttling errors instead of retrying immediately, which only makes it worse. The full list is in common SMPP error codes.
Keeping binds healthy
- Send enquire_link every 30 to 60 seconds (agree the interval), and reconnect automatically when it fails.
- Spread traffic across binds with a simple round-robin, and do not open more than allowed.
- Use IP whitelisting and, where offered, TLS or a VPN, because SMPP 3.4 sends credentials in plain text.
- Monitor submit_sm_resp latency: a rise often comes before throttling or delivery problems. See SMS delivery rate and latency.
- For US traffic, remember that carrier throughput limits per brand and campaign can be lower than your SMPP TPS. See 10DLC and toll-free SMS.
Sizing a request
Calculate your peak per second, not your monthly volume: OTP traffic at 9:00 on a Monday or a campaign launch can be ten times the average. When you request A2P SMS routes through VoIPMatcher, state the TPS and number of binds you need. Request an SMPP route.
Frequently asked questions
Why does my SMPP bind fail?
The most common causes are a wrong system_id or password, an IP address not whitelisted by the supplier, or more binds open than the account allows. The supplier then answers with errors such as ESME_RBINDFAIL (0x0D), ESME_RINVPASWD (0x0E) or ESME_RALYBND (0x05). Check credentials and allowed IPs, close stale sessions and confirm the bind limit.
How many SMPP binds do I need?
Divide your peak messages per second by the TPS allowed per bind, then add one bind for redundancy. If the supplier sets the limit per account rather than per bind, extra binds add resilience but not throughput. Most A2P connections use transceiver binds, so one session carries both submissions and delivery reports.
What is a good TPS for SMS?
Normal A2P accounts are typically set between 10 and 100 TPS per bind, with more for large senders. The right figure depends on your peak, not your monthly volume: 360,000 messages take one hour at 100 TPS and five hours at 20 TPS. Remember that each segment of a long message counts as one transaction.
What is enquire_link in SMPP?
Enquire_link is a keep-alive command that either side sends to check that the SMPP session is still working. Most setups send it every 30 to 60 seconds, with the interval agreed with the supplier. If no response arrives, the client should close the bind and reconnect automatically, so messages and delivery reports do not queue up.
Need a route?
Send the destination, route type and target rate. We reply with what we can deliver.