The Lightweight Protocol Conundrum in the IoT

What do we need to successfully build a network of IoT ‘things’?

I finally gave up at 1:57 a.m. Tokyo time and rolled out of bed, restless with jet lag and a churning brain. The awkward time would be more palatable if Tokyo was where I had intended to spend the night – delayed flights are one of the less glamorous sides of travel.

But what has my brain busy is a mental wrestling match about the definition of “lightweight.” For example, I’ve been doing a good amount of biking over the last year, and in that world gear-head roadies will chase down grams of weight with a relentless (and expensive) enthusiasm.  While I admit to having succumbed to carbon fiber, I’m pretty sure that further investments in “lightweight” are negated by the soft lump in the saddle, outweighing the bike by 10:1. (And that’s being overly kind to myself).

So, what is lightweight? Ask that question to an automotive engineer, aeronautical engineer or aerospace engineer and you’d get three very different answers.  The question is, of course, all relative to the overall system in question.

But I’m not an automotive engineer. In my world of machine communications, the word “lightweight” revolves around communications protocols and their associated overhead relative to the task at hand, which is to send a piece of business-critical data from Point A to Point B, securely and reliably. And what we define to be “lightweight” has everything to do with how big that actual data payload actually is.

Why is this important? Because of the Internet of Things (IoT). We’re in an era where we want to connect more and more stuff. Before the IoT, we weren’t often concerned about “lightweight” communications because our actual data payloads were typically pretty large. But now, the new cellular technologies LTE Cat M and Narrowband-IoT are rolling out make it not only possible, but practical to deploy low power, low bandwidth monitoring solutions that are inexpensive to buy, install and own – but only if we design them right.

Here’s an example: what if we want to send a chunk of data and that chunk is 60kB? Not much really—a small image or a short document.  For that 60kB payload we can afford ourselves the luxury of using TCP. And because security matters, we can use a secure connection like TLS. Our overhead costs aren’t too high. We’ll spend a few thousand bytes on TCP overhead, plus it will cost you about 6kB to setup the TLS connection. Our 60kB of data will be about 85% efficient. Not exactly carbon fiber, but workable.

The problem lies in the IoT world where we want a tiny bit of status from a machine or a piece environmental data from a sensor. Now our payload is 100 bytes or less.  You can pack a surprising punch into only 100 bytes of payload. (Want an example? Take a look at the POTUS Twitter feed).

Suddenly things like TCP IP and TLS look more than a little bloated. If we work that same example we will drop to roughly 2% efficiency. If you’re sending data over a cellular connection, or from a battery-powered device, 2% efficiency is a non-starter.

So, back to this concept of the IoT. To successfully build a network of “things” we can’t simply apply the identical systems engineering that we used in the 1980s and ‘90s to network computers, or those that we used in the 2000s to network people.

We need truly lightweight protocols that are secure, are IP-based that won’t overwhelm a 200kB/month cellular data plan, or won’t consume much battery life from battery powered wireless sensors.

Do we need to invent something new? I don’t think so. But do we need to change our thinking about how we engineer these systems compared to prior networking eras? Absolutely.

If you’ve tackled the systems engineering conundrums of the IoT or you’re embarking on that journey, talk back. I’d love to hear from you.

 – Mike Fahrion

You may also be interested in:

• An IoT-connected journey—the biggest mistake is not getting started
• The needed mindset when entering the Industrial IoT world