To much of the outside world, Sigfox and LoRa seem to be rivals competing for the same market – and that’s because they are. However, underlying that idea is the assumption that the two approaches are very similar. In the post-MWC landscape, after several follow-up discussions, we’re here to clarify their differences – despite surface appearances suggesting that they are nearly interchangeable for adopters and developers.
At its heart, the fundamental difference between Sigfox and LoRa is that Sigfox focuses on an ultra-narrow-band implementation, while LoRa has opted for a wideband CDMA approach – something that isn’t apparent from the LPWAN tag with which Sigfox and LoRa are often branded.
The difference is much more than semantics, as the choice of radio protocol will hinge on the type of application required. A unidirectional scheme is great for certain applications, where only intermittent status updates need to be sent off to the cloud management system. But a developer may need bidirectional communication if a device needs to be told to trigger an action or actuator. Both protocols aim for long range and low power consumption, and are aimed at IoT applications – but they are not interchangeable.
LoRa seems more suited to applications that demand higher bandwidths, while Sigfox’s lower throughput will appeal more readily to developers who only need to send and receive small messages – it’s a case of matching the technology to your applications needs, and while both provide bidirectional communication (LoRa since launch, Sigfox since the second half of 2014), the choice will largely come down to network requirements and deployment schedules.
But technology isn’t the thing that wins these kinds of arms races; it’s the business model. The Sigfox approach seems more likely to win new customers, with already-installed national networks a powerful bargaining tool when it comes to encouraging customers to sign on the dotted line. LoRa and its supporters might argue that the Sigfox technology isn’t as good as the LoRa approach, but for businesses looking for a quick rollout with a small upfront investment, Sigfox currently wins over LoRa.
That may not always be the case, but significant chunks of the LoRa spec have yet to be written. Sigfox’s stack may well be sub-par, but it is already shipping in chips in a finished form – while LoRa is just getting started. Critics have complained that Sigfox’s marketing department is the only valuable part of the business, but it would appear that the investors have looked over the business model and given it a resounding thumbs-up in the form of $115m funding. Those investors may not understand the technology, but you can usually trust them with their cash.
LoRa and its supporters have ground to make up, and the LPWAN market may be very different in a couple of years. The race for the IoT sensor markets has already begun, and Sigfox’s low overheads (mostly comprising its wage bill, with very little in the way of capex) and deployment head start may well give it the long-term edge over LoRa – although Sigfox appears to have a lot of head-scratching and redrafting to do in order to conform to the US FCC ISM requirements (more on that later).
The post-MWC feedback:
Sigfox recently told us it had quietly upgraded its network infrastructure to support bidirectional ultra-narrow-band (UNB) communication, in the second half of 2014, as well as achieving FCC certificatoin in September 2014. The unidirectional communication was the most frequently cited critique of Sigfox and its technology from the LoRa camp, and on the surface it appeared that this was a legitimate complaint.
But as Eric Nicolas, Sigfox’s product marketing manager explained, the company chose to upgrade its base stations in Q3 and Q4 to support bidirectional communication – preferring to under-report but over-deliver, and focusing its external communications on news of network expansion rather than the software updates.
Nicolas said that this now put the Sigfox capability on par with Class A LoRa devices, which have bidirectional communications where the device’s uplink transmission is followed by a brief downlink communication window – perfect for sending an acknowledgment or command before the device re-enters sleep state.
Class B LoRa devices have scheduled downlink slots, where the device will wake at pre-programmed times to listen to the network, and Class C devices have always-open receive windows that only close when the device is transmitting to the network – which crucially means that the LoRa protocol is bidirectional, but not simultaneously capable of both downlink and uplink.
Class B and C have increased power consumption requirements due to the extra wake cycles and lack of sleep. Nicolas said that some bidirectional Sigfox devices have already been deployed, and mentioned a US installation of smart meters, which don’t have to worry about power consumption thanks to a wired connection.
That consideration is something that developers will have decide for themselves, as the tradeoff for bi-directionality is found in reduced battery life – one of the primary requirements for IoT sensor deployments. It’s also worth noting that you can’t perform an OTA update to remote updates to try and support bidirectional communication if the device isn’t able to listen for the update due to lack of hardware – although Nicolas assured us that all Sigfox chipsets support the feature, but not all deployments would include the necessary two-way RF components.
When asked whether LoRa and Sigfox can coexist in the market, Nicolas said yes, but that he saw LoRa as a rival in LAN deployments and applications that require a higher data rate than Sigfox can provide on its UNB throughput. He said that LoRa deployments would also require more base stations too.
But a more pressing criticism which Nicolas pointed out, was that in order to adopt the technology, buyers must lock themselves into purchasing modules from Semtech. While an option is currently available from MicroSemi, under license from Semtech, this closed approach could see LoRa go the way of Z-Wave – which appears to be stagnant compared to livelier rival ZigBee.
Nicolas also pointed out that Class B and Class C in LoRa have yet to even be standardized, with only Class A finalized in a specification.
Nwave’s take:
Last week, we spoke to Nwave CEO Jonathan Wiggin, largely discussing the upcoming ISM-based version of the Weightless spec (a project that began under the auspices of Neul with a TV white space implementation, but which later transferred to the ISM bands after Neul’s acquisition by Huawei slowed progress down). The Weightless-N spec is currently almost completely based on Nwave’s own protocol, and you can find a much more thorough description in last week’s edition of RIoT.
On the subject of LoRa and Sigfox, both competitors for Nwave and Weightless-N, Wiggin said that Sigfox’s business model was cumbersome and not the best approach to take. He said that the “build it and they will come” method was expensive, and that the modular and project-based approach of Nwave was a much safer bet – although we feel that having a ready-to-go network in place is still a very powerful draw when it comes to signing deals.
Nwave prefers an area and application specific network deployment, using gateways sold to the customer to cover only the required area. Over time, that coverage might expand out to reach something like the national coverage that Sigfox is aiming for – but these two very different approaches won’t be reconciled in the short term.
Wiggin thinks that customers need to be able to see a network in action, with applications running on it, in order to encourage them to build their own use cases. He also felt that Sigfox’s national approach means that it will lose out on business that only requires a very localized deployment – where high densities of devices are better handled by multiple, closer gateways than a single wide area base station.
Nonetheless, when asked about his opinion of Sigfox, Wiggin admitted that it was hard to take a dim view of a company that has raised so much funding – despite only having revenues of $6m. Sigfox hasn’t published any numbers, but if Wiggin’s figure is in the right ballpark, it does look a little worrying given the $115m investment that has just been made in Sigfox.
And it isn’t just the financials that trouble Wiggin about Sigfox. He said that the current implementation of bi-directional communication means that the base station can only talk to one end device at a time, and given the comparatively long time it takes to send a Sigfox message, this is an issue that will not scale well.
But Wiggin takes a fairly dim view of LoRa at the moment too, saying that although it is “an exceptionally good protocol,” its broadband CDMA implementation means that it does scale well in dense deployments, and would end up taking up too much spectrum. Wiggin didn’t criticize the single vendor hardware approach, but to do so would be hypocritical given Nwave’s current business model.
The Link Labs perspective:
We reached out to Link Labs, another player in the LPWAN game, and spoke to CEO Brian Ray, and director of business development Glenn Schatz. Founded about a year and a half ago, the company has a lot of experience with the US Department of Defense, but can’t tell us much more about its involvement there.
Schatz said that the company has taken a particular liking to LoRa, and has developed robust software stacks around the protocol – while remaining PHY agnostic, so that it can jump ship if needed in the future – with a long term strategy of becoming more of a PaaS than a hardware vendor. Schatz noted that because the hardware is so closely tied to Semtech, and the LoRaWAN component is controlled by IBM and Actility, customers might be reluctant to adopt the approach due to its closed nature – hence remaining PHY agnostic.
Similarly, Link Labs has built its own LoRaWAN replacement, called Symphony Link, intended to replace the MAC-layer functionality that would normally be governed by LoRaWAN. With an AWS backend, Symphony lives on the gateway itself, unlike the LoRaWAN implementation, which is run in the cloud in order to try and treat a distributed network as a single antenna – in order to run the acknowledgments and de-duplication processes more easily.
Ray explained that the Sigfox business model is quite similar to Link Labs’ long term strategy, in terms of network coverage, but that the company still wants to be able to ship hardware to OEMs if it is needed – while Sigfox’s goal is to be completely removed from hardware, allowing network partners to install the infrastructure, and silicon players to install the Sigfox stack on chips in the factory.
He also explained the main differences between LoRa and Sigfox in layman’s terms, by saying that a Sigfox message is sent relatively slowly in a very narrow band of spectrum (hence ultra-narrow-band) using Gaussian Frequency-Shift Keying modulation – effectively asking the base stations to listen very closely to one specific bit of the radio spectrum, sticking with the information theory that says the slower you transmit, the more easily you are heard.
LoRa takes the opposite approach, and uses a wideband approach, with modulation that chirps a message over a very wide channel of some 120KHz. Thanks to OFDM, multiple messages can be sent over that same channel – which is not possible in the Sigfox approach. A constant preamble chirp is used to allow the receiver to focus in on the transmission, which allows higher signal sensitivity.
The main downside to the LoRa method is that you have to accommodate a much higher noise floor in the receiver, which requires much more filtering to discern the message among the noise. Ray feels that despite this, the LoRa approach comes out ahead, and notes that Sigfox tries to overcome this issue by having more channels for those single messages to be conveyed – while LoRa typically only uses 8. Sigfox notes that its UNB approach is robust enough to accomodate the noise floor, and points to a whitepaper from Texas Instruments that says Sigfox is more robust than the spread spectrum approach used by LoRa.
Another key distinction in the terminology that Ray wanted to make clear was the LoRa refers only to the PHY layer functionality, with LoRaWAN handling the higher levels. This means that LoRaWAN lives on the end devices and the base station gateways, but that both LoRa chips and the LoRaWAN stack are required for a functioning LoRa system. This is where being forced to buy Semtech chips comes from, despite the LoRaWAN project being open-sourced by IBM – called LoRaWAN in C.
According to a Link Labs guide, “the OSI Layer 2 and above functions of large networks (anything higher than the PHY) that include gateways, repeaters, addressing, adaptive data rates, message retries, message acknowledgements, and high capacity OFDM downlink signals are functions of systems like LoRaWAN and Symphony Link.”
LoRaWAN is a “server-side implementation of a multiple access protocol designed to minimize collisions with a large number of endpoints. It requires a server application to run the MAC functions over a network connection. The network architecture is typically laid out in a star-of-stars topology in which gateways are a transparent bridge relaying messages between end-devices and a central network server in the backend.”
After the data is in this central cloud, it can be ported to the necessary platforms – which include LoRaWAN developer IBM’s Long Range Signaling and Control (LRSC) software.
A final point that Ray wanted to convey was that Sigfox seems to facing problems in the US due to the difference between the EU and FCC rules regarding ISM band usage. In the US 902-928MHz band, there is a hard limit on message transmission time of 0.4 seconds. As the Sigfox messages are typically three seconds in length, which is fine outside the FCC restrictions, Link Labs believes that a new architecture is required – which would explain why Sigfox’s European growth has vastly outpaced its US growth. Link Labs points to dog-collar tracking product Whistle’s acquisition of cellular-based Tagg, after not being able to deploy on a US Sigfox network.
Deployments:
Senet, a New Hampshire based M2M operator has installed 20,000 Semtech LoRa sensors and a LoRa radio network for fuel vendors looking to more efficiently fill customer tanks. The sensor in the tank provides a real time reading of the fuel level, so that the seller can more efficiently deliver fuel to cut costs. Proulx Oil and Propane is one such customer, and has so far managed to cut the total deliveries to customer tanks by between 2-3 stops per year.
The Senet cloud platform licenses IBM’s Long Range Signaling and Control (LSRC) protocol, to handle all the communications leading up to the cloud, in combination with the LoRaWAN stacks and the LoRa protocol at the device level.
Both KPN and Swisscom, two European telcos, have announced that they will be deploying LoRa gateways this year; with Actility (an IoT solutions and network provider) announcing 4 LoRa wins including Swisscom, NKE Electronics, and La Poste. Actility sells its ThingPark platform and hardware to operators looking to set up a local or national LPWAN, and Actility is strongly endorsing LoRa.
Microchip has also recently launched the RN2483 LoRa module, which includes the LoRaWAN protocol stack, in a 17.8mm x 26.3mm x 3mm form factor. The RN2483 currently works in the 433MHz and 868MHz ISM bands, which means it is currently not an option for US developers.