bg-gradient-orange-post
bg-gradient-orange-post-mobile
Dec, 10 2020

SMPP: Short Message Peer-to-Peer Protocol

Quick definition: SMPP, or Short Message Peer-to-Peer Protocol, is the system of rules that lets devices and software applications send and receive text messages over the internet.

iot_glossary
Share this post

SMPP is essentially the language cellular networks use to relay text messages. It governs how External Short Message Entities (ESME) such as business texting apps and cellular IoT devices exchange Short Message Services (SMS) with a mobile device. 

All SMS communications have to go through a network provider’s Short Message Service Center (SMSC). Computers need a third-party system such as an SMS gateway or SMPP gateway to connect to the service center, and then the gateway and SMSC use SMPP to govern the interaction.

Here’s what it looks like:

SMPP Bind

You’ll sometimes see a distinction between “peer-to-peer messaging” and “application-to-peer messaging,” wherein P2P implies communication between two mobile devices, and A2P implies communication between software and a mobile device. The SMPP applies to both because software and mobile devices can use this same protocol to exchange SMS messages with mobile devices.

How does the SMPP work?

When an SMS-enabled device or application wants to send a text to another device, it initiates an SMPP session with a cellular carrier’s Message Center (MC), also known as an SMSC.

During the session, the device and the Message Center use the SMPP protocol to send requests (or commands) and respond to one another. They package these requests and responses as “Protocol Data Units” (PDUs). It’s how they define whether an External Short Message Entity (ESME) is going to send or receive an SMS communication (or do both), and how they actually relay the information.

It’s kind of like this: the two entities that need to exchange messages have to speak through a mediator. The cellular carrier’s Message Center establishes which entity is sending or receiving and then accepts or rejects the SMS transmission on behalf of the recipient. If one of the entities needs to use a gateway to communicate via SMS, then the gateway acts as a mediator as well, relaying information to and from the Message Center.

If the transmission is rejected, an error code relays what went wrong. For example, it can specify an invalid request, destination, message ID, or message length.

SMPP sessions

There are four types of SMPP sessions, three of which are initiated by the ESME, and the MC initiates the other.

Transmitter (TX)

An ESME will initiate a session as a transmitter in order to send SMS messages to a mobile device. It can also use a transmitter session to cancel previously sent messages. Since it sends these messages to a mobile device, they’re also known as mobile terminated messages.

Receiver (RX)

An ESME will initiate a session as a receiver in order to receive SMS messages from a mobile device. Since these messages originate from the mobile device, they’re also known as mobile originated devices.

Transceiver (TRX)

Transceiver sessions allow ESMEs to both send and receive SMS messages. The oldest version of the SMPP doesn’t allow this type of session.

Outbind session

An outbind session is simply an SMPP session that the Message Center initiates. 

Protocol data units (PDUs)

PDUs contain the actual commands and responses the SMSC and MC send to each other, formatted according to the protocol. 

At the start of every session, a bind command defines the type of interaction that will take place. For example, to initiate a transmitter session, the SMSC sends a PDU with the command bind_transmitter. This initial PDU also contains the ESME’s identification, type, and a password. It also specifies which version of the SMPP the ESME is using, so the MC knows how to interpret the commands and which PDUs can be used.

PDUs also define which direction an SMS communication is coming from. If an ESME wants to send a text message, for example, the SMSC sends the request submit_sm to the MC.

SMPP versions

There are three versions of the SMPP:

  • SMPP v3.3
  • SMPP v3.4
  • SMPP v5.0

SMPP v3.3 is the oldest version of the SMPP. Later versions added new session types (transceiver sessions), support for additional technologies, and new PDU parameters (some of which are optional). 

Since the SMPP version determines how the two entities can interact, every session has to define what version the ESME is using.

What is the SMPP used for?

The SMPP is a key component of modern SMS communications, and it’s used in a broad range of applications. Here are just a couple of use cases.

Business texting uses the SMPP to send text messages from a software program to individual phone numbers or a mass list of them. This includes everything from marketing messages to information services, appointment reminders, chatbot services, and even password reset requests.

Cellular Internet of Things (IoT) devices such as smart meters use the SMPP to transmit updates about resource consumption and location status. When an event like a break-in or fire triggers a smart alarm system, it uses the SMPP to message the building owner, potentially with a link that allows them to access a camera feed.

Does your IoT device need to use SMS?

If your IoT device relies on cellular connectivity, it’s probably going to use SMS to transmit and receive information. But that doesn’t mean you have to use SMPP. SMPP is a complicated protocol that most IoT manufacturers can avoid relying on for SMS.

EMnify is an IoT connectivity platform. Not only do we enable IoT manufacturers to take advantage of cloud native connectivity, but we also simplify SMS communications for your IoT device. Using our RESTful API, your devices can communicate over SMS using JavaScript Object Notation (JSON), and you don’t have to worry about SMPP.

Talk to an expert and discover how EMnify provides complete end-to-end connections for your cellular IoT devices.

Get in touch and learn more

We value your privacy.