At Haystack, we are fans of Semtech’s LoRa LPWAN radio. Until recently, we considered the 915 MHz band as too noisy for low power IoT systems, but Semtech’s use of chirp spread spectrum combined with modern silicon capabilities gives them an edge in the growing LPWAN industry. We are particularly bullish on LoRa’s prospects for mobile LPWAN applications where competitors like NB-IoT and Sigfox are effectively stillborn. Every day we are discovering things about LoRa that reinforce the conclusion that it is a good LPWAN radio and it can be deployed in a cost-effective manner.
But like Usain Bolt wearing chain mail and ski boots for a 100-meter dash, Semtech promotes a weak networkingng software option in support of LoRa. Designed to disappoint even the most underachieving IoT developer, battery-powered LoRa endpoints using LoRaWAN can effectively only transmit messages toa gateway and practically speaking cannot receive messages from a gateway. Sending a command to an endpoint, querying an endpoint, broadcasting a message to a group of endpoints, wirelessly refreshing a security key or authenticating an endpoint using public key encryption — those are just some of the things that are more or less impossible to accomplish with a battery powered LoRa endpoint running LoRaWAN.
This is due in part to the fact that LoRaWAN was architected to be very much like a cellular network, only simpler: there is a relatively low-cost endpoint, which can be powered by a battery, and a relatively high-cost gateway, which is typically mains-powered. Communication between the endpoint and the gateway is one-to-one, similar to cellular, which means that broadcasted data flows are not possible. This made sense for phone calls, but even with contemporary cellular systems, which are more data-oriented than ever, the one-to-one routing limitations prevent maximum utilization of the spectrum. This is a bigger problem in LoRa than with cellular, though, because the data rate for LoRa is very low — generally less than 10 kbps, and typically less than 2400 bps. So a broadcast operation that might require 1 second to push a message to 1,000 endpoints, instead takes a minimum of 1,000 seconds. This limitation is understood, and LoRaWAN deprecates communication from the gateway to the endpoint. For the most part, LoRaWAN is a technology designed-for, and suitable to, fixed, automated meter reading, as its design limitations make it a difficult fit for low-latency, broadcasted, or bidirectional data flows. Applications requiring a two-minute communication latency between endpoint and application — this is the minimum supported by LoRaWAN — are advised to use more than one gateway per 60 endpoints, which results in a fairly high density of gateways.
The LoRaWAN Lock-In Strategy
One would think Semtech would be more or less agnostic regarding the application software that rides on top of LoRa as Semtech is a semiconductor manufacturer and they profit when chips are sold for any purpose. Nonetheless, Semtech displays a clear strategy to push LoRaWAN over other networking software implementations using LoRa. A look at their chip pricing provides the information one needs to better understand their plans.
Developers choosing LoRaWAN are effectively “locked in” to the SX1301 LoRa Gateway IC as part of the network implementation, and this gateway component has distributor pricing of $68.00, versus only $3.00for its endpoint radios. That’s a price premium of 2,300%. For the record, the material cost of a chip is next to noting — chips are made of silicon(sand) and a very small amount of metal. With such profit margins on its gateway ICs, it’s less of a shock that Semtech markets networking technology that locks developers into those gateway IC’s.
The high price point for LoRa gateway ICs will eventually drift lower via competition. In fact, the LoRa modulation and encoding schemes indeed have been reverse engineered and the popular “GNU Radio” software for SDR implementation includes a LoRa software driver. Semtech, however, maintains patents for LoRa that prevent commercial adoption of such technologies. Otherwise, it’s possible to build a LoRa gateway software defined radio (SDR) of your own, with performance exceeding that of the SX1301, using off the shelf components such as the Intel Zynq and pretty much any SDR front-end IC (there are many). There is nothing wrong with charging high prices for patented technologies, but it’s worth pointing out the strong possibility that LoRaWAN exists today not to give developers the best set of options for LoRa networking software but to support a certain revenue model for LoRa gateway IC’s. In other words without LoRaWAN, Semtech’s gateway IC margins might be at risk.
LoRaWAN In Consumer/SMB Markets Is Pricey
For business models where only a limited number of gateways are required for a deployment, such premium pricing for may amount to a rounding error. But for those planning large-scale deployments in consumer or SMB markets and who envision a LoRa gateway in every residence or small business (for example, like this), the $65.00 difference between endpoint and gateway amounts to a non-trivial LoRa “gateway tax” that can sink a business plan. For those contemplating going to offline retail with a LoRa gateway solution (e.g. one endpoint + one gateway), the implications of a $65.00 premium on price elasticity of demand are severe. And for those thinking of emulating cellular carriers with a subscription based approach, a straight amortization of $65 over, say, a three year customer lifetime adds $1.81 to a consumer’s monthly bill. Good luck.
Semtech’s implicit message to the marketplace sees to be that consumer-facing customers should look elsewhere for their LPWAN needs.
Avoiding The LoRa Gateway Tax With Haystack
Fortunately, there’s an answer. Haystack’s DASH7 allows the use of a LoRa endpoint radio as the gateway radio. In other words, with Haystack there is no difference in the LoRa portion of the bill of materials between an endpoint and a gateway.
Haystack’s DASH7 networking stack is an alternative to LoRaWAN. Both are very low power, but they don’t do exactly the same things. In fact, the two can operate concurrently on the same devices. What DASH7 does provide, however, are very powerful broadcasting and multicasting features as well as low-latency, bidirectional communications. DASH7 can enable normal, REST-oriented applications to work on LoRa, while LoRaWAN cannot do so very effectively.
Another interesting attribute of DASH7 is the Haystack gateway middleware that supports it. In this case, it is completely different than LoRaWAN. LoRaWAN passes-through low-level attributes of its protocol to the cloud, where packet processing takes place and any business logic runs. This model simplifies the middleware, but at the cost of very high network latency. For many developers, two minute latency is a non-starter, particularly for mobile applications. DASH7 gateways must be able to communicate round-trips to the endpoint in milliseconds, though, so the middleware requirements are very different. Haystack gateways do three things, in particular, which are unique in the LPWAN space.
- Proxy endpoint datasets on each gateway in order to bridge high-throughput internet data flows with low-throughput LPWAN data flows. You can think of this sort of like “Dropbox for IoT” except it is not centralized in the cloud, it is managed intelligently on each gateway. A single Haystack gateway can support roughly 30,000 proxied endpoints.
- MQTT-based synchronization of proxied datasets with cloud-based brokers. In case you do want to synchronize centrally on the cloud, this is possible via MQTT. The DASH7 data model and broadcast/multicast model fit neatly into the pub/sub topic model used by MQTT.
- The core gateway software is written in C, so it will run great on austere, low-cost platforms such as the $5.00 Onion Omega 2. No bloated, virtual machine environments are required. Custom plugins for additional business logic may be done in C or Python.
Due to the sophistication of the middleware, Haystack gateways can be constructed using the overpriced SX1301 Gateway IC, or the much cheaper, $3 LoRa endpoint ICs. Using the endpoint ICs, such as the SX1276, the cost of the gateway becomes similar to the cost of a remote sensor endpoint. These low-cost gateways can be scattered across a network environment and they will work together to provide vastly superior network coverage to an equivalently priced LoRaWAN gateway, while also allowing internet applications to interact with the DASH7 LPWAN at a more fundamental level than is possible with LoRaWAN.
Developers interested in more information on how Haystack can help overcome the LoRa “gateway tax”, click here.
One final thought:
- For those keeping score at home, LoRaWAN’s poor suitability for the high volume consumer/SMB applications described above further circumscribes LoRaWAN’s potential in the IoT should Semtech continue to pursue a pro-LoRaWAN course. This in addition to mobile, battery powered applications as written here and here. This basically leaves LoRaWAN to brawl, I suppose, with another not-ready-for-mobile protocol, NB-IoT, over fixed meter reading use cases. No shame in focused on fixed meter reading, but one has to wonder why Semtech is leaving so much money on the table here and what sorts of freebies this leaves for a competitor rumored to be launching in the coming months.