Wireless IP for M2M Data—Best Practices (Part 1)
This week, I continue a series of posts on the best practices for M2M data transports (the previous post in this series was on SMS Data)—interspersed periodically with other topics.
Short Data Packets
Aeris’s original control channel MicroBurst® data transport was limited to 23 decimal digits (approximately 84 bits) of M2M Application data per packet transmission.
Today, SMS is limited to 140 eight-bit bytes (or 160 characters of seven-bits) of M2M Application data in every message packet transmission, in both GSM and CDMA cellular technologies.
While such short data packets are completely sufficient for many M2M Application data purposes, they may be limited for some use cases.
For example, after an alarm Device sends an SMS for a security event, it may need to open a video feed for alarm verification. Even if this is a slow frame-rate, black-and-white, and low-resolution video transmission, it may be too much data for SMS and needs another transport.
Wireless Internet Protocol (“IP”) data transports are used when the amount of data to be sent per “event” is larger than an SMS message can contain.
In 2G GSM and CDMA cellular, the IP data transport technologies are “GPRS” and “1xRTT”. While these have slow data throughput rates compared to 3G and 4G cellular, they are quite sufficient for the IP transmission needs for most M2M Applications.
(Of course, readers of my blog know that 2G GSM and GPRS services are being shut down soon, so CDMA 1xRTT is the only current option for new M2M Devices.)
For higher transmission rate M2M Applications, devices can use 3G CDMA and GSM protocols, such as EV-DO and HSPA. Today, HSPA geographic coverage in the US does not match the EV-DO coverage.
EV-DO and HSPA radio modules are more expensive than GPRS and 1xRTT Modules, so they are only used when the higher transmission rates are required for a particular M2M Application.
Best Practices for Wireless IP in M2M
This section outlines practices that will maximize the benefits of using Wireless IP for M2M data transport—for detailed assistance, please contact Aeris Sales Engineering.
Wireless IP is Not the Same as Wired IP
First, it is important to recognize that Wireless IP data technologies are not really the same as Wired IP technologies.
A recent generation of software developers, who are used to working with DSL, Fiber and Cable IP services (along with Local Area IP Networks), have begun working on Wireless IP Devices. They sometimes attempt to apply Wired IP learnings and practices to Wireless IP implementations, and often go unexpectedly awry.
The typical issues these developers encounter are described in more detail in this post.
Wireless IP Radio Modules Are Modems
It is better to consider Wireless IP Radio Modules (“Modules”) as similar to old dial-up modems that used traditional telephone lines, rather than continuously-connected devices, used in DSL and Cable IP services for example.
(Note: even DSL and Cable units also perform the functional equivalent of “dial-up”, but these are usually set to “dial” immediately after power-on, and stay connected till power-off—acting as if they were connected via a physical wire to the Internet.)
To establish a session, the M2M firmware must initiate the cellular transmission from the Module using a “dial-string” … very similar to making a phone call with dial-up modems. The controller running the M2M Application code sends an AT command (for example, “ATDT #777”) to the Module over a serial or USB port.
Indeed, using “AT” commands with Modules is very similar to using AT commands (originally developed by Hayes Corporation) for traditional dial-up modems.
After receiving the “ATDT #777” command, the Module originates a call using the dialed digits “#777” to the Mobile Switching Center (“MSC”) that is serving the Device in the local cellular network. The MSC interprets the digits “#777” as a request to establish a data session and allows the process to continue.
The detailed mechanisms of establishing an IP session in Wireless IP technologies is unnecessary to describe here. Suffice it to say that the cellular systems have the necessary equipment, protocols, and communication mechanisms to make it all happen using the relevant cellular data standards.
Dueling PPP Stacks
Using a PPP session for IP data transmissions after “dialing in” using a Module, is just like using PPP on traditional dial-up modems on dial-up telephone lines!
In traditional dial-up modem connections, the computer that is connected to the modem uses a PPP stack to establish an IP session to the network and remote server. This is generally under the control of the computer, since the user can choose whether the dial-up modem connection is used for an IP data session or with a terminal emulation program for accessing the server.
Similarly, the Wireless Device must use a PPP stack for the IP data session to the cellular network. And, here is one potential source of trouble!
Many manufacturers provide an IP stack in the Module. However, Developers writing code for their M2M Applications sometimes add a separate IP stack to the firmware of their Devices.
When the Module establishes a cellular data session with the network, both stacks may attempt to set up PPP sessions!
This causes problems for Device operation on the network. The systems providing the end-point of the IP session may get confused and assign multiple IP addresses; they may disconnect only one session when the Module eventually terminates the session; the systems may reject both session attempts; etc.
Thus, if there are two IP stacks in the Device, software developers must cleanly ensure that only one attempts to establish the PPP session—the choice of whether the IP stack in the Module or the Application is used, is up to the developer.
IP Session Started by the Device
In cellular data technologies, the session is always initiated by the Module (of course, under control of the external M2M Application code)—the analogy to dial-up modem service holds true.
Thus, until such an IP session is started and connected, there isn’t any IP data path for a network system or server to send IP data to the Device. M2M Applications are generally designed with this concept in mind.
However, if the network or server needs to initiate the transmission of IP data to a Device, mechanisms called “Shoulder-Taps” must be used to cause the Device to start the actual session if it is not in a session. Typically, these shoulder-taps are Mobile-Terminated SMS (“MT-SMS”) messages sent to the Device.
Send Content in MT-SMS Shoulder Taps
When an MT-SMS is used to “shoulder tap” a Device to initiate an IP data session, it is useful to send information to the Device in the SMS fields, rather than simply sending an empty MT-SMS (since the length of the SMS content generally does not change its cost).
For example, consider sending Absolute Time (perhaps the server time in “seconds past midnight UTC”) for the remote Device programming 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 time—the latter 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 as 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 information that is unique to the M2M Application) can be sent in a single MT-SMS shoulder tap.
Next Post In the Series
In the next post on this topic, I will cover UDP or TCP, data encryption, and other best practices for using Wireless IP for M2M Applications.
What are your Comments?
Please post your comments. Thanks!