Short Message Peer To Peer Protocol (SMPP)

Symlabs Identity Management and Virtual Directory Blog

U.S. Company Products Services Solutions

+1 (312) 214 3570

| E.U Videos

+34 (91) 320-5524

Support

Training

Contact Us

Virtual Directory Server LDAP Proxy Federated Identity Suite Free LDAP Browser

Schedule a product DEMO

Short Message Peer To Peer Protocol (SMPP)

Quick Links Company Overview About Symlabs Management Team Clients Press Releases White Papers Strategic Partners Careers Become a Reseller Contact Us WebEx Demo Request Privacy Policy Standard Terms and Conditions Contact Us Click here to contact a Symlabs representative. Author: Sampo Kellomki Download White Paper as PDF

Short Message Peer to Peer Protocol (SMPP)

Symlabs Messaging White Paper Series
Sampo Kellomki

1 Introduction
This white paper series explores solving complex messaging problems using Symlabs Virtual Directory Server and its multi-protocol proxy features. Some uses are: Translate from one messaging protocol to another, e.g. SMPP to MM7 HTTP to telco messaging protocol gateway Virus scan the content of the messages Apply content filtering to the messages Increase SMSC or MMSC performance by connection aggregation Route messages (SMS router or MMS router) Handle or translate vendor extensions Messaging as web service or SOA component Application layer firewall for messaging: Keep SMSC or MMSC at arms length from 3rd parties Protection against illegal protocol requests Protection against Denial of Service (DoS) and flooding attacks Implement additional or custom audit or billing An operator reaps several benefits from using the Symlabs solution: Evolve existing infrastructure with point solutions that solve the observed inadequacies Prolong the useful life of, and protect investment in, existing messaging infrastructure

http://symlabs.com/wpaper/4[2/7/2011 3:09:21 PM]

Short Message Peer To Peer Protocol (SMPP) Avoid customizing SMSC or MMSC software packages; reduce maintenance and support cost Improve scalability for an existing infrastructure, avoid investment in new SMSC and MMSC licenses and maintenance contracts. The white papers in this series are: SMPP (SMS) (this white paper) MM1 and MM7 (MMS) Multiprotocol Messaging Gateway Scanning, Filtering, Firewalling, Auditing and Billing

1.1 Glossary
SLA Service Level Agreement. A contract that guarantees performance or throughput of a service. Usually SLA is associated with guaranteed minimum service at given price point. SMPP Short Message Peer to Peer protocol. A standard for sending and receiving SMS messages. SMS Short Message Service. A highly popular service for sending over a mobile network text messages of up to 160 characters. In some cases longer messages can be sent using chaining allowing SMS to be used for ring tone and wall paper delivery. An operator can also use SMS for Over-the-Air configuration messages. SME Short Message Entity. Usually the handset connected by the mobile network to the SMSC. ESME External Short Message Entity. A SMPP client. May run on WAP Proxy or similar, or may be a genuine external 3rd party wanting to send (and receive) messages. ESME generally is not handset, see SME. SMSC Short Message Service Center. A SMPP server. Usually synonymous with MC, RE, USSD, or CBC. MC Message Center. The SMPPv5.0 name for SMSC. RE Routing Entity. Synonymous with a SMSC that can also act as an ESME. See [SMPP50] section 2.4. MC/RE Portmanteau of MC and RE meaning SMSC. USSD Unstructured Supplementary Services Data. Synonymous with SMSC. CBC Cell Broadcast Center. Synonymous with SMSC. MMS Mobile Multimedia Service. Similar to SMS but allows sending photos and other media.

http://symlabs.com/wpaper/4[2/7/2011 3:09:21 PM]

Short Message Peer To Peer Protocol (SMPP)

MMSC Mobile Multimedia Service Center. The MMS equivalent of a SMSC, i.e. a MMS server. VDS Virtual Directory Server. Used here specifically to mean Symlabs Virtual Directory Server with multiprotocol capabilities. VAS Value Added Service. Sometimes called a Service Provider. Usually a third party providing paid services to the mobile users. A VAS usually plays the ESME role to send and receive messages.

1.2 SMPP Architecture

The SMPP architecture consists of handsets, called SMEs, connected to SMSC servers by protocols specific to the mobile network. The SMSC server is analogous to a mail server and is used for both sending and receiving SMS messages. If the message is destined to another operator's network, the SMSC will contact the other operator's SMSC, which will then deliver the message to the handset in the other network. When contacting the other SMSC, the first SMSC actually acts in the ESME role, although this is usually not depicted. The bulk of the ESMEs are 3rd party (value added) services that wish to send and receive SMS messages. At high level they are clients just like handsets, but in practical terms they are different because they are on an IP network and use SMPP to communicate to the SMSC.

Fig-1: SMPP architecture and roles

While this is the general outline of the architecture, creative architects have found many other more or less exotic ways to employ SMPP - after all it is just a protocol and if you speak it correctly, it will work even when used in an unorthodox way. Finally, SMPP has some historical baggage: there are several versions. While 3.4 is the most prevalent as of late 2008 (more modern than version 4.0 of the protocol), version 5.0 seems to be officially most recent since 2003-02-19 (according to smsforum.net). Some sites still use version 3.3 of the protocol. SMPP v3.4 makes a provision for vendor extensions which, while adding flexibility, have not been conducive to interoperability. The current (late 2008) state of the art tends to be that products

http://symlabs.com/wpaper/4[2/7/2011 3:09:21 PM]

Short Message Peer To Peer Protocol (SMPP) from different vendors seldom interoperate out-of-the-box, but with proper expertise can usually be configured to interoperate.

2 SMPP Connection Aggregation

SMPP protocol runs over TCP. In early deployments the TCP connection was kept open for long time, exchanging several (thousand) messages over the same connection. However, some ESMEs follow a different pattern: they open a new connection for every message they need to send. This can create scalability problems for SMSCs that were not engineered with this usage in mind. [SMPP50] section 2.6.5 "Why Asynchronous" provides a good treatment of this topic. The Symlabs solution is connection aggregation. VDS listens for and accepts a large volume of shortlived connections from the ESMEs, but keeps one persistent connection (or a few, if needed) towards the SMSC, thus eliminating the bottleneck.

(a) Problem

(b) Solution
Fig-2: Symlabs VDS solves scalability problem due to massive number of connections from 3rd party partners by aggregating multiple ESME connections to one connection to SMSC.

The solution is also applicable to situation where there are too many connections to the SMSC simply because there are too many ESMEs (i.e., there would be too many connections even if every ESME used persistent connection). This situation cannot be solved by reconfiguring or fixing ESMEs: it can only be solved by fixing the SMSC or by deploying a front-end like VDS to handle the connections. Interposing VDS enables additional functionality, such as prioritizing traffic from ESMEs according to

http://symlabs.com/wpaper/4[2/7/2011 3:09:21 PM]

Short Message Peer To Peer Protocol (SMPP) SLAs, auditing traffic from ESMEs, or implementing custom billing on a per ESME and message content basis. The additional audit logs provide a valuable way to verify that the primary billing records are correct. Even more so as the audit logs from VDS are closer to the ESME, thus helping to validate ESME claims when the SMSC does not provide adequate detail. The VDS layer can also accommodate ESMEs that speak different version or dialect of SMPP and translate to the dialect spoken by the SMSC. This is especially important if the SMSC is encumbered by vendor extensions. VDS can map the incoming request to the dialect understood by the SMSC and supply the needed vendor extensions. The inverse translation can be performed when receiving messages (from handset to ESME). Finally, the VDS layer can translate between protocols: a message may be received using HTTP form submission, a web services call, or MM7 protocol, and translated to SMPP that will be understood by the SMSC. This feature allows consolidation of messaging platforms, reducing ongoing cost.

3 SMPP Router
3.1 Routing at the ESME Side
By deploying VDS as a proxy, it is possible to implement routing based on a phone number or message content. Consider a situation where the ESME usually uses Operator A for sending the messages, but Operator A's price for messages to Operator B is very expensive (or perhaps there is no agreement between A and B so sending messages to B's customers directly from A is simply impossible).

(a) Problem

http://symlabs.com/wpaper/4[2/7/2011 3:09:21 PM]

Short Message Peer To Peer Protocol (SMPP)

(b) Solution
Fig-3: ESME routing problem - choice of wrong SMSC costs more to the ESME

Here the Symlabs solution allows a 3rd party to inspect the phone number field of the message and send it directly to Operator B's SMSC, thus avoiding the problem. The routing decision could just as well be based on content of a message (e.g., if Operator A does not allow certain types of content to pass through its network), or dynamic load balancing and fail-over considerations. In fact anything you can write a business rule for in Symlabs VDS's scripting language can be used as the basis for routing.

3.2 Routing at the Operator Side

An operator may want routing capability beyond what is offered by a SMSC product. Or the operator may want to avoid implementing routing logic in a SMSC due to high cost of such a solution. Consider following situation where Operator wishes to encourage non-paying 3rd party partners to pay by redirecting their traffic to another ESME. The ESME1 has not paid and is therefore entered to the debt database. Most SMSC implementations can not consult such database, or would require expensive customization to do so.

http://symlabs.com/wpaper/4[2/7/2011 3:09:21 PM]

Short Message Peer To Peer Protocol (SMPP)

(a) Problem

(b) Solution
Fig-4: Operator routing problem - redirect traffic of a temporarily banned ESME .

The Symlabs solution allows the operator to implement this database lookup (with full generality of Symlabs VDS technology) and route or filter the infringing 3rd party's traffic.

http://symlabs.com/wpaper/4[2/7/2011 3:09:21 PM]

Short Message Peer To Peer Protocol (SMPP)

4 About the Symlabs Solution

4.1 Stability and Performance
Symlabs messaging solutions are based on the proven technology of Symlabs Virtual Directory Server, capable of throughput measured in tens of thousands of operations per second on single server (2 CPU blade). Symlabs has solutions for full load balancing and fail over that provide carrier grade scalability and, combined with Symlabs 24x7 support, five nines (99.999%) uptime.

4.2 Standards
Symlabs VDS supports the following messaging related protocols and standards1 as a client, server, or proxy. SMPP v3.3, v3.4, v4.0, v5.0 MM1 MM7 ID-MM7 (Liberty enabled MM7) Ad-hoc HTTP forms based interfaces Ad-hoc SOAP based interfaces

4.3 Customization
Professional Services are also available from Symlabs, should you need further customization or support for additional messaging protocols. All customizations performed by Symlabs PS can be added to support contract coverage.

4.4 Inquiries
Please direct all inquiries to Sales at Symlabs.
1 For

other protocol and standards support, see the Symlabs Virtual Directory Server data sheet.

5 Copyright and Permission to Distribute

Copyright (c) 2008-2009 Symlabs, Inc. All Rights Reserved. Target audience: engineers and technical decision makers with background understanding of telco messaging systems. Royalty free and paid-up permission is granted to: 1. distribute and publish verbatim copies with all copyright and proprietary notices intact; and 2. translate to other languages or media provided that such translation is either approved by Symlabs or states that it is an unofficial translation. For any other use, please contact Symlabs (jeff@symlabs.com) for permission. This permission to distribute and translate this document does not grant license to the technologies, techniques, or products described herein. Symlabs does not provide warranty or guarantee of any kind, not even against infringement or violation of any intellectual property rights. In no event shall Symlabs be liable for any effect caused by use of or failure to use any information described herein, even if advised of the possibility of such an effect. Symlabs reserves right to change this document and the specifications of any products described herein without notice.

References
[SMPP50] SMS Forum: "Short Message Peer-to-Peer Protocol Specification, Version 5.0", 20030219 SMS Forum, smpp50.pdf, www.smppforum.net

http://symlabs.com/wpaper/4[2/7/2011 3:09:21 PM]

Short Message Peer To Peer Protocol (SMPP)

About Symlabs Symlabs is the performance leader for virtual directory and identity management solutions. Benchmarks show Symlabs Virtual Directory Server, LDAP Proxy and Federated Identity Suite are the fastest and most powerful products in the industry for managing and unifying identity data. Global giants like Sony, IBM, Vodafone, Nokia and United Nations already depend on Symlabs to add flexibility, security, and reliability to their infrastructure. Symlabs also offers annual support, training and professional services to our clients to help them develop, integrate, and maintain solutions.

Site Map

Copyright 2011 Symlabs, Inc.

http://symlabs.com/wpaper/4[2/7/2011 3:09:21 PM]