Blog Article

In international SMS business, enterprises typically need to connect their business systems with cloud communication platforms, SMS gateways, or carrier networks through standardized communication protocols.

The SMPP protocol is one of the widely used protocols in the SMS communication field.

For enterprises that need to handle large volumes of verification codes, notification SMS, and marketing messages, SMPP is not only about how the SMS system is accessed, but also involves concurrency capability, message receipts, connection stability, and system scalability.

So, what is SMPP? How does the SMPP protocol work? What is the difference between SMPP and HTTP API? What should enterprises pay attention to when accessing SMPP?

1. What is SMPP?

SMPP stands for Short Message Peer-to-Peer Protocol.

Simply put, SMPP is a communication protocol used for message exchange between SMS entities, commonly seen in data communication between enterprise SMS systems, cloud communication platforms, SMS gateways, and carrier SMS centers.

In a typical international SMS architecture, enterprise systems can establish a TCP long connection with a cloud communication platform via SMPP, and the platform then submits the SMS to the corresponding carrier network.

The typical communication link is as follows:

Enterprise Business System → SMPP Client → Cloud Communication Platform → SMS Gateway → Carrier → User Handset

From a technical implementation perspective, SMPP differs significantly from ordinary HTTP SMS interfaces.

HTTP API usually adopts a request-response model and is relatively simple to develop; while SMPP is usually based on a TCP long connection and continuously exchanges messages through binary PDUs, making it more suitable for high throughput, long connections, and system interconnection between communication platforms.

TCP connection established
      ↓
Bind authentication
      ↓
SMPP session established
      ↓
submit_sm submit SMS
      ↓
submit_sm_resp returns submission result
      ↓
deliver_sm returns status report
      ↓
DLR updates final SMS status

For enterprise technical personnel searching for "what is SMPP" or "SMPP protocol detailed explanation", it is very important to understand this:

SMPP is not simply an SMS API, but a standardized communication protocol for message exchange between SMS systems.

2. How does the SMPP protocol work?

SMPP usually communicates over TCP.

After the client and server establish a TCP connection, authentication is performed through the Bind operation. Once authentication succeeds, SMS can be submitted.

A complete SMPP communication flow is roughly as follows:

TCP connection established
      ↓
Bind authentication
      ↓
SMPP session established
      ↓
submit_sm submit SMS
      ↓
submit_sm_resp returns submission result
      ↓
deliver_sm returns status report
      ↓
DLR updates final SMS status

Special attention should be paid here: successful SMS submission does not equal final delivery to the handset.

For example, an enterprise sends a verification code:

Enterprise System
   ↓
submit_sm
   ↓
SMS Platform
   ↓
Carrier
   ↓
Target Handset

The platform returns:

submit_sm_resp = OK usually only indicates that the SMS submission request has been accepted by the platform.

Subsequently, the final result still needs to be determined based on the Delivery Receipt returned by the carrier, i.e., the SMS Delivery Receipt (DLR). Therefore, when purchasing SMPP SMS services, one should not only focus on whether the interface can successfully submit, but more importantly on: whether real DLR is supported, whether DLR is traceable, whether it can be associated with Message ID, and whether different failure reasons can be distinguished.

3. What are the core PDUs in the SMPP protocol?

SMPP uses PDUs (Protocol Data Units) for data communication.

A typical SMPP PDU structure can be understood as:

command_length
command_id
command_status
sequence_number
command_body

1. command_length

Indicates the length of the entire PDU.

When reading TCP data, the SMPP client or server needs to determine the boundary of the complete PDU based on this field. Therefore, when developing an SMPP client or server, it is also necessary to correctly handle TCP sticky packet and packet splitting issues.

2. command_id

command_id indicates the type of the current PDU. Common SMPP commands include:

bind_transmitter
bind_transmitter_resp

bind_receiver
bind_receiver_resp

bind_transceiver
bind_transceiver_resp

submit_sm
submit_sm_resp

deliver_sm
deliver_sm_resp

unbind
unbind_resp

Among them, the most important commands in the enterprise SMS sending process are: bind_transceiver, submit_sm, deliver_sm.

3. command_status

command_status indicates the status of the current operation. For example:

ESME_ROK
ESME_RINVSYSID
ESME_RINVPASWD
ESME_RSYSERR
ESME_RTHROTTLED

Among them, ESME_ROK usually indicates success. ESME_RTHROTTLED usually indicates that the request is subject to flow control. For high-concurrency SMS systems, error codes cannot be simply classified as "success/failure"; instead, mechanisms for retry, rate limiting, degradation, and failover should be designed according to the error type.

For high-concurrency SMS systems, error codes cannot be simply classified as "success/failure"; instead, mechanisms for retry, rate limiting, degradation, and failover should be designed according to the error type.

4. sequence_number

Sequence Number is a key field in the SMPP protocol.

The client sends: submit_sm sequence_number = 10001, and the server returns: submit_sm_resp sequence_number = 10001. The client can then match the response with the original request through the Sequence Number.

In high-concurrency environments, the Sequence Number generation and request matching mechanism must be reliable, otherwise response mismatches may occur.

4. What are the Bind modes of SMPP?

The SMPP protocol provides multiple connection modes, among which the following three are most common in enterprise SMS systems.

bind_transmitter

bind_transmitter is mainly used for sending. After establishing an SMPP connection, the enterprise can submit SMS to the SMS platform through this mode.

Typical structure:

Enterprise System
   ↓
bind_transmitter
   ↓
SMS Platform

Suitable for scenarios where only sending messages is required.

bind_receiver

bind_receiver is mainly used for receiving messages. Depending on the specific platform implementation, it can be used to receive Deliver_SM messages, such as SMS status reports or uplink messages.

bind_transceiver

bind_transceiver has both sending and receiving capabilities. For enterprises that need to: send SMS + obtain DLR, this method is very practical.

For example:

Enterprise System
    │
    │ bind_transceiver
    ↓
SMPP Server
   ↙     ↘
Send       Receive
submit_sm  deliver_sm

Therefore, when choosing an SMPP SMS platform, enterprises need to confirm in advance which Bind mode the supplier supports and how many connections are allowed per account.

5. How does SMPP send SMS?

The most core PDU for sending SMS via SMPP is: submit_sm. The enterprise system submits SMS to the SMPP Server through this PDU. The following fields are usually involved:

submit_sm

Field description:

For example, an enterprise sends an OTP verification code:

source_addr
        ↓
YaningAI

destination_addr
        ↓
+***********

short_message
        ↓
Your verification code is 328914.

registered_delivery
        ↓
Request DLR

After receiving submit_sm, the server returns: submit_sm_resp, which usually also includes a Message ID.

This Message ID is very important for subsequent SMS status queries and DLR association.

6. What is DLR in SMPP?

DLR stands for Delivery Receipt. It is used to feed back the processing and delivery results after the SMS enters the carrier network. Common statuses may include:

Common statuses:

DELIVRD
UNDELIV
EXPIRED
REJECTD
UNKNOWN

Different service providers and carriers may have different return formats. The most noteworthy point for enterprises is: submit_sm success != handset received SMS.

The complete SMS status chain should be understood as:

Business Order → Submit SMS → submit_sm_resp → Message ID → Carrier Processing → DLR → Final Status

• Business Order
• Submit SMS
• submit_sm_resp
• Message ID
• Carrier Processing

This is also one of the technical capabilities that enterprises need to focus on when purchasing international SMS services.

For example, if an enterprise needs to count the SMS success rate for a certain country on a given day, only a complete DLR system can help the technical team analyze: submission success rate, carrier acceptance rate, final delivery rate, and failure reasons.

7. What is SMPP TPS?

TPS is a very important indicator for enterprises evaluating SMPP access performance. TPS usually stands for: Transactions Per Second. For example, if a supplier provides: 100 TPS, it means the system can theoretically process about 100 transactions per second.

However, special attention should be paid:

100 TPS

TPS does not necessarily equal the final SMS delivery volume.

Actual throughput is also affected by many factors, including:

• Per-connection rate limit
• Account-level rate limit
• Country-level rate limit
• Carrier restrictions
• Window Size
• Network latency
• SMS length
• Long SMS splitting
• Actual channel capacity

Therefore, for high-concurrency international SMS business, it is recommended to conduct actual stress testing during the technical testing phase, rather than judging solely based on the TPS parameters on the supplier's promotional page.

8. What is SMPP Window Size?

Window Size can be understood as: how many outstanding requests the client can keep while waiting for responses. For example: Window Size = 5, the client can continuously submit:

Continuous submission example:

submit_sm 10001
submit_sm 10002
submit_sm 10003
submit_sm 10004
submit_sm 10005

Then receive:

Response example:

submit_sm_resp 10001
submit_sm_resp 10002
submit_sm_resp 10003
...

Compared to sending one SMS at a time and waiting for a response before sending the next, the Window mechanism can improve communication link utilization. Therefore, when designing a high-concurrency SMPP SMS system, TPS and Window Size usually need to be tuned together.

9. Why does SMPP SMS encoding cause garbled characters?

SMS encoding is a very error-prone issue in SMPP development. Common encoding methods include:

Common encodings:

• GSM 7-bit
• 8-bit
• UCS2

English SMS can usually use GSM 7-bit, etc. Chinese SMS usually needs to use Unicode-related encoding, such as UCS2.

For example: 您的验证码是123456, if data_coding does not match the actual encoding method, it may result in: garbled SMS, or even submission failure.

您的验证码是123456

When developing SMPP interfaces, enterprises should conduct complete testing for different content, including:

English, Chinese, mixed Chinese-English, special characters, Emoji, and long SMS.

Therefore, when testing SMPP SMS interfaces, simple English content should not be the only validation. A more complete test should at least include: ordinary English SMS, Chinese SMS, mixed Chinese-English, special characters, Emoji, ultra-long SMS, and long SMS splitting.

10. How is long SMS implemented in SMPP?

When SMS content exceeds the length supported by a single SMS, it needs to be split. For example:

Original SMS
↓
SMS 1/3
SMS 2/3
SMS 3/3

After the handset receives multiple SMS fragments, it reassembles them based on relevant information.

In SMPP implementations, UDH (User Data Header) is often involved.

Therefore, when testing SMPP SMS interfaces, simple English content should not be the only validation. A more complete test should at least include:

Ordinary English SMS
Chinese SMS
Mixed Chinese-English
Special characters
Emoji
Ultra-long SMS
Long SMS splitting

Only by covering these scenarios can you ensure that long SMS displays correctly on different handsets.

11. What is the difference between SMPP and HTTP SMS API?

This is a common question when enterprises are selecting SMS technology.

Therefore, it cannot be simply assumed that: SMPP is definitely better than HTTP API. A more accurate judgment is:

For mature cloud communication platforms, simultaneously providing: HTTP API + SMPP can cover the technical architecture needs of more enterprise customers.

Therefore, enterprises should choose the appropriate access method based on their own business scale, technical architecture, and concurrency requirements.

12. What technical issues should enterprises consider when accessing SMPP?

When choosing an SMPP SMS service, enterprises should not just look at whether there is an "SMPP interface". What really needs to be evaluated is the entire communication link.

1. SMPP Version

Confirm whether the supplier supports: SMPP 3.4 or other protocol versions.

SMPP 3.4

At the same time, confirm the actually supported PDUs and extension fields.

2. TPS and Window Size

Key confirmations:

What is the per-connection TPS? How many connections are supported per account? What is the Window Size? Are there different rate limits for different countries?

3. DLR Capability

Key confirmations:

Is real delivery receipt supported? Is Message ID returned? Can it be associated with a business ID? Can different failure reasons be distinguished?

4. Sender ID Support

International SMS business usually needs to confirm the Sender ID usage rules based on the target country, carrier, and SMS type.

Some countries or regions may require Sender ID to be registered in advance or undergo relevant review. Therefore, before accessing international SMS, enterprises should confirm the Sender ID rules of the target market.

5. International SMS Routes

SMPP is only a technical access protocol. It cannot directly represent the quality of SMS routes. What enterprises really need to focus on is: carrier coverage, local routes, routing quality, peak capacity, DLR completeness, and compliance capabilities.

In other words:

13. How to build a highly available SMPP architecture?

For enterprises with large SMS volumes, it is not recommended to rely on only one SMPP connection. A more reasonable architecture can adopt:

High availability architecture diagram:

              Enterprise Business System
                    │
                    ↓
                API Gateway
                    │
                    ↓
                 Message Queue
                    │
          ┌─────────┴─────────┐
          ↓                   ↓
     SMPP Worker A       SMPP Worker B
          ↓                   ↓
     Connection A        Connection B
          │                   │
          └─────────┬─────────┘
                    ↓
                 SMS Platform
                    │
             ┌──────┴──────┐
             ↓             ↓
          Route A        Route B
             ↓             ↓
           Carrier         Carrier
             └──────┬──────┘
                    ↓
                  DLR
                    ↓
                Status System

Such an architecture can achieve: decoupling of business systems, message queues, SMPP connections, SMS routing, and status receipts.

When a connection fails, connection pools, backup connections, or backup routes can be used to reduce the impact on the overall business.

14. Common SMPP development issues

Frequent TCP connection disconnections

Common causes include:

• Network anomalies
• Firewall policies
• Heartbeat timeout
• Server actively disconnects
• Long idle connection

Usually needs to design: heartbeat detection + automatic reconnection + connection status monitoring.

submit_sm timeout

After the client sends a request, if submit_sm_resp is not received within the specified time, the corresponding request needs to be released in time, otherwise the Window may be occupied for a long time.

Sequence Number confusion

In high-concurrency environments, it is necessary to ensure that the Sequence Number generation mechanism is reliable and correctly establishes the mapping between requests and responses.

DLR cannot match business orders

It is recommended to establish a complete status association chain:

Business Order Number
   ↓
SMS Task ID
   ↓
Message ID
   ↓
DLR
   ↓
Final SMS Status

Only by achieving this level can enterprises truly make the SMS link traceable.

15. Which enterprises are suitable for SMPP?

From actual application scenarios, the following enterprises are usually more worth considering SMPP access:

Cross-border E-commerce

Used for: order notifications, logistics reminders, login verification codes, account security notifications.

Fintech

Used for: OTP, payment reminders, transaction notifications, risk control messages.

Overseas Game Platforms

Used for: registration verification codes, login authentication, account notifications.

Social Platforms

Used for: mobile number verification, account login, password recovery.

Large Internet Platforms

Used for: high-concurrency SMS submission, batch message processing, and communication system interconnection.

For enterprises with small SMS volumes, HTTP API can be prioritized. For enterprises that need to handle large volumes of international SMS every day, SMPP access can be further evaluated.

16. What should enterprises ask suppliers when purchasing SMPP SMS services?

During the technical procurement stage, it is recommended to include the following in the supplier test table:

17. SMPP is just an interface; route quality determines the final communication effect

When many enterprises purchase international SMS services for the first time, they focus on comparing: API price, SMPP price, TPS, and free test quota. These indicators are certainly important, but they cannot fully reflect the SMS service quality.

For international SMS business, more worthy of attention is: SMPP access capability + international carrier resources + routing strategy + DLR capability + compliance capability + O&M support.

For example, both are SMPP interfaces with 100 TPS:

The performance of the two in actual SMS business may differ significantly. Therefore, when purchasing technology, enterprises should not only ask:

Instead, they should further confirm:

This is a technical evaluation with actual procurement value.

18. YaningAI International SMS SMPP Access Capability

For enterprises that need to conduct overseas business, a stable international SMS infrastructure is more important than simply having an SMS interface.

YaningAI provides international SMS communication capabilities for enterprise business systems, supporting enterprises to choose appropriate access methods based on their own technical architecture.

For technical teams and communication platforms, you can focus on: SMPP access, HTTP API access, international SMS routing, message status tracking, and enterprise-level communication system integration.

Enterprises can choose the appropriate access method based on their own business scale, technical architecture, and SMS concurrency requirements.

Learn about international SMS access solutions immediately:

Learn about International SMS Access Solutions

Get SMPP / API technical access materials →

Apply for international SMS testing →

Contact the technical team to evaluate the access solution →

Conclusion

The SMPP protocol is one of the important technical standards in the SMS communication field.

On the surface, it is only responsible for message transmission between enterprises and SMS platforms; but from the perspective of a complete enterprise SMS system architecture, SMPP actually involves: TCP connection, Bind authentication, PDU, submit_sm, Sequence Number, TPS, Window Size, encoding, long SMS, and DLR.

For enterprise technical teams, mastering these basic concepts can help developers complete SMPP system access faster, and also help procurement teams more accurately judge the technical capabilities of different international SMS suppliers.

Especially in international SMS business, one should not only compare interface prices. What truly determines the business experience is: protocol access capability, system stability, concurrency capability, carrier resources, routing quality, delivery receipts, and compliance capability.