If there’s one thing the Internet of Things (IoT) has in abundance, it’s protocols. Some are standards, some are standards-in-progress, and some are proprietary. I’ve done some cursory reviews before, but each survey seems to raise at least as many questions as it answers. We saw that with the deeper dive into messaging protocols; things will be no different with this piece today. Probably worse, actually – in the end, while we’ll cover a lot of issues, it’s somehow unsatisfying.

One of the universal themes in IoT-land is wireless communication. We’ve discussed the basic battle between WiFi, Bluetooth, and Zigbee before, but these are all short-range protocols (meshing aside). There’s also activity afoot with respect to longer range wireless protocols, but with power and cost characteristics intended to make them more attractive for IoT deployments than the current cellular system is.

These are generically referred to as LPWA (or LPWAN) for “low power wide area (network).” We saw one with SIGFOX, but the more I dug, the more I found. There’s a lot of work going on here – when a winner shakes out, there’s going to be a lot of scrap protocol littering the side of the road.

My goal was to compare them. Which raises the immediate question, “What are you going to compare?” Perusing the different pieces of literature in support of this protocol or that, I tried to distill some common threads along which I could line up the protocols. It was less satisfying than I had hoped. Welcome to the land of, “It depends.”

Unlike with the messaging protocols, here we’re dealing with lower network layers, all the way down through the PHY. It’s all about spiriting bits from an edge node into a backhaul network, with some provision for getting bits back. And doing so in a way that meets data rate, range, power, and cost requirements. Those criteria work against each other, so it could be that there is no one best protocol.

But there’s also the “here’s what our protocol can do – theoretically” vs. “here’s how it works in practical installations” question. Each protocol makes claims, but I heard more than once about “other guys’” marketing claims that were good in theory only. Some folks have done a lot of work to prove their point. So we can – and will – assemble a comparison table, but I’m sure some folks will look at some numbers and say, “Oh, that’ll happen only on paper.” Dodgy parameters are labeled below with “Caveat.”

So, rather than this article being an answer to all questions LPWAN-oriented, it’s a basic treatment that exposes many questions. I’ll discuss the parameters I chose to compare – including some that I’m really unable to compare. I’ll then briefly review the protocols I compare, ending up with a table. Of sorts. It’s all squishy, but it just ain’t right without a table.

I got the information first by combing the web and documents, and then by asking specific questions of representatives from each protocol. Answers to those questions often contained color or background that both explained the answer more clearly and illuminated just how unreliable some of the numbers can be.

Playing Nicely Together

One important factor in this confusion is that most of these protocols take advantage of industrial, scientific, and medical – ISM – frequency bands. These bands differ as you change geography, but the critical thing about them is that they’re unlicensed. They’re regulated – there are rules – but anyone who follows the rules can use the spectrum without buying a license. Critically, you also don’t get exclusive access. Some of the protocols have been implemented over licensed spectrum as well, but they’re far and away the exception.

The rules for using ISM bands vary regionally, but, details aside, they amount to this: “We’re going to set aside some spectrum here for you guys to use as you see fit. Here are some rules to make sure you play nicely. Now go play.” Otherwise, you just know that some entitled bozo is going to blast away nonstop, crowding everyone else out.

Because you have all of these different potential users sharing the same airwaves, they all need to bow to one physical reality: interference. Both “wave” interference, as receivers try to sort through a noisy environment, and access interference, as multiple senders try to get a channel.

Lots of interference and cheap receivers mean a signal that won’t be detectable as far away as might be possible if no one else were broadcasting. This has range, data-rate, and power implications (since shouting louder obviously increases range and power).

Most of the protocols play nice using collision avoidance techniques of one kind or another. The general rule is, “Listen, then talk.” (M2COMM’s Fabien Petitgrand says this is the “law” in Japan.) Like an old-fashioned party line – pick up the phone and see if anyone else is using it. If not, then go for it.

Another option is derived from the Aloha protocol, which doesn’t listen, but rather transmits and waits for a brief acknowledgment. If it doesn’t hear back, then it assumes a collision occurred – this is collision detection instead of avoidance – and resends according to a back-off algorithm.

While collision avoidance and detection aren’t required everywhere, they’re encouraged. In Europe, for instance, if you don’t use such an approach – if you just broadcast without listening – then there are severe duty cycle limitations. SIGFOX is an example of a protocol that doesn’t have a play-nice media access approach, and so it must live with the duty cycle limitations – which is why it has data rate limitations and limits on how many transmissions are allowed per day.

I’m Not Listening

You might wonder why one would sacrifice that much data capacity for the privilege of blasting a message over the top of everyone else. My guess is that listening before talking means you need a receiver to do the listening. That may be obvious, but, in its first incarnation, SIGFOX was an uplink-only protocol – the first Atmel SoC supporting it was all TX, no RX.

Leaving off receive circuitry obviously saves cost. Clearly, to make that tradeoff, you have to believe that the application itself needs no downlink. If that’s the case, then adding RX capability just for some protocol nicety might seem wasteful – especially if you believe that your application doesn’t need higher bandwidth. So you live with the duty cycle rules, presumably with a cost advantage.

There are also power implications on the edge-node side. If an edge node does nothing but transmit, then it’s in control of its destiny as it decides when to wake up, transmit, and go back to sleep.

If it’s going to receive as well, then it’s either got to keep listening all the time (burning power) or it’s got to have some schedule that both it and the hub or gateway agree on. Staying in synch means more expensive clock components for better precision and/or beacons or other keep-alive traffic. That traffic obviously burns more system power than a completely quiet channel.

So including downlink means both extra RX circuitry and increased overhead traffic, both of which cause the consumption of additional energy. This is another area of distinction between protocols. Even SIGFOX is being revised to include a downlink capability, but it’s limited. And other protocols are also asymmetric with respect to up- and downlink.

Energy and Cost – Everyone’s a Winner!

Energy consumption is particularly difficult to pin down. It and cost are the two attributes that every protocol says it’s best at. And there’s no real way of proving a winner (ahem, EEMBC?)

The number of items that affect energy is practically uncountable. There’s not a thing that goes on – from choice of modulation scheme to media access protocols to acknowledgments and adaptive techniques – that doesn’t affect power. This is the biggest “it depends” parameter of them all – to the extent that I excluded it from the table.

It’s not even clear what energy consumption should be compared. According to Telensa, “The only power consumption figures that count are… measured in [the] battery life [of edge nodes].” M2COMM’s Mr. Petitgrand notes that power efficiency can also differ: “LPWAN [protocols] use low power, but this actually translates to higher energy consumption than 2G when transferring the same amount of data. [emphasis in original]” The issue here is that lower transmit power means a slower data rate, which means it takes longer to transmit, which means you’re out of sleep mode for longer. Fainter signals due to low transmit power also require more sensitive receive circuits, which typically means more power.

Cost is also a squirrely parameter. One approach to it is, “I have an edge node that’s missing only the communication piece. How much will it cost (for a module, an SoC, whatever) to provision my node with this protocol?” More than one person said that, once volume is established, there’s not likely to be a significant difference in this cost. Other cost models include gateways/hubs in the comparison. Then there’s operating cost.

Exactly which costs are important depends, among other things, on the rollout model. With a protocol intended for use in private networks, the acquiring company will bear all of the costs – edge nodes, hubs, operations. But for protocols being worked into public cellular-like services, like SIGFOX, the end customers ultimately pay the edge-node costs in their equipment, the network operator pays the backhaul infrastructure cost, and the end customer pays some ongoing subscription fee that presumably covers the operating costs of the network.

So there’s no one cost model that everyone follows, with the result being that there’s no meaningful way (at this point) to include cost in the table.

So What’s Left to Compare?

Range (Caveat)

OK, we all know that the range of any wireless technology can vary based on what’s in the way of the signal. That applies to these LPWAN protocols, to be sure. In fact, even more so. A dense urban setting, with walls and buildings and reflections and lots of other people and traffic, means much shorter range than a rural one. And a flat, unobstructed rural setting will fare better than a hilly one. But there are other factors – interference and collisions make for lower ranges, for example.

So ranges are hotly disputed – a protocol claiming 10s of kilometers may be denounced by a competitor as maybe a couple of kilometers under real-world conditions. The numbers I put below should therefore be taken cautiously. You could argue that this line should also be removed from the table, but at least we have numbers (if fantastical at times).

One other note: you’ll find some of these protocols with marketing material that competes with Zigbee, for instance. Which would at first seem odd, since Zigbee is much shorter range. But Zigbee – and other protocols – can achieve long range through meshing. I am not considering meshing in this piece, so “range” refers to a single radio link.

Band/Spectrum

Almost all protocols use ISM bands; some may also use licensed spectrum as an option. I show the frequencies claimed in the table.

One aspect I have not dug into is the nature of the spectrum use. Some are ultra-narrow band, some are narrow band, and some are spread-spectrum (direct sequence and chirp). Fodder for future discussion, perhaps.

Up/Down Symmetry

We discussed the fact that these protocols are biased towards data upload in many cases. The table simply addresses whether the protocol is symmetric.

Data rate (Caveat)

This is another highly variable parameter. It depends on distance and obstructions and competing data traffic. So only general ranges are shown. I’m sure they’re debatable.

Maximum number of nodes (Caveat)

There are two different ways this tends to get quoted. One is as nodes for the entire network; the other is as nodes per hub in a star configuration. In the latter case, depending on the backhaul structure, there may be no fundamental limit to the number of hubs.

There are two ways in which a limit may be hit. One may be built into the protocol – an addressing scheme, for example. But even if a protocol can theoretically handle a million channels, there may not be enough capacity in a particular ISM band. And it’s not just a matter of doing the math; it depends on who else is using the band at any given time.

Over-the-air upgrades possible?

This may sound like a random characteristic, but it hinges on the amount of downlink capacity available. If only a few bytes of control capacity are provided, then you won’t be able to download a larger software package for updating a remote node.

Handoff?

It’s easy to think of IoT edge nodes as static units radioing in data. But some devices – automobiles and farm implements, to name a couple – are mobile. Others might not be mobile, but someone might move them – like inventory with electronic price tags. So it’s natural to wonder whether a protocol can handle the hand-off of a device as it moves between hubs.

Note that this matters only to the extent that a “session” of some sort is being maintained. If, at wake-up, an edge node always had to authenticate and join the network briefly before going back to sleep, then hand-off wouldn’t matter – each transmission would grab the nearest hub antenna. But some protocols have explicit handoff capability, so a longer-term device/hub relationship must therefore be possible.

Operational model

Some protocols are being implemented only by network operators to provide public network services, much as is done with the cellular phone system. Others can be used for public or private networks.

Standard status

Some protocols are standards (or in progress); some are “open”; some are proprietary. In some cases you can get a spec; in other cases you have performance requirements to pass for certification (with the underlying protocol implemented by an opaque SoC).

And in a couple of cases, proprietary technologies have been donated for standardization. In that case, it’s typical that you end up with a standard version that’s slightly different from the original donated protocol.

A brief rundown of the protocols compared

LoRa and LoRaWAN

This protocol originates with Semtech, who furnishes the silicon to implement the protocol. They’re planning to license other sources as well.

I originally thought that LoRa and LoRaWAN were two names for the same thing. Turns out not so. LoRa is Semtech’s PHY, and it is not open. If you want to use it, you use their silicon or that of someone they have licensed (there’s no one else at present).

LoRaWAN is the rest of the protocol stack. It was assembled by an Alliance led by  IBM, Actility, Semtech, and Microchip. This portion of the protocol is open. (I’ve noticed that, for some reason, some folks don’t consider the PHY to be part of a protocol. But to me, if it’s part of “the rules” to make something work, whether or not it involves a handshake with another party, it’s a protocol.)

LoRa has three classes of edge node: one that allows a small downlink window after each upload (solving the scheduling problem if your downlink needs are frugal); one that allows a scheduled downlink slot; and one that listens for downlink messages at any time. The latter ones burn more power than the former.

Microchip has announced supporting modules; Bouygues Telecom in France has announced a new network build-out.

NWave

This company has its own proprietary technology that formed the basis for Weightless-N (below). They have virtualized hubs that allow multiple streams – public and private – to pass; the central server sorts out which streams belongs to whom. They describe it as a VPN capability within public traffic.

OnRamp

OnRamp uses its own protocol, which it calls RPMA (random phase, multiple access). They created this completely from scratch, and they use it for contracted installations that they implement themselves. They have a very detailed whitepaper going into the reasons why they believe they compete well against SIGFOX and LoRa – and it has way more tables than my measly one below.

Platanus

This protocol was designed to handle ultra-high node density over modest distances – their motivating application was electronic price tags. It’s proprietary to M2COMM, but it has also been donated as the basis of Weightless-P (below).

SIGFOX

We’ve talked about them in some detail before; I’ll let that piece handle this protocol. Note that, since that article, they’ve added a small downlink capability. I also asked about a couple features; as of this writing, I haven’t heard back. I have indicated these as “doubtful” in the table.

Telensa (formerly Senaptic)

This company implements full-on applications, in particular for city resources (parking, etc.). They control the entire vertical stack for the sake of the application (even though pieces of the stack conform to standards). They have open interfaces, but the protocol itself is not yet open. They indicate it’s likely to happen at some point – they consider their company differentiation at the overall application level, not at the low protocol level.

Weightless

This is actually three protocols. The original is Weightless-W, which leveraged so-called whitespace – unused local spectrum in the licensed TV band. That was then supplemented with Weightless-N, an unlicensed spectrum narrowband protocol born out of NWave’s technology. More recently, work has started on Weightless-P, based on technology donated by M2COMM (the Platanus guys).

The two most likely versions for IoT deployment are –N and –P. –N is unidirectional – uplink only; it’s also a simpler feature set. –P is being outfitted with more features, and it has a downlink capability (although the up/down ratio hasn’t been frozen yet).

Amber Wireless

This appears to be proprietary technology (although it’s always possible that some of these companies are commercializing technology that is generically known by a different name). As of print time, I have not received a response from them. The information below is derived from public sources.

M2M Spectrum Networks

To quote their web home page, “We are building and operating the first nationwide, dedicated Machine-to-Machine communications network in the United States over licensed spectrum.” I’m unclear on the underlying technology. As of print time, I have not received a response from them. The information below is derived from public sources.

Coronis

I include this only because my searches brought it up, so you might find it as well. But further analysis showed that it was bought by Elster in 2007 for internal use. I’ve seen no evidence of its current availability as a specific thing.

Huawei’s CIoT

This isn’t really a protocol; it appears to be Huawei’s initiative for IoT over the cellular system (CIoT = Cellular IoT). I list it here simply because it sometimes is referenced as if it were a protocol. Not included in the table.

LTE-Cat0

Refers to a discussion within the LTE world to develop a new profile for small IoT-type devices (Category 0). Not covered in the table below.

LTE-MTC

This is further work being done on LTE to add better capabilities for machine-type communications (MTC). Not covered in the table below.

The Table

(Click table to enlarge)

[Update: Slight clarifications in table; formal Weightless-P network capacity added, Weightless-P data rate corrected]

[Update 9/15/15: Clarified distinction between LoRa and LoRaWAN; edited a few table entries: LoRa column symmetry (in always listening mode, it can be considered symmetric), number of nodes (should be the same as SIGFOX; in reality, neither can actually do millions due to interference, but for table-comparison purposes, if one is millions, then the other is too). Clarified the LoRa standards status given the LoRa/LoRaWAN distinction. Also, clarified that OnRamp is currently not a standard, but they’re working with IEEE.]

More info:

LoRa

NWave

OnRamp

Platanus

SIGFOX

Telensa

Weightless

Amber Wireless

M2M Spectrum Networks