Short Message Peer-to-Peer
Short Message Peer-to-Peer in the telecommunications industry is an open, industry standard protocol designed to provide a flexible data communication interface for the transfer of short message data between External Short Messaging Entities, Routing Entities and SMSC.
SMPP is often used to allow third parties to submit messages, often in bulk, but it may be used for SMS peering as well. SMPP is able to carry short messages including EMS, voicemail notifications, Cell Broadcasts, WAP messages including WAP Push messages, USSD messages and others. Because of its versatility and support for non-GSM SMS protocols, like UMTS, IS-95, CDMA2000, ANSI-136 and iDEN, SMPP is the most commonly used protocol for short message exchange outside SS7 networks.
History
SMPP was originally designed by Aldiscon, a small Irish company that was later acquired by Logica. The protocol was originally created by a developer, Ian J Chambers, to test the functionality of the SMSC without using SS7 test equipment to submit messages.In 1995 the ETSI included the SMPP protocol into the technical report TR 03.39.
In 1999 Logica formally handed over SMPP to the SMPP Developers Forum, later renamed as The SMS Forum.
The SMS Forum disbanded in 2007, with this announcement: "The SMS Forum, a non-profit organization with a mission to develop, foster and promote SMS to the benefit of the global wireless industry will disband by July 27, 2007." As part of the original handover terms, SMPP ownership returned to Mavenir.
Operation
SMPP uses the client–server model of operation, despite "peer-to-peer" in the name. The Short Message Service Center (SMSC) usually acts as a server, awaiting connections from ESMEs. When SMPP is used for SMS peering, the sending MC usually acts as a client.The protocol is based on pairs of request/response PDUs exchanged over OSI layer 4 connections. The well-known port assigned by the IANA for SMPP when operating over TCP is 2775, but multiple arbitrary port numbers are often used in messaging environments.
Before exchanging any messages, a bind command must be sent and acknowledged. The bind command determines in which direction will be possible to send messages; bind_transmitter only allows client to submit messages to the server, bind_receiver means that the client will only receive the messages, and bind_transceiver allows message transfer in both directions. In the bind command the ESME identifies itself using system_id, system_type and password; the address_range field designed to contain ESME address is usually left empty. The bind command contains interface_version parameter to specify which version of SMPP protocol will be used.
Message exchange may be synchronous, where each peer waits for a response for each PDU being sent, or asynchronous, where multiple requests can be issued without waiting and acknowledged in a skew order by the other peer; the number of unacknowledged requests is called a window; for the best performance both communicating sides must be configured with the same window size.
Versions
The SMPP standard has evolved during the time. The most commonly used versions of SMPP are:- SMPP 3.3 the oldest used version ; supports GSM only. Generates an immediate response for each message sent.
- SMPP 3.4 adds optional tag–length–value parameters, support of non-GSM SMS technologies and the transceiver support. The exchange of SMPP request and response PDUs between an ESME Transmitter and SMSC may occur synchronously or asynchronously.
- SMPP 5.0 is the latest version of SMPP; adds support for cell broadcasting, smart flow control. it is not widely used.
PDU format (after version 3.4)
The SMPP PDUs are binary encoded for efficiency. They start with a header which may be followed by a body:PDU header
Each PDU starts with a header. The header consists of 4 fields, each of length of 4 octets:;
command_length: Is the overall length of the PDU in octets ; must be ≥ 16 as each PDU must contain the 16 octet header;
command_id: Identifies the SMPP operation. If the most significant bit is cleared, this is a request operation. Otherwise it is a response.;
command_status: Always has a value of 0 in requests; in responses it carries information about the result of the operation;
sequence_number: Is used to correlate requests and responses within an SMPP session; allows asynchronous communication All numeric fields in SMPP use the big endian order, which means that the first octet is the Most Significant Byte.
Example
This is an example of the binary encoding of a 60-octet submit_sm PDU. The data is shown in Hex octet values as a single dump and followed by a header and body break-down of that PDU.This is best compared with the definition of the submit_sm PDU from the SMPP specification in order to understand how the encoding matches the field by field definition.
The value break-downs are shown with decimal in parentheses and Hex values after that. Where you see one or several hex octets appended, this is because the given field size uses 1 or more octets encoding.
Again, reading the definition of the submit_sm PDU from the spec will make all this clearer.
PDU header
'command_length', ... 00 00 00 3C'command_id', ... 00 00 00 04
'command_status', ... 00 00 00 00
'sequence_number', ... 00 00 00 05
PDU body
'service_type', ... 00'source_addr_ton', ... 02
'source_addr_npi', ... 08
'source_addr', ... 35 35 35 00
'dest_addr_ton', ... 01
'dest_addr_npi', ... 01
'dest_addr', ... 35 35 35 35 35 35 35 35 35 00
'esm_class', ... 00
'protocol_id', ... 00
'priority_flag', ... 00
'schedule_delivery_time', ... 00
'validity_period', ... 00
'registered_delivery', ... 00
'replace_if_present_flag', ... 00
'data_coding', ... 03
'sm_default_msg_id', ... 00
'sm_length', ... 0F
'short_message', ... 48 65 6C 6C 6F 20 57 69 6B 69 70 65 64 69 61
Note that the text in the short_message field must match the data_coding. When the data_coding is 8, the text must be in UCS-2BE. When the data_coding indicates a 7-bit encoding, each septet is stored in a separate octet in the short_message field. SMPP 3.3 data_coding exactly copied TP-DCS values of GSM 03.38, which make it suitable only for GSM 7-bit default alphabet, UCS2 or binary messages; SMPP 3.4 introduced a new list of data_coding values:
data_coding | Meaning |
| 0 | SMSC Default Alphabet / MC Specific |
| 1 | IA5 /ASCII |
| 2 | Octet unspecified |
| 3 | Latin 1 |
| 4 | Octet unspecified |
| 5 | JIS |
| 6 | Cyrillic |
| 7 | Latin/Hebrew |
| 8 | UCS2 |
| 9 | Pictogram Encoding |
| 10 | ISO-2022-JP |
| 11 | Reserved |
| 12 | Reserved |
| 13 | Extended Kanji JIS |
| 14 | KS C 5601 |
| 15-191 | reserved |
| 192-207 | GSM MWI control - see GSM 03.38 |
| 208-223 | GSM MWI control - see GSM 03.38 |
| 224-239 | reserved |
| 240-255 | GSM message class control - see GSM 03.38 |
The meaning of the
data_coding=4 or 8 is the same as in SMPP 3.3. Other values in the range 1-15 are reserved in SMPP 3.3. Unfortunately, unlike SMPP 3.3, where data_coding=0 was unambiguously GSM 7-bit default alphabet, for SMPP 3.4 and higher the GSM 7-bit default alphabet is missing in this list, and data_coding=0 may differ for various Short message service centers—it may be ISO-8859-1, ASCII, GSM 7-bit default alphabet, UTF-8 or even configurable per ESME. When using data_coding=0, both sides must be sure they consider it the same encoding. Otherwise it is better not to use data_coding=0. It may be tricky to use the GSM 7-bit default alphabet, some Short message service centers requires data_coding=0, others e.g. data_coding=241.Quirks
Despite its wide acceptance, the SMPP has a number of problematic features:- No standardized
data_codingvalue for GSM default alphabet - No standardized meaning of
data_coding=0 - Unclear support for Shift-JIS encoding
- Incompatibility of
submit_sm_respbetween SMPP versions - Using of SMPP 3.3 SMSC Delivery Receipts, especially the Message Id format in them
No standardized data_coding value for GSM default alphabet
Althoughdata_coding value in SMPP 3.3 are based on the GSM 03.38, since SMPP 3.4 there is not a standardized data_coding value for the GSM default alphabet. It is further ambiguous whether the 7-bit characters are packed, as in GSM, allowing sending 160 characters in 140 octets, or whether each 7-bit character is encoded as an entire octet.No standardized meaning of data_coding=0
According to SMPP 3.4 and 5.0 the valuedata_coding=0 means ″SMSC Default Alphabet″. Which encoding it really is, depends on the type of the SMSC and its configuration.Unclear support for Shift-JIS encoding
One of the encodings in CDMA standard C.R1001 is Shift-JIS used for Japanese. SMPP 3.4 and 5.0 specifies three encodings for Japanese, but none of them is identical with CDMA MSG_ENCODING 00101. It seems that the Pictogram encoding is used to carry the messages in Shift-JIS in SMPP.Incompatibility of submit_sm_resp between SMPP versions
When a submit_sm fails, the SMSC returns asubmit_sm_resp with non-zero value of command_status and ″empty″ message_id.- SMPP 3.3 explicitly states about the
message_id field″If absent this field must contain a single NULL byte″. The length of the PDU is at least 17 octets. - SMPP 3.4 contains an unfortunate note in the
SUBMIT_SM_RESPsection ″Thesubmit_sm_respPDU Body is not returned if thecommand_statusfield contains a non-zero value.″ Then the length of the PDU is 16 octets. - SMPP 5.0 just specifies that
message_idis a mandatory parameter of the type C-Octet string of thesubmit_sm_respmessage. According to the section 3.1.1 NULL Settings, ″A NULL string ″″ is encoded as 0x00″. The length of the PDU is at least 17 octets.
submit_sm_resp regardless of the version of SMPP standard used for the communication.Message ID in SMPP 3.3 SMSC Delivery Receipts
The only way to pass delivery receipts in SMPP 3.3 is to put information in a text form to theshort_message field; however, the format of the text is described in Appendix B of SMPP 3.4, although SMPP 3.4 may use receipted_message_id and message_state TLVs for the purpose. While SMPP 3.3 states that Message ID is a C-Octet String of up to 8 characters, the SMPP 3.4 specification states that the id field in the Delivery Receipt Format is a C-Octet String of up to 10 characters. This splits SMPP implementations to 2 groups:- Implementations using the decimal representation of an integer Message Id in the id field of the Delivery Receipt body and the hexadecimal representation of an integer Message Id in
message_idandreceipted_message_idfields - Implementations using the same hexadecimal number both in
message_idparameter and in the id field of the Delivery Receipt body
receipted_message_id and message_state TLVs should be used to convey the outcome of a message.Extensibility, compatibility and interoperability
Since introduction of TLV parameters in version 3.4, the SMPP may be regarded an extensible protocol. In order to achieve the highest possible degree of compatibility and interoperability any implementation should apply the Internet robustness principle: ″Be conservative in what you send, be liberal in what you accept″. It should use a minimal set of features which are necessary to accomplish a task. And if the goal is communication and not quibbling, each implementation should overcome minor nonconformities with standard:- Respond with a
generic_nackwithcommand_status=3to any unrecognised SMPP command, but do not stop the communication. - Ignore any unrecognised, unexpected or unsupported TLV parameters.
- The borders of PDUs are always given by the PDUs'
command_lengthfield. Any message field must not exceed the end of PDU. If a field is not properly finished, it should be treated as truncated at the end of PDU, and it should not affect further PDUs.