Hello! Although messengers and social networks are displacing traditional means of communication every day, the popularity of SMS remains unaffected. Verification on a popular website, or notification about a transaction, they repeat and will continue to live on. Have you ever wondered how it all works? Very often, the SMPP protocol is used for sending bulk messages, which is what this article will cover.
There have already been articles about SMPP on Habr, ,, but their purpose was not to describe the protocol itself. Of course, you can start directly with the original source — , but I think it would be good to have a brief overview as well. I will explain using version 3.4. I welcome your objective criticism.
The SMPP protocol is a peer-to-peer messaging protocol. This means that each peer/hub server is equal. In its simplest form, the SMS messaging exchange scheme looks like this:
However, if the national operator does not have a route to a remote region, they request a middleware—an SMS hub. Sometimes, to send one SMS, a chain must be built between several countries, or even continents.
About the protocol
SMPP is an application-level protocol based on PDU exchange and transmitted over TCP/IP or X.25 sessions for sending SMS and USSD messages. Typically, SMPP is used in a persistent connection mode, which helps save time. SMPP uses a client-server communication model.
Communication mode
Message exchange between the sender and the SMS center via SMPP can be conducted in the following modes:
Transmitter — message transmission in one direction, sequentially
Receiver — only receiving messages from the SMS center.
Transreceiver — message exchange between the SMS center and the user
Structure
Message length
One SMS message can contain 70 characters when typed in Cyrillic and no more than 157 Latin characters + 3 UDH. If an SMS exceeds the character limit, it will be split into several segments and recombined on the receiving device. In case of segmentation, the number of characters decreases due to message headers indicating the part of the message. Therefore, when sending a large SMS message, it contains a maximum of 153 Latin characters or 67 non-typical characters.
Data Coding Scheme
However, characters require encoding for message transmission. In the SMPP protocol, a special field—the Data Coding Scheme, or DCS—handles encoding. This field indicates how messages should be recognized. Additionally, the DCS field includes:
- a character set that defines the encoding;
- the message class;
- a request for automatic deletion after reading;
- an indication for message compression;
- the language of the broadcast message;
Standard 7-bit alphabet (GSM 03.38). It was developed for the messaging system in GSM. This encoding is suitable for English and a number of Latin languages. Each character consists of 7 bits and is encoded in an octet.
UTF-16 (in GSM UCS2) was developed to include missing characters in the 7-bit alphabet, adding additional characters (including Cyrillic) by reducing the message size from 160 to 70; this type of encoding approximately mirrors Unicode.
8-bit user-defined data. This includes KOI8-R and Windows-1251. While this solution seems more economical compared to UTF-16, there arises a legitimate question of compatibility on different devices, as in this case both devices must be pre-configured.
Message class
- Class0, or flash, messages, are stored in the phone's memory at the user's discretion;
- Class1, or those stored in the phone's memory;
- Class1, or those stored in the phone's memory;
- Class2 must ensure that the message will be saved in the mobile terminal's memory; otherwise, it must notify the SMS center of the inability to save;
- Class3 — in this case, the phone must notify that the message can be saved, regardless of the device's memory capacity. This type of message implies that the message reached the recipient;
Message type
Silent message (SMS0) A type of SMS message without content. Such an SMS arrives without notification and does not appear on the device's screen.
PDU
Each PDU operation is paired and consists of a request and a response. For example: a command that indicates establishing a connection (bind_transmitter / bind_transmitter_resp), or that the message has been delivered (deliver_sm / deliver_sm_resp)
Each PDU packet consists of two parts — header and body. The structure of the header is the same for any PDU packet: command length is the length of the packet, id is the name of the packet, and the status command indicates whether the message was successfully transmitted or if there was an error.
Additional TLV parameters
TLV (Tag Length Value), or additional fields. Such parameters are used to extend the functions of the protocol and are not mandatory. This field is specified at the end of the PDU field. As an example, using TLV dest_addr_np_information can facilitate the transmission of number portability information.
TON and NPI
TON (Type of Number) parameter informs the SMSC about the addressing format and type of network.
NPI (Numbering Plan Identification) parameter indicating the numbering plan.
Source address of the message, or alpha name
Messages sent to a phone can be of two varieties: numeric and alphabetic. Numeric messages can be long (similar to a phone number) and short. Sometimes operators have restrictions on sending from neutral names, such as Infosms, Alert, etc. Occasionally, operators do not allow traffic if the name is not registered in their network. However, this is more of an operator's peculiarities.
Stages of sending
SMS-SUBMIT — is the submission of an MO FSM (mobile terminal short message)
SMS-SUBMIT REPORT — confirmation that the message has been sent to the SMSC
SRI SM (SendRoutingInfo) — the SMSC obtains information from the HLR regarding the MSC / VLR location of the subscriber
SRI SM RESP — the response from the HLR regarding the subscriber's location
MT-FSM — after obtaining the location, the message is sent using the 'Forward Short Message' operation
MT-FSM ACK — response from the SMSC indicating that the message has been sent
SMS-STATUS REPORT — the SMSC sends the status of the message delivery.
Message delivery status
SMS-STATUS REPORT can take several values:
DELIVRD the message was successfully delivered
REJECTD — the message was rejected by the SMS center
EXPIRED — the message was removed from the sending queue after TTL (time-to-live) expired
UNDELIV — other undelivered cases
UNKNOWN- no response received about the sending.
Transmission errors
Sometimes there are reasons why SMS messages are not delivered to the subscriber. The result of these reasons is the occurrence of errors. Errors are returned in PDUs_sms_resp. All errors can be divided into temporary (Temporary) and permanent (Permanent).
For example, temporary errors can include absent_subscriber when the subscriber is unavailable or offline, while permanent errors indicate that the subscriber does not exist. The message retransmission policy is shaped by the errors that occur.
For instance, if the subscriber was on a call and received an error indicating MT handset is busy, the message can be resent after a few minutes. However, if the subscriber has blocked the message reception service, resending will not make sense. You can find the list of errors on the SMSC pages, for example, as .
Source: habr.com
