Real world Internet of Things

Having spent some times working with devices connected via GSM, I'd like to share some observations that seem to be obvious to cellular network engineers but get lost in the breathlessly overhyped echo chamber of marketing. The short assessment is that depending on the mobile nature of your connected device, the allowable delays, and the amount of data your intend to transmit and receive, you will need to very carefully choose your protocol and state management.

To begin, there are two major types of connected "things": #1 Mobile "things", such as trains, planes, and automobiles. and #2 Immobile "things" such as thermostats, refrigerators, and buildings.

Mobile Things

Mobile things have two unique problems you'll need to be concerned with, they are: #1 Speed, #2 Network availability

Speed (and/or velocity) impacts network connectivity because it introduces signaling problems for the radio network. Rapid movement or changes in direction can greatly impact packet loss and greatly reduce the effectiveness for protocols like TCP. If your device moves quickly and/or changes direction/speed often, you'll likely want a UDP or RTP based protocol to allow customization of how you deal with packet loss and delay. This also means that you're going to want to reduce the size of each message, but potentially increase the frequency and develop novel ways to handle losses. If you design your device to just use a TCP connection and delegate all this work to the networking stack (without serious TCP tuning) you're going to have a lot of problems most network engineers (outside wireless telecom) are just NOT used to dealing with. Be prepared for sleepless nights and sporadic failures if you use TCP.

Network availability introduces a similar problem as your device may enter and leave areas where is cannot communicate "at all". As above, your protocol needs to have definition around "what do we do when my device falls off the network for a few minutes/days/hours?". This is a big deal when using TCP based protocols because most connection based protocols account for this by waiting around to see if the connection can be reestablished, then using retry mechanisms to "guarantee" delivery.

A major failure folks tend to have with mobile things is that they tend to test their devices in unrealistic controlled environments (stationary in a lab) and rate their performance based on these criteria. When the devices begin operating in the real world, the factors above rear their ugly heads and the reliability of the overall system is severely impacted.

Stationary Things

Stationary things are arguably easier to deal with since, once connected, they don't have to deal with the problems mentioned above for mobile things. More importantly, they are generally tested in a manner similarly to how they are deployed...that is, stationary and with network connectivity. There is a problem that stationary things have that is generally much more problematic, which is shared with mobile things, but aggravated...namely:

"What do I do if I cannot get on the network?"

When designing a stationary thing, how can you handle a device that is deployed in a location with poor or nonexistent connectivity? Generally, a stationary device will need more connectivity options (3g, 4g, wifi, X.25, satellite, ethernet, bluetooth) as once someone has placed the device, it is unlikely that it will roam in and out of cellular connectivity (if it can't get a connection, it will never get a connection).

As more devices become connected, the importance of designing network protocols and tuning the stack to the device's attributes become more important in everyday life.