Short Message Peer-to-Peer

Last updated

Short Message Peer-to-Peer (SMPP) in the telecommunications industry is an open, industry standard protocol designed to provide a flexible data communication interface for the transfer of short message [1] data between External Short Messaging Entities (ESMEs), Routing Entities (REs) and SMSC. [2]

Contents

SMPP is often used to allow third parties (e.g. value-added service providers like news organizations) 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 (used to deliver MMS notifications), USSD messages and others. Because of its versatility and support for non-GSM SMS protocols, like UMTS, IS-95 (CDMA), CDMA2000, ANSI-136 (TDMA) and iDEN, SMPP is the most commonly used protocol for short message exchange outside SS7 networks.

History

SMPP (Short Message Peer-to-Peer) was originally designed by Aldiscon, a small Irish company that was later acquired by Logica (since 2016, after a number of changes Mavenir). 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. [3]

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 (short message service) to the benefit of the global wireless industry will disband by July 27, 2007." [4] 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 (protocol data units, or packets) exchanged over OSI layer 4 (TCP session or X.25 SVC3) connections. [5] 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 (introduced in SMPP 3.4) allows message transfer in both directions. [6] 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:

The applicable version is passed in the interface_version parameter of a bind command.

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:

SMPP PDU
PDU Header (mandatory)PDU Body (Optional)
Command
length		Command
Id		Command
Status		Sequence
Number		PDU Body
4 octetsLength = (Command Length value - 4) octets

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 (including command_length field itself); must be ≥ 16 as each PDU must contain the 16 octet header
command_id
Identifies the SMPP operation (or command). 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 (using a sliding window method)

All numeric fields in SMPP use the big endian order, which means that the first octet is the Most Significant Byte (MSB).

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', (60) ... 00 00 00 3C 'command_id',      (4) ... 00 00 00 04 'command_status',  (0) ... 00 00 00 00 'sequence_number', (5) ... 00 00 00 05

PDU body

'service_type',                 () ... 00 'source_addr_ton',             (2) ... 02 'source_addr_npi',             (8) ... 08 'source_addr',               (555) ... 35 35 35 00 'dest_addr_ton',               (1) ... 01 'dest_addr_npi',               (1) ... 01 'dest_addr',           (555555555) ... 35 35 35 35 35 35 35 35 35 00 'esm_class',                   (0) ... 00 'protocol_id',                 (0) ... 00 'priority_flag',               (0) ... 00 'schedule_delivery_time',      (0) ... 00 'validity_period',             (0) ... 00 'registered_delivery',         (0) ... 00 'replace_if_present_flag',     (0) ... 00 'data_coding',                 (3) ... 03 'sm_default_msg_id',           (0) ... 00 'sm_length',                  (15) ... 0F 'short_message', (Hello Wikipedia) ... 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 (UCS2), the text must be in UCS-2BE (or its extension, UTF-16BE). When the data_coding indicates a 7-bit encoding, each septet is stored in a separate octet in the short_message field (with the most significant bit set to 0). 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_codingMeaning
0SMSC Default Alphabet (SMPP 3.4) / MC Specific (SMPP 5.0)
1IA5 (CCITT T.50)/ASCII (ANSI X3.4)
2Octet unspecified (8-bit binary)
3Latin 1 (ISO-8859-1)
4Octet unspecified (8-bit binary)
5JIS (X 0208-1990)
6Cyrillic (ISO-8859-5)
7Latin/Hebrew (ISO-8859-8)
8UCS2 (ISO/IEC-10646)
9Pictogram Encoding
10 ISO-2022-JP (Music Codes)
11Reserved
12Reserved
13Extended Kanji JIS (X 0212–1990)
14 KS C 5601
15-191reserved
192-207GSM MWI control - see GSM 03.38
208-223GSM MWI control - see GSM 03.38
224-239reserved
240-255GSM 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 (ESME and SMSC) 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 data_coding for GSM 7-bit default alphabet

Although data_coding value in SMPP 3.3 are based on the GSM 03.38, since SMPP 3.4 there is no data_coding value for GSM 7-bit alphabet (GSM 03.38). However, it is common for DCS=0 to indicate the GSM 7-bit alphabet, particularly for SMPP connections to SMSCs on GSM mobile networks. It is further ambiguous whether the 7-bit alphabet is packed, as in GSM, allowing sending 160 characters in 140 octets, or whether the each 7-bit character takes up an entire octet (with the high bit set to zero, as with ASCII).

Not standardized meaning of data_coding=0

According to SMPP 3.4 and 5.0 the data_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 (JIS, ISO-2022-JP and Extended Kanji JIS), but none of them is identical with CDMA MSG_ENCODING 00101. It seems that the Pictogram encoding (data_coding=9) 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 a submit_sm_resp with non-zero value of command_status and ″empty″ message_id.

For the best compatibility, any SMPP implementation should accept both variants of negative submit_sm_resp regardless of the version of SMPP standard used for the communication.

The original intention of error scenarios was that no body would be returned in the PDU response. This was the standard behavior exhibited on all Aldiscon/Logica SMSC and also in most of the other vendors. When SMPP 3.4 was being taken on by the WAP forum, several clarifications were requested on whether a body should be included with NACKed response and measures were taken to clarify this in several places in the specification including the submit_sm section and also in the bind_transceiver section. What should have been done was to add the clarification that we eventually added in V5.0.. that bodies are not supposed to be included in error responses. Some vendors have been very silly in their implementations including bodies on rejected bind_transmitter responses but not on bind_transceiver responses etc. The recommendation I would make to vendors.. as suggested above.. accept both variants. But its also wise to allow yourself issue NACKed submit_sm_resp and deliver_sm_resp PDUs with and without an empty body. In the case of these two PDUs, that empty body will look like a single NULL octet at the end of the stream. The reason you may need this ability to include what I call dummy bodies with NACKed requests is that the other side of the equation may be unable or unwilling to change their implementation to tolerate the missing body. (I worked on three versions of SMPP specification in Aldiscon/Logica and designed the ESME solution for Openmind Networks)

— Cormac Long [ This quote needs a citation ]

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 the short_message field; however, the format of the text is described in Appendix B of SMPP 3.4, although SMPP 3.4 may (and should) use receipted_message_id and message_state TLVs for the purpose. While SMPP 3.3 states that Message ID is a C-Octet String (Hex) of up to 8 characters (plus terminating '\0'), the SMPP 3.4 specification states that the id field in the Delivery Receipt Format is a C-Octet String (Decimal) of up to 10 characters. This splits SMPP implementations to 2 groups:

The SMPP 3.4 specification does however state that the delivery receipt format is SMSC vendor specific, and therefore the format included in the specification is merely one possibility. As noted above, when using SMPP 3.4 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:

Information applicable to one version of SMPP can often be found in another version of SMPP, for example with the case of SMPP 3.4 describing the only mechanism of delivery receipts in SMPP 3.3 described above.

Security

The SMPP protocol is designed on a clear-text binary protocol which needs to be considered if using for potentially sensitive information such as one-time passwords via SMS. There are, however, implementations of SMPP over SSL/TLS if required. [7]

See also

Related Research Articles

<span class="mw-page-title-main">General Packet Radio Service</span> Packet oriented mobile data service on 2G and 3G

General Packet Radio Service (GPRS), also called 2.5G, is a packet oriented mobile data standard on the 2G cellular communication network's global system for mobile communications (GSM). GPRS was established by European Telecommunications Standards Institute (ETSI) in response to the earlier CDPD and i-mode packet-switched cellular technologies. It is now maintained by the 3rd Generation Partnership Project (3GPP).

<span class="mw-page-title-main">SMS</span> Text messaging service component

Short Message/Messaging Service, commonly abbreviated as SMS, is a text messaging service component of most telephone, Internet and mobile device systems. It uses standardized communication protocols that let mobile devices exchange short text messages. An intermediary service can facilitate a text-to-voice conversion to be sent to landlines.

Abstract Syntax Notation One (ASN.1) is a standard interface description language (IDL) for defining data structures that can be serialized and deserialized in a cross-platform way. It is broadly used in telecommunications and computer networking, and especially in cryptography.

External Machine Interface (EMI), an extension to Universal Computer Protocol (UCP), is a protocol primarily used to connect to short message service centres (SMSCs) for mobile telephones. The protocol was developed by CMG Wireless Data Solutions, now part of Mavenir.

Computer Interface to Message Distribution (CIMD) is a proprietary short message service centre protocol developed by Nokia for their SMSC.

Modbus or MODBUS is a client/server data communications protocol in the application layer. It was originally published by Modicon in 1979 for use with its programmable logic controllers (PLCs). Modbus has become a de facto standard communication protocol for communication between industrial electronic devices in a wide range of buses and network.

External Short Messaging Entity (ESME) is an external application that connects to a Short Message Service Center (SMSC) to engage in the sending or receiving of SMS messages. The term was coined by Aldiscon.

<span class="mw-page-title-main">Unstructured Supplementary Service Data</span> Communications protocol

Unstructured Supplementary Service Data (USSD), sometimes referred to as "quick codes" or "feature codes", is a communications protocol used by GSM cellular telephones to communicate with the mobile network operator's computers. USSD can be used for WAP browsing, prepaid callback service, mobile-money services, location-based content services, menu-based information services, and as part of configuring the phone on the network. The service does not require a messaging app, and does not incur charges.

GSM services are a standard collection of applications and features available over the Global System for Mobile Communications (GSM) to mobile phone subscribers all over the world. The GSM standards are defined by the 3GPP collaboration and implemented in hardware and software by equipment manufacturers and mobile phone operators. The common standard makes it possible to use the same phones with different companies' services, or even roam into different countries. GSM is the world's most dominant mobile phone standard.

A Short Message Service Center (SMSC) is a network element in the mobile telephone network. Its purpose is to store, forward, convert and deliver Short Message Service (SMS) messages.

<span class="mw-page-title-main">Push Proxy Gateway</span>

A Push Proxy Gateway is a component of WAP Gateways that pushes URL notifications to mobile handsets. Notifications typically include MMS, email, IM, ringtone downloads, and new device firmware notifications. Most notifications will have an audible alert to the user of the device. The notification will typically be a text string with a URL link. Note that only a notification is pushed to the device; the device must do something with the notification in order to download or view the content associated with it.

Mobile marketing is a multi-channel online marketing technique focused at reaching a specific audience on their smartphones, feature phones, tablets, or any other related devices through websites, e-mail, SMS and MMS, social media, or mobile applications. Mobile marketing can provide customers with time and location sensitive, personalized information that promotes goods, services, appointment reminders and ideas. In a more theoretical manner, academic Andreas Kaplan defines mobile marketing as "any marketing activity conducted through a ubiquitous network to which consumers are constantly connected using a personal mobile device".

An SMS gateway or MMS gateway allows a computer to send or receive text messages in the form of Short Message Service (SMS) or Multimedia Messaging Service (MMS) transmissions between local and/or international telecommunications networks. In most cases, SMS and MMS are eventually routed to a mobile phone through a wireless carrier. SMS gateways are commonly used as a method for person-to-person to device-to-person communications. Many SMS gateways support content and media conversions from email, push, voice, and other formats.

Aldiscon Limited was a telecommunications software company founded in Dublin, Ireland, in 1988. The company supplied software products to mobile phone operators and became a leader in the supply of short message service centres (SMSC).

The Short Message Service is realised by the use of the Mobile Application Part (MAP) of the SS7 protocol, with Short Message protocol elements being transported across the network as fields within the MAP messages. These MAP messages may be transported using "traditional" TDM based signalling, or over IP using SIGTRAN and an appropriate adaptation layer.

In the cellular phone industry, mobile phones and their networks sometimes support concatenated short message service to overcome the limitation on the number of characters that can be sent in a single SMS text message transmission. Using this method, long messages are split into smaller messages by the sending device and recombined at the receiving end. Each message is then billed separately. When the feature works properly, it is nearly transparent to the user, appearing as a single long text message. Previously, due to incompatibilities between providers and lack of support in some phone models, there was not widespread use of this feature.

In mobile telephony GSM 03.38 or 3GPP 23.038 is a character encoding used in GSM networks for SMS, CB and USSD. The 3GPP TS 23.038 standard defines GSM 7-bit default alphabet which is mandatory for GSM handsets and network elements, but the character set is suitable only for English and a number of Western-European languages. Languages such as Chinese, Korean or Japanese must be transferred using the 16-bit UCS-2 character encoding. A limited number of languages, like Portuguese, Spanish, Turkish and a number of languages used in India written with a Brahmic scripts may use 7-bit encoding with national language shift table defined in 3GPP 23.038. For binary messages, 8-bit encoding is used.

User Data Header (UDH) is a binary structure which may be present at the start of a short message in the Short Message Service in GSM. It does not contain any text, but it specifies how the message should be formatted and processed.

GSM 03.40 or 3GPP TS 23.040 is a mobile telephony standard describing the format of the Transfer Protocol Data Units (TPDU) of the Short Message Transfer Protocol (SM-TP) used in the GSM networks to carry Short Messages. This format is used throughout the whole transfer of the message in the GSM mobile network. In contrast, application servers use different protocols, like Short Message Peer-to-Peer or Universal Computer Protocol, to exchange messages between them and the Short Message Service Center (SMSC).

Data Coding Scheme is a one-octet field in Short Messages (SM) and Cell Broadcast Messages (CB) which carries a basic information how the recipient handset should process the received message. The information includes:

References

  1. ↑ "GSM 03.40 Technical realization of the Short Message Service (SMS)", 3GPP, 2003-12-03
  2. ↑ "Short Message Peer-to-Peer Protocol Specification v5.0" (PDF).
  3. ↑ Friedhelm Hillebrand (2010). Short Message Service (SMS): The Creation of Personal Global Text Messaging. Wiley. p. 112. ISBN   978-0-470-68865-6.
  4. ↑ "SMS Forum Homepage". smsforum.net. Archived from the original on 2007-12-22.
  5. ↑ Neil Croft (2012). "On forensics: A silent SMS attack". 2012 Information Security for South Africa. IEEE. pp. 1–4. doi:10.1109/ISSA.2012.6320454. ISBN   978-1-4673-2159-4. ISSN   2330-9881. S2CID   13448347.
  6. ↑ A. Henry-Labordère; Vincent Jonack (2004). SMS and MMS Interworking in Mobile Networks. Artech House. pp. 137–138. ISBN   1-58053-890-8.
  7. ↑ "Secure Short Message Peer-to-Peer Protocol", International Journal of Electronic Commerce Studies, 2012
This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.