Get the Best Information for Your Region by Switching to the Aeris India Site.

Based on your location, we recommend switching to the Aeris Europe website. There you will find information about Aeris' IoT connectivity services unique to your region.

Get the Best Information for Your Region by Switching to the Aeris Europe Site.

Based on your location, we recommend switching to the Aeris Europe website. There you will find information about Aeris' IoT connectivity services unique to your region.

You can always switch back by using the Switch Regions menu at the top of the website.


Using SMS for M2M Data—Best Practices


This week, I begin a series of posts on the best practices for M2M data transportsinterspersed periodically with other topics.

Text Messaging

Clearly, most people are knowledgeable about what text messaging is, so I will not spend much time on that.

Suffice it to say that the service and capability was developed for digital cellular technologies, to send and receive text (up to 160 printable characters) from one cellular handset to another. In a fire-and-forget way similar to e-mail!

First, a description of the issues and concerns with using standard text messaging services for M2M data.

Early Issues

In early digital cellular, text messaging was not reliable.

Delivery success rates were well below 75% to 85% for most Carriersparticular when roaming where the messages were not delivered at all in some markets.

If the recipient handset was on a different Carrier, it was very likely that it would never receive the text messages! Without any notification of the lack of success.

Even when successful, delivery times ranged from about 15 to 30 seconds, to many minutes and hours ... sometimes days after the text message was sent!

(We had one Customer that used to sent two duplicatesi.e., three successful transmissionswith another Carrier to ensure that at least one transmission would make it through, and even this was not a guarantee for success.)

Thus, text messaging developed a reputation for uncertainty that caused people to avoid using it for mission-critical M2M applications.


In the past few years, Carriers have improved their networks to better support text messaging services. Success rates have increased, and the delivery times have improved.

But, even today, delivery times have long tailswhere a number of messages take longer to be delivered than may be acceptable for some M2M Applications, although many messages do arrive promptly.

Combined with the increase in the number of consumer text messages sent, and the use of spam filters, message queues, and the lack of security (anybody can send a text message to a cellular handset), using standard text messaging services for M2M data can still be a concern.

My simplistic test as I wrote this post: sending five text messages from one handset to another (same nationwide cellular Carrier, same Market, [presumably] on the same set of nearby towers since the two CDMA handsets were sitting side-by-side, etc.) averaged 15 seconds. The shortest time was approximately 12 seconds and the longest was approximately 22 seconds.

Aeriss SMS Transport for M2M

Early in its digital cellular service deployments, we recognized the need for providing a highly-reliable, rapid SMS transport for M2M Applicationsboth Mobile-Originated SMS (MO-SMS) and Mobile-Terminated SMS (MT-SMS) data.

High-Performance Objectives

Careful performance objectives were set for the Aeris SMS transport servicesinitially called SMSDirectto meet the requirements for M2M Applications:

  • MT-SMS and MO-SMS delivery success rates well in excess of 95% (when measured with a delivery time of 12 seconds maximum to a radio that is powered on and ready to receive SMS).
  • Notification of delivery success when the MT-SMS was delivered to the radio.
  • Timely notification of delivery failures when the MT-SMS was not delivered.
  • Detailed information on the reasons for any delivery failures.
  • Allow 8-bit binary encoding of MO-SMS data, since that is a more natural fit for data gathered by controllers.
  • Customers can only send/receive SMS to/from their own Devices, without allowing others to access them.
  • Devices secured against external MT-SMS spam protected from receiving MT-SMS from unknown sources.

Aeris met its design objectives quite handily and provides an SMS transport service that is used today by mission-critical M2M Applications.

In the Aeris system, the vast majority of MO-SMS and MT-SMS packets are sent and received from the Device to the host systems in under 6 seconds, with outstanding success (when the radio is on and able to receive the SMS, of course!)

No Store-And-Forward By Design

Aeris designed its SMS Center (SMSC) systems to not use store-and-forward for SMS packetsthis is unlike the treatment accorded to consumer text messaging by Carriers.

Since the M2M Application transmission could be mission-critical, the SMS sent and received from the Devices must be transported rapidlywith very timely notification of delivery failures (for example, if the recipient Device is powered off).

Additionally, MT-SMS transmissions that initiate actions at the Device must not be delayed by a store-and-forward SMSC, since a late action may cause inadvertent problems when executed at an uncontrolled time in the future.

For example, a vehicle door unlock function that is delayed by many minutes or hours, or a security system enable that occurs many hours after it is wanted, can cause that M2M Application function to fail.

Best Practices for SMS in M2M

This section outlines practices that will maximize the benefits of using SMS for M2M data transportfor additional assistance, please contact Aeris Sales Engineering.

Use SMS For Short Content Transmissions

The capacity of each SMS transmission is 140 eight-bit bytes or 160 seven-bit characters. This is sufficient for many functions in M2M Applicationsstudies show that the majority of M2M messages are alert, notification, and location-based messages that average under 75 characters.

For these short transmissions, opening an IP session (i.e., using Packet-Radio services), transmitting the data to a server, and closing the session, is more inefficient than simply sending an SMS.

When transmitting from a moving vehicle, the MO-SMS transmission may also be sent with greater reliability than during a session-oriented TCP/IP connection to a server.

Consider Using Eight-bit Data In SMS

When using SMS transport services that allow eight-bit data (such as Aeriss SMS data transport service), encode and send the data using eight-bit fields if the data is gathered from sensors and controllers where this is a natural data size.

Using eight-bit data also allows application-level encryption to protect the information better than sending open text characters in an SMS message. This may be important for some applications where an action taken by a Device in the field requires additional protection to prevent accidental, or deliberate, invocation.

Send Content in MT-SMS Shoulder Taps

Often, an MT-SMS is used as a shoulder tap for the remote Device to initiate an IP Packet-Radio session.

For shoulder taps, it is useful to send information to the radio in the SMS fields to provide a better experience rather than simply sending an empty MT-SMS (since the length of the SMS does not change the cost) .

For example, consider sending Absolute Time (perhaps host time in seconds past midnight UTC) for the remote Device to make decisions about the time-validity of a command to take action.

Of course, remember to compensate for the [current] 15 second difference between Absolute Time UTC and CDMA timewhich is based on Global Positioning System (GPS) time and, hence, does not correct for leap-seconds. This is even more relevant if the Device has an on-board GPS system from which it receives time data.

It may be useful to send the URL for the radio to connect to, or IP port number to use, or the protocol (such whether the Device should open a TCP session or send data via a UDP packet or use an HTTP session).

Indeed, since the SMS capacity is 140 eight-bit bytes, or 160 seven-bit characters, all of the above content (including other content that is unique to the M2M Application) could be sent in a shoulder tap MT-SMS.

Set Multiple Transmission Timers Correctly

In most radio modules, the frequency of MO-SMS packets, or frequency of MT-SMS packets, is limited by the capabilities of the radio processor or the cellular processing in the radio after receiving the data.

In general, radios and handsets cannot receive messages too rapidly and the inter-message timingparticularly for MT-SMS packetsmust be carefully selected.

I.e., when sending multiple MT-SMS messages to the same Device, appropriate delays must be inserted between messages to avoid delivery failures. (The same is true for MO-SMS messages from the Device, but these errors can be immediately noted by controllers that can retry as needed.)

Although the Aeris AerFrame interface provides support for this (by rejecting requests that are made too quickly), this places an unnecessary burden on the interface, and the client and server. It is best to set these timers externally at the Customer host systems.

Empty the Radio SMS Buffers

In most radio modules, there is a finite buffer for the storage of received MT-SMS packets. If not emptied, these buffers can get full over time, preventing the radio from receiving more MT-SMS messagessometimes without any warnings or notifications(!)and confusing the program in the controller attached to the radios.

In some radios, receiving multiple MT-SMS messages without clearing the buffer can slow down the process of receiving new messages and can also slow down the process of retrieving these messages from the radio over the serial or USB port.

Thus, it is best if the external processor (that runs the M2M Application firmware) immediately clears the SMS buffers in the radios after retrieving the received MT-SMS packets.

Analyze the SMS Cause Codes

In the Aeris AerFrame interface, MT-SMS requests are sent by the Customer host systems using an XML/SOAP interface. After the message is delivered to the radio, an acknowledgement is sent to the host system.

If an MT-SMS delivery fails (for example, if the radio is turned off), the AerFrame interface returns an "SMS Cause Code" to the requesting system. This Cause Code provides significant and valuable detail for the reason for the failure.

The host system software for the M2M Application should analyze the returned Cause Code to make decisions about retries, etc. Currently, up to 25 Cause Codes are available, although not all occur with the same frequencysome are more common than others.

Simultaneous Voice and SMS

In ANSI-2000 CDMA cellular, an SMS transmission can be sent and received while a voice call is in progress. This allows the transmission of short MO-SMS data packets (and receipt of MT-SMS too) during a phone call.

M2M Applications should take advantage of this simultaneous transmission capability when possible.

For example, an Automotive Telematics application can update the car location, using an MT-SMS transmission containing GPS data, while a voice call to an operator or concierge service person is in progress! This could even be done on demand, by the operator sending an appropriately coded SMS transmission to the vehicle.

Just Use SMS!

The most important best practice advice is simply "Use SMS"!

Aeris's SMS transport system is a very practical and viable method for sending and receiving M2M data from Devices, and well-suited for transmissions where the size, reliability and relative low-latency, matches the needs of many M2M Applications.

The bottom line is that SMS is a completely viable data transport method for M2M Applications, including for mission-critical functions when provided by companies like Aeris that have optimized it for M2M.

Download our free whitepaper:

wireless ip for m2m best practices