IT Research BYTE
© Copyright Ford Motor Company
Analysis
How SMS Works
As a component of the mobile communications system, SMS was designed to deliver short text messages between mobile devices. It uses a very thin slice of the cellular network to transmit and receive messages.
In very simplistic terms, SMS is similar to a stripped-down version of e-mail. Instead of using the Internet (as with e-mail), SMS uses the cellular network to deliver very short messages to a designated number. Network carriers like AT&T, Verizon, Sprint, and T-Mobile build these networks and manage the flow of SMS traffic. SMS employs a store-and-forward service to deliver messages to mobile devices. It also works even when the recipient device is turned off3.
Figure 2 – A typical message flow between mobile subscribers and content providers. Source: Author; Data acquired from interactions with vendors. Images acquired from sxc.hu
SMS and American Idol
As mentioned in the introduction, SMS was originally designed for person-to-person communication. However, the advent of SMS Gateways and shortcodes
enabled non-mobile devices to send and receive text-messages. This paved the way for application-to-person messaging and the converse. Examples of this type of messaging include text delivery of emergency alerts, banking transactions, and SMS voting systems like in the popular show American Idol.
Figure 2 illustrates a high-level account of person-to-application messaging using SMS. As depicted in the figure, several entities play key roles in the delivery and processing of SMS to make it an effective application platform.
IT Research BYTE
Bringing SMS into FordThere are a variety of opportunities within Ford to incorporate text messaging with business processes in the B2E and B2C space. A good example is to integrate SMS notifications with several Ford customer-facing applications. In its simplest form, integrating SMS with a backend system only requires setting up an SMS Gateway and a properly provisioned shortcode.
With the introduction of SMS Aggregators (service providers), the overhead of standing-up SMS Gateways and provisioning shortcodes has moved up to the cloud. SMS Aggregators provide enterprises with the ability to send and receive text messages through simple interfaces like HTTP and Web Service calls. This architecture is depicted in Figure 3.
Figure 3 – Key requirements for standing-up an SMS application within Ford. Source: Author; Data acquired from findings on SMS Aggregators. Key Requirements
Assuming the SMS Gateway and shortcode are provided through an Aggregator, the remaining effort required to stand-up an SMS Application revolves around
buildinglogic to handle the sending and receiving of text-messages which complies with the guidelines of the Mobile Marketing Association4. In fact, conforming to MMA guidelines in addition to processing text-messages using the aggregator’s Application Programming Interface (API) constitutes the core of an SMS application.
On the architecture side, this requires building communication channels between Ford and the SMS Aggregator. In other words, Ford will need properly defined systems in place to handle Mobile Terminating (MT) and Mobile Originating (MO) traffic (see diagram).
For security purposes, the SMS Aggregator will require that the MO and MT systems be identified prior to development. The Aggregator will need this to implement the necessary firewall rules on its premise. In practice, the MO and MT systems are often deployed from separate servers. As long as these systems conform to the aggregator’s API, building SMS applications is analogous to processing HTML forms5.
Auxiliary Information Other Factors to Consider when Building and Deploying SMS Applications
Value-Driven Applications
Unlike client-server or web-based applications, SMS applications are very unique because they are highly constrained and purely text-based. SMS interaction is very limited. Moreover, the information presented is very limited (160 for 7-bit ASCII, 140 for 8-bit ASCII, and 70 for Unicode). These constraints should be kept in mind when developing and deploying SMS applications.
Pricing Models
The pricing models for deploying SMS applications via SMS Aggregators vary per vendor, but they all follow a common framework:
1. Set-up fee for Shortcode registration - standard and mandatory across all vendors. Fees vary depending on the use of random or “vanity” shortcodes (i.e. 4SYNC – 47962, FORD – 3673). Setup-fee and registration range from $500 to $1500. 2. Monthly subscription fees – subscription fees cover licensing costs for the SMS Gateway, and monthly fees for shortcode provisioning and maintenance. Subscription fees range from $500 to approximately $2,000 per month.
3. Per-Message Monthly Fees - per-message fees for incoming and outgoing messages. Incoming and outgoing messages are charged with slightly different rates. Vendors also provide discounted rates for large volume messages. Per-message fees range from a fraction of a cent to 3 cents.
There is also a different pricing model for providing premium SMS services such as purchasing content or services that bill directly from the user's cellular
IT Research BYTE
© Copyright Ford Motor Company
There are also other factors to consider when building and deploying SMS applications. Read the auxiliary information on the sidebar to learn more.
The Challenges in the Rise of Demand Ad Hoc Approach: Isolated SMS Applications
As mentioned, SMS Aggregators assuage the effort of building and deploying SMS applications. However, consider what happens when several entities within Ford start deploying SMS applications sporadically using different shortcodes and SMS aggregators. All of a sudden, fees start to pile up and unused message bins are thrown away (see Auxiliary Information on previous page for pricing models). Moreover, each entity is responsible for managing and maintaining its own SMS application. There is an opportunity here for IT professionals to take a systems engineering approach and create an effective and efficient service.
Alternative Solution: A Planned and Managed SMS Service
A better alternative to tackle this dilemma is to build a Managed SMS Service to consolidate and manage isolated SMS applications into using one service. A managed service eliminates the redundancy of multiple aggregators and shortcodes. It also benefits from economies of scale since text-messages are charged from a single account, therefore reducing licensing costs.
One challenge with this approach involves creating an internal Ford API for entities to tap into the SMS service. The keyword definitions and endpoints should be clearly defined for each business entity in order to avoid overlaps. This approach will also require an operations engineering group to manage and oversee SMS applications.
The benefits and challenges of each approach are summarized below.
Table 1: Benefits and Challenges for Isolated SMS Applications
Ad Hoc SMS Applications
Benefits Challenges
Fast and easy to setup Inefficient in terms of pricing and technical implementation
Can be very flexible Cannot benefit from economies of scale Requires managing separate accounts for
each application or business entity Table 2: Benefits and Challenges for a Centralized SMS Service
Managed SMS Service
Benefits Challenges
Efficient way to manage several SMS applications
Some overhead technical requirements involved
Reduces costs Will need a method to bill and track business entities who subscribe to the service Eliminates redundancy of multiple
Aggregators and shortcodes
Auxiliary Information Other Factors to Consider when Building and Deploying SMS Applications (continued)
Local vs. International Deployment
It is important to note that there are certain differences between deploying SMS applications for local and international mobile subscribers. For instance, a completely different shortcode and registration process is required for international countries, including Canada. Monthly subscription and per-message fees also vary for international deployment. However, the infrastructure and application implementation remain the same. Moreover, the character limits are different for international deployment. Countries using 7-bist ASCII encoding have a 160-character limit (e.g. US). Countries using 8-bit ASCII encoding have a 140-character limit, while those using Unicode encoding have a 70-character limit.
Legal Requirements
Every SMS application needs to conform to certain legal requirements imposed by the Mobile Marketing Association (MMA). Complying with MMA standards is as important as the technical solution for the SMS application. These guidelines are established to prevent abuse and to ensure the consumer’s best interest. For example, every SMS application should support the “HELP” keyword and should provide the option to allow any user to “STOP” or “opt-out” of the service. To learn more about these guidelines, see end-note [4].
IT Research BYTE
Recommendations
In order for Ford IT to successfully integrate text-messaging into its internal and customer facing applications, it will need to assess its current implementation of SMS. In the long run, it is more beneficial to consolidate isolated SMS applications into a managed SMS service. Aside from the benefits of a unified infrastructure, a managed service eliminates the redundancy of multiple aggregators and shortcodes while reducing costs.
Identify which Services are “One Way” or “Two Way”
It is also important to draw distinctions between two general types of SMS applications: One Way and Two Way (see Auxiliary Information). Once these distinctions are drawn, Ford IT can assess whether or not it will require one, two, or multiple shortcodes for a given function or application. For example, one-way SMS applications such as alert notifications do not require user interaction (except for giving the user an option to "opt-in" and "opt-out" of the service). In this case, the end-user is indifferent about the originating shortcode as long as the information is valuable to them. On the other hand, mobile subscribers will demand user-friendly shortcodes and keywords for two-way SMS applications.
Treat SMS Applications like any Solution Delivery Project
Despite being purely text-based with limited user-interaction, the immediacy and pervasiveness of SMS makes it a very valuable application service. Therefore, when building SMS applications they should begin with proper technical design considerations and then follow solution delivery methodologies.
Consider Possible Overlap with IM and Email
Sagacious decision-makers don’t use technology for technology’s sake. Therefore, evaluate the value of SMS over other messaging options such as IM and e-mail. The pervading force of Mobile Internet has given rise to promising technologies such as mobile IM, mobile e-mail, and mobile web6. When building an application, always consider what makes SMS unique. For example, applications that require a short and immediate response outside of the user’s workstation will benefit more with SMS. On the other hand, a multi-page status update application may be more valuable if delivered through e-mail.
Bottom Line
Today, every mobile phone can send and receive SMS. The simplicity, immediacy, and reach of SMS are the pith to its wide adoption. With the advent of SMS Aggregators, it takes little effort for enterprises to setup ad-hoc
SMS applications. However, serious challenges begin to surface if these isolated systems increase sporadically within the enterprise. Scaling SMS applications into a centralized service is more beneficial in the long term, but is not a walk in the park. Ford IT will need to asses how it currently manages SMS applications, and will need to provide an efficient solution as the demand rises.
Auxiliary Information Other Factors to Consider when Building and Deploying SMS Applications (continued)
One Way vs. Two Way Applications
It is important to draw distinctions between two types of SMS applications: one-way and two-way. One-way applications function mainly as notification channels for alerts. Two-way applications, on the other hand, are primarily user-driven and information is delivered based on certain keywords given by the user. When building SMS applications, these distinctions should be kept in mind.
IT Research BYTE
© Copyright Ford Motor Company
Where to Learn More
• Internal Ford Document
• "Mobile Application Architectures"
James Kobielus, Burton Group. 2001
• Reverse SMS Billing
<http://en.wikipedia.org/wiki/Reverse_SMS_billing>
• SYNC FAQs – How Can I Stop Receiving Text Messages?
<http://www.syncmyride.com/Own/Modules/FaqManagement/FaqDetail.aspx ?faqId=460>
Endnotes
1
"Text Message Statistics", CellSigns.com. Nov 2009
2
R. Murphey, "U.S. Wireless SMS, IM and MMS Messaging in 2009 – 2013 Forecast: Unlimited Pricing Plans Propel Market Forward," IDC. 2009
3 "Store and Forward", Wikipedia. 2009
<http://en.wikipedia.org/wiki/Store_and_forward>
4 "Mobile Consumer Best Practices and Guidelines," Mobile Marketing
Association. 2010
<http://www.mmaglobal.com/bestpractices.pdf>
5 "Syniverse MES: SMS Gateway Web Services Interface & SMS Gateway HTTP
Interface," Syniverse Technologies. 2009
6
Phillip Redman, Sandy Shen, et al. "Hype Cycle for Wireless Devices, Software and Services, 2009," Gartner Research. July 2009
Reviewed by Internal Ford Peer Review
