A lot has been written about the popular LPWAN technologies Sigfox and LoRaWAN and in particular about the differences between them with regards to radio technology, data rate, robustness, bi-directional traffic, coverage, etc.

This blog post is NOT about that, rather it wants to emphasise what these two LPWAN technologies have in common. And we don’t mean the fact that they both target low-data rate, long-battery life applications, but rather what they have in common in terms of IT architecture setup, how that paradigm differs from classical M2M architectures and why that is relevant to customers. [1]

‍

A choice of strategic importance

To accurately estimate an IoT solution’s TCO (total cost of ownership), all solution components need to be looked at together – device, communication and application through to installation and maintenance. But not all IoT solutions will have the same freedom of option at all component levels.

At the communication level, there are a number of applications where LPWAN is not an option or is not so well suited (data is mission critical, there is power available, number of messages being transmitted per day over a certain value etc.). For those where this choice is on the table, Sigfox and LoRa propose similar systems characterised by their open architectures and flexibility, as we will describe below.

‍

Sigfox & LoRa architectures – focus on data

In classic architectures, devices communicate to a back-end platform over a bearer provided by the network operator. This is often done via a proprietary protocol, or even when done via a “standard” protocol, often completely proprietary payload formats are used. In a typical setup, there is a vendor lock-in at the solution level, where devices and platform are offered by a single vendor, without any flexibility to swap either of these.

With Sigfox and LoRa, the architecture is somewhat different. Data from sensors is captured by back-end systems provided by the network providers. These back-end systems expose the data over APIs, which are independent of the application.

‍

‍

In this case, the secure onboarding of the devices happens at the level of the back-end systems of the network provider: these systems allow the user to provision new devices onto the network and to associate devices with a customer, hence also covering one of the core features of a classic IoT platform – secure multi tenant onboarding of devices and customers.

In an LPWAN architecture, the main function of the platform sitting northbound of the back-end servers is to figure out what to do with the data, not the onboarding process.

‍

Sigfox & LoRa architectures – reduced vendor risk

Given their very nature, Sigfox and LoRa architectures pave the way for a less closed ecosystem, in the sense that it is much easier to decouple the platform from the devices. As soon as device vendors open up the payload format, essentially any platform that has a (certified) integration with a Sigfox and/or LoRa back-end can be used.

This also implies that it is relatively straightforward to attach devices from multiple vendors to a single platform. As technology is still relatively young, HW evolves fast and what looks like the best HW on the market today, may not be the best tomorrow. So having the flexibility to at any point in time select the best of breed HW is an evolutionary advantage. In addition, it avoids the stovepipe approach where for every application or set of devices, a new application back-end is required.

The same holds true at the back-end side: since the Sigfox and LoRa back-ends have open APIs, it becomes relatively straightforward to switch supplier at the platform side as well.

In closed systems, when problems arise with a vendor (non-performant system, change of strategy, bankruptcy), customers have little choice: either continue with the same solution or switch the complete solution (hardware and software) and consider previous investments as a sunk cost.

‍

Sigfox & LoRa architectures – faster innovation

In conclusion, many people focus on the differences between Sigfox and LoRa. But they have a lot in common when looking from an IT architecture point of view. By having a back-end service provided by the network provider, they allow for a lightweight platform that focuses on creating value out of the data, rather than onboarding devices.

LoRa and Sigfox allow for a more open and flexible architecture, where customers can work with best of breed products both at the device and the platform side, hence enabling a faster rate of innovation and decreasing vendor risk.

We believe open systems are what will push IoT forward and companies that don’t want to be excluded from a fast developing ecosystem of larger solutions will choose open flexible systems early on.

‍

Learn how easy it is to connect your Sigfox or LoRa sensors to Waylay, sign-up for a demo.

‍

‍

[1] Contrary to Sigfox, LoRaWAN is a technology specification rather than a specific network implementation. So, when we refer to a LoRa or LoRaWAN architecture below, we mean the common denominator on how LoRa solutions are typically set up, irrespective of the differences between providers of LoRa network servers or telco network operators.

‍

‍