# SMPP v3.4 vs v5.0: what changed

> SMPP v5.0 is backward compatible with v3.4 and adds congestion-control signalling, broadcast messaging operations (broadcast_sm and friends), an extra message state (SKIPPED) and additional TLVs. Despite this, v3.4 remains the dominant interconnect because it is universally supported; v5.0 is used only where both peers implement it.

- Canonical URL: https://www.broadnet.me/reference/smpp-3-4-vs-5-0
- Language: en
- Last updated: 2026-07-18
- Publisher: BroadNet (https://www.broadnet.me)

The practical differences between SMPP v3.4 and v5.0: congestion control, broadcast operations, extra message states and TLVs — and why v3.4 is still the default interconnect.

## What v5.0 adds

v5.0 is an incremental, backward-compatible revision of v3.4. Its headline additions are congestion control (the SMSC advertises load so ESMEs can slow down before being throttled), a family of broadcast operations for cell-broadcast-style messaging, a new SKIPPED message state, and extra optional parameters. The core PDU format, the bind model and submit_sm/deliver_sm are unchanged, which is why an v3.4 ESME can talk to a v5.0 SMSC.

*v3.4 → v5.0 additions*

| Area | v3.4 | v5.0 addition |
|---|---|---|
| Congestion control | None (react to throttling) | congestion_state TLV — proactive |
| Broadcast | Not supported | broadcast_sm / query_broadcast_sm / cancel_broadcast_sm |
| Message states | 8 states | Adds SKIPPED (9) |
| Optional params | v3.4 TLV set | Additional TLVs |
| interface_version | 0x34 | 0x50 |

## What stayed the same

The fundamentals are identical: the 16-byte header, big-endian encoding, the three bind types, session states, enquire_link keepalive, submit_sm/deliver_sm field layouts and the ESME_R* error range all carry over. TLVs — introduced in v3.4 — remain the extension mechanism. This continuity is deliberate: v5.0 was designed so existing v3.4 integrations keep working.

## Which version to use

Use v3.4 unless you have a concrete reason to use v5.0 and both peers support it. v3.4 is the safe, universal default for A2P interconnect. Reach for v5.0 when you specifically need its congestion signalling or broadcast operations and the provider confirms support. Always confirm the negotiated version from the bind_resp (the sc_interface_version TLV) rather than assuming a feature is available.

## Frequently asked questions

### Is SMPP v5.0 backward compatible with v3.4?

Yes. v5.0 preserves the v3.4 PDU format, bind model and core operations, so a v3.4 ESME and a v5.0 SMSC can interoperate. The version is declared in interface_version (0x34 vs 0x50).

### Why is SMPP v3.4 still the most common version?

Because it is universally implemented and covers the needs of A2P messaging completely. v5.0's additions — congestion control, broadcast — are useful in specific scenarios but not required for standard MT/MO traffic, so most interconnects stayed on v3.4.

### What is the main practical benefit of v5.0?

Proactive congestion control: the congestion_state TLV lets the SMSC advertise its load so a cooperative ESME slows down before hitting hard ESME_RTHROTTLED errors, giving smoother throughput under pressure.

### How do I know which version a session negotiated?

Read the sc_interface_version TLV returned in the bind_resp. Do not assume v5.0 features are available just because you sent interface_version 0x50 — the SMSC reports what it actually supports.

## Sources

- [SMPP v3.4 specification](https://smpp.org/SMPP_v3_4_Issue1_2.pdf)
- [SMPP v5.0 specification](https://smpp.org/SMPP_v5.pdf)

## Related

- [SMPP protocol overview](https://www.broadnet.me/reference/smpp-protocol-overview)
- [SMPP enquire_link & throttling](https://www.broadnet.me/reference/smpp-enquire-link-throttling)
- [SMPP bind operations](https://www.broadnet.me/reference/smpp-bind-operations)
- [What is SMPP?](https://www.broadnet.me/answers/what-is-smpp)
- [SMPP integration checklist (guide)](https://www.broadnet.me/guides/smpp-integration-checklist)