The Problem with LoRa

We announced the Helium decentralized machine network (DMN) about six months ago. This is a huge leap from our current generation platform but the decision to take this path is based on our belief that, in order for enterprises and developers to deploy billions of connected devices in the next 10 years, they need a ubiquitous, decentralized wireless infrastructure unencumbered by the traditional revenue models and royalty / patent regimes most of the bigger players in the space are putting in place. So we went all in.

“Why?! Why would you do this?!”

Since the announcement, we’ve spoken with thousands of developers and hundreds of enterprises and VCs about our plans. What we’re doing is quite ambitious so we always elicit some sort of reaction. Arguably the best was from the head of R&D from a global networking supplier who, mid-meeting, exclaimed simply “Why?! Why would you do this?!”. Potential investors, on the other hand, typically say something closer to, “This is one of the most ambitious plans we’ve ever seen. If you can pull it off, clearly it will be massive.”

Given the audacity of what we’re attempting these reactions are to be expected. The shortlist of major components we’ve built from scratch for this coming network roll out are:

• Wireless protocol built for small, secure device data; and a new, production hardware module that embodies this protocol
• **Hardware gateway (**or “Hotspot” as we call it) powered by a new software defined radio
• New blockchain for the physical world

Arguably any of these could form the basis of a complete company. And we did not make the decision to undertake rebuilding nearly all parts of our infrastructure lightly. Especially since we have customers in production seeing success building on the current Helium platform.

Another theme in our conversations and talks with enterprises and investors is competitive comparisons. Specifically:

1. The new Helium wireless protocol frequently gets compared to LoRa
2. The Helium network roll out plans get compared to The Things Network (TTN).

Both comparisons are for good reason. So in this post I want to explain why we passed on LoRa; and why we think TTN’s LPWAN deployment model is interesting but ultimately not enough to be successful.

Do We Really Need Another Wireless Protocol?

Earlier this year when we went back to the drawing board, the first thing we revisited was the wireless protocol. The existing Helium wireless protocol wasn’t the ideal choice to build a long range network for various reasons. Firstly, the range and battery life was inferior to alternatives like LoRa. We had also built it to run in two frequency bands — 2.4 GHz and sub-GHz (e.g. 900MHz–929MHz) — thinking that some users would favor the higher data rates 2.4 GHz afforded. We were wrong. Most customers weren’t sending that much data.

For these reasons, and a few others, we decided to test LoRa. LoRa, and LoRaWAN, were starting to see some success, and the Semtech-run LoRa Alliance had some momentum. Also, we’re not wireless zealots. Any protocol that helped us achieve our mission would be ideal regardless of whether or not we wrote it. So we kicked off a rigorous test of LoRa/LoRaWAN at our San Francisco office. Every available gateway was purchased, along with all the modules and dev kits on the market, the available specs were procured, and we started building sample sensor applications using it. We even built our own implementation of a LoRaWAN server.

Part of LoRa/LoRaWAN Graveyard

While the wireless range is certainly impressive, there’s a huge issue with LoRa that doesn’t really get talked about much, partly due to Semtech being clever about the distinction between the proprietary LoRa and the open LoRaWAN. The real issue with LoRa for us was the governance and licensing.

LoRa is the physical layer specification (whereas LoRaWAN is the networking stack that extends up through the cloud). The LoRa Alliance, founded and run by Semtech, owns and publishes the LoRaWAN spec. Hundreds of companies (including even Helium a few years ago) have paid to join this Alliance, and this gives them a seat at the table when it comes to the direction of LoRaWAN. Semtech, however, is in sole possession of the RF modulation specifics. They license this to hardware manufacturers, but they are the single source. This was a deal breaker for us.

Semtech inserts themselves as the only supplier for some of this hardware, and asks for a license fee per-device for the keys to access the finely timestamped packets.

Their licensing regime also extends to the Gateway firmware. And one piece of functionality, specifically, is guarded quite closely: “fine timestamps”. As we detail in this blog post, when using sensor timestamps to derive location, one microsecond equates to roughly 3,000 feet. So, for accuracy one needs nanoseconds. Nanoseconds let you place packages or vials or trucks on a map with precision in the tens of feet without needing GPS. Now, nanosecond precision is hard to come by, but fine-grained sensor location was a feature everyone was asking for so it was a requirement.

Enter fine timestamps. Semtech, understanding the need for this fine timestamping functionality, has various LoRa Gateway reference designs that contain additional hardware to precisely timestamp radio samples as they are received; FPGAs, DSPs and the like. Semtech inserts themselves as the only supplier for some of this hardware, and asks for a license fee per-device for the keys to access the finely-timestamped packets. This was prohibitive to our business model and counter to our beliefs on how networks like this should propagate.

So we passed on LoRa and went to work on WHIP, the new Helium wireless protocol. When we release it in the coming months, it will be open source under a friendly, royalty-free license and use open modulation techniques like GFSK and DSSS that require only commodity hardware.

A gloomy outlook for The Things Network

When Helium was founded in 2013, our goal was to blanket the world with Helium wireless coverage. We realized relatively quickly, unfortunately, that deploying gateways everywhere was going to be far too capital intensive, particularly with our soon-to-be legacy wireless protocol. And we were starting to see success with customers who were happy to deploy their own networks using Helium. So we backed away from the public network model in favor of helping our customers deploy and maintain their own Helium networks.

Five years later, however, we now see deploying ubiquitous network coverage as essential to the success of IoT. So along with rewriting our wireless protocol, we needed a new network deployment model that would let us rapidly build out coverage without spending every dollar of money we raised in the process. (In the LPWAN landscape, companies attempting to roll their own infrastructure have not excelled: Sigfox, bless their heart, is still chasing this dream. MachineQ, on the other hand, seems to have backed off this strategy despite announcing progress earlier this year. And Ingenu, another early LPWAN upstart building public coverage on top of proprietary RPMA technology, seems to have fizzled out altogether over the last 12 months.)

When we detail our deployment model to people familiar with IoT and the LPWAN space, they are quick to compare us to The Things Network (TTN). Arguably one of the biggest success stories in the LoRaWAN ecosystem, TTN started over three years ago with a Kickstarter campaign to sell consumer LoRaWAN gateways. They sold about 3000 gateways in this sale (definitely a huge success), and at this point have about 5000 gateways live across 100s of cities globally. (You can see a tidy map of their coverage here.) And the vision is that people who deployed TTN LoRa gateways would, over time, create a robust coverage network that could be utilized by companies deploying LoRa-based applications. On top of this, TTN would layer cloud-based, enterprise-level services for their customers under their enterprise-focused brand The Things Industries.

On the surface, Helium’s network deployment model appears similar. We’re asking network participants to buy gateways, deploy and maintain them, and share their Helium coverage with companies and developers deploying sensors on the network. The massive difference, however, is that individuals and companies are incentivized to provide Helium wireless coverage. This is where the new blockchain for the physical world comes in. When you deploy a Helium gateway, you’re compensated in two ways — mining and per-packet transport fees — both of which are made possible by the Helium blockchain.

Critically, the Helium network uses an entirely open approach to deploying this network. Just as with established networking and internet protocols like BGP, TCP/IP, and HTTP, we believe that in the long run ubiquitous networking in the LPWAN space requires open protocols and open standards. Building on top of LoRa makes this impossible.

Early validation of our approach is the feedback we’re getting from actual TTN gateway operators. We’ve been on the road the last few months talking at IoT and crypto meetups, and running events of our own. The general response we’ve received from numerous TTN members at these events is the following:

“I get it. This succeeds where the Things Network falls short in that it incentivizes me to keep a gateway online and provide coverage.”

This response from TTN members is encouraging, and ultimately we think the incentivization model, along with a superior wireless protocol / gateway product, will enable us to overcome the CAPEX-heavy model that deterred us initially and continues to make life hard for our competitors (or is at least forcing them to change their deployment and business models).

The Helium Hotspot creates miles of wireless connectivity for low-power machines, as well as acting as a mining node for the Helium blockchain.

The Audacity of Helium

When we look back on our efforts 18–24 months from now, two big questions that relate to our success will be the following:

1. Are enterprises and developers actually deploying IoT use cases on the Helium network?
2. If Helium were to step away from its role in building and maintaining the network, would it continue to thrive in our absence?

The answer to both of these questions will be “yes”. For use cases, it will come down to cost, ease of use, and trust. At a fundamental level, both startups and big companies alike should be asking “Should I bank my business or the success of my new product line on this?” Dirt cheap connectivity and hardware components, along with the feature set that enables a large company to check the “ease of use” box, will be table stakes for all the IoT platform companies trying to capture value from the nine billion MCU powered devices that are shipping every year.

But in our eyes the real differentiator is trust. Helium is so committed to this open source, decentralized machine network vision that, if we do our jobs correctly, all the network components — hardware, software, blockchain, governance, etc. — would continue to chug along even in our absence, and we hope to compete with other businesses in providing products and solutions on top of the network. The infrastructure — from the wireless modulation scheme to cloud routing — has to be open for enterprises to trust the network and the motivations of the operators.

So that’s what we’re doing. We’re going all in.