IOT decision-making tree (part 2): When to employ LoRaWAN/Sigfox/NB-IoT

IOT decision-making tree (part 2): When to employ LoRaWAN/Sigfox/NB-IoT

An article by Richard Barry, Polymorph CEO.

In our previous article, we introduced the IOT decision-making tree for choosing the right IOT protocol. We noted that the specific IOT product you are developing will determine the type of IOT connectivity to use, and the advantages and disadvantages it will yield will flow from this decision.

We highlighted the first branch of the IOT decision-making tree, which commences with the overarching question: Is your device IP-enabled or not. Branch one departed from the premise that the device is IP enabled and we delved into the next steps and questions from the perspective of an IP-enabled device.

In this article, we depart from the premise that your device is not IP enabled (as indicated in branch two below) and you are able to pull data into your own data pipeline via a custom bridge between your back-end to a connectivity gateway, in which case your options include LoRa, Sigfox, and NB-IoT.

The IOT decision-making tree: LoRaWAN/SIGFOX/NB-IoT branch highlighted

Main reasons for choosing branch 2:

  • Energy efficiency
  • Cost-effectiveness
  • Long-range communication

These applications can connect wireless sensors with exceptionally long range and long battery life, while transmitting data. LoRaWAN devices can enter a deep sleep mode and only wake up when required to transmit data or to communicate a new event. Similar to other technologies such as Sigfox, LORA typically runs at lower data rates, which further increases link margin.

However, because this is not an always-on solution that transmits real-time data, delays between sending and receiving data should be taken into account. This simply means that you can expect return data, in most use cases, on an hourly or daily basis. Because it is a fairly uncomplicated sensor, it only returns data from one data point. Examples include water meters that transmit usage on an hourly basis, security gate sensors sending open/close data or an electricity meter communicating on/off data.

Furthermore, the LoRaWAN server that manages the device connectivity usually resides in the cloud. When the server is in the cloud, the gateway operates in packet forwarding mode, which simply means that all the raw data packets are passed to the server and from the server back over the air. The intelligence required for decoding these fairly small packets and ultimately managing the connectivity to the devices is in the cloud.

IoT connectivity options

Comparing LoRaWAN, Sigfox and NB-IoT

LoRaWAN is an open protocol that follows a bottom-up approach and relays messages between end-devices and a central network server. LoRaWAN is good for running an isolated or private network on a farm or in a city. It is ideal for sensors that only occasionally need to send a value, like a soil moisture sensor sending its measurements every 10 minutes, or a water trough sending a notification that it is empty. It is also a good system for the tracking and monitoring of wildlife in a predefined area. For example, LoRaWAN is currently employed for real-time monitoring of rhinos by embedding sensors directly into the horns of the animals, which utilise LoRaWAN tech to communicate with interconnected devices such as computers or the ranger station across long-range wireless networks.

NB-IoT runs in the mobile telephone radio spectrum and piggybacks on old, unused GSM channels, or free space between LTE channels. It requires an expensive and dedicated regional frequency or channel. NB-IoT is ideal for the upgrading of GSM-based systems and works effectively for sensor readings, tracking and fleet management.

Sigfox is building out the infrastructure from the top down, and handing APIs to their customers. It is a proprietary network and protocol and is meant for remote meter reading, but can be used for any remote data uplink. It is low speed and low power, but also long range. Sigfox is, therefore, more like connectivity as a service. It has been developed to supply wireless connectivity for devices such as remote sensors, actuators and other M2M and IOT devices. Sigfox has a very particular approach in that it only offers public LPWAN possibilities. Although the number of private LPWAN connections has been higher so far and dominated by LoRa and LoRaWAN, it is estimated that by 2023, public networks will capture over 70% of LPWA connections.

Introducing the IOT decision-making tree: Choosing the right IOT protocolThe IOT decision-making tree begins with the things that matter most to your business. It is about making your data come together in new ways. We ensure we are always expanding and learning about ways to keep clients connected. The question of what connectivity to use is based completely on the use case of the IOT product you are creating, and this is based on what your user needs.

Contact Polymorph if you have any questions about what connectivity or product you should be using.

Source: itweb.co.za


Don't miss IoT in Action Amsterdam - January 27
IoT in Action Amsterdam 2020 banner

Related posts

Show Buttons
Hide Buttons
X