Casually Chirping Into The World Of LoRaWAN
While wireless communications are unquestionably useful in projects, common wireless protocols such as WiFi and Bluetooth peter out after only a number of meters, which is annoying when your project is installed in the middle of nowhere. Moving to an LTE-based or similar mobile solution can help with the range, but this does not help when there’s poor cell coverage, and it tends to use more power. Fortunately, for low-bitrate, low-power wide-area networks (LPWAN) like e.g. sensor networks, there’s a common solution in the form of LoRaWAN, as in long-range wide area network (WAN).
The proprietary LoRa RF modulation technique that underlies LoRaWAN is based on Chirp Spread Spectrum (CSS). This modulation technique is highly resistant to channel noise and fading as well as Doppler shift, enabling it to transmit using relatively low power for long distances. LoRaWAN builds on top of the physical layer provided by LoRa to then create the protocol that devices can then use to communicate with other LoRa devices.
Courtesy of global LoRaWAN gateway and software providers such as The Things Industries and ThingSpeak, it’s possible even as a hobbyist to set up a LoRaWAN-powered sensor network with minimal cost. Let’s take take a look at exactly what is involved in setting up LoRaWAN devices, and what possible alternatives to LoRaWAN might be considered.
No Free RF Lunch
When it comes to picking the appropriate wireless communication protocol for a project, it’s essential to keep in mind that one gets to pick any two of the following high bandwidth, long distance, long battery life. This is evidenced by for example how amazingly quickly one’s smartphone drains its battery when ramping up gigabyte-sized transfers over 5G mmWave, whereas Zigbee manages a paltry 250 kb/s, but can operate for months on a coin cell, or forever using energy harvesting.
LoRaWAN has a best-case data throughput rate (Adelantado et al., 2017) of a few tens of kilobits per second, depending on the spreading factor (SF). Here the SF is essentially the ratio for how fast the transmitted signal is being sent: a higher SF (up to 12) means a slower transmission and thus lower bandwidth (<1 kbps), but with increased reliability. A lower SF (down to 7) means that the signal is being transmitted faster, thus with higher bandwidth, but with possible loss of reliability.
LoRaWAN does support parity bits, as every fifth bit, and LoRaWAN end devices (‘motes’) generally wait for an acknowledgement from the gateway so that they can retransmit in case of a timeout. Even so, depending on the environment, messages may be lost due to interference, obstructions and competing motes sending data.
LoRa achieves its long-distance performance as mentioned using CSS, which is a form of spread spectrum signaling, but different from frequency hopping (FHSS) or direct-sequence spread spectrum (DSSS), the latter of which underlies Zigbee and some forms of WiFi (IEEE 802.11). Where CSS differs is that it does not use any special encoding, uses a constant amplitude yet modulates in the frequency domain.
LoRa signaling can thus be identified as ‘chirps’ in the RF spectrum, that either increase in frequency (‘up-chirp’) or decrease (‘down-chip’) within a certain band, either 125 kHz or 500 kHz. These can be used to create symbols that are then used to encode LoRa frames, as in the below image.
In this sequence we see 8 preamble up-chirp symbols that identify the start of a LoRa frame, following by two down-chirp synchronization symbols. These are then followed by the payload message. The exact duration of each symbol is dependent on the SF chosen.
Adding The Wide Area
As alluded to earlier, LoRaWAN relies on gateways to act as the interface between LoRa-enabled devices and the wider Internet, translating from LoRa to an IP-based protocol and vice versa. The company behind LoRa (Semtech) covers the details behind this in their documentation. This includes the security aspect of transmitting the data via LoRaWAN. Assuming end devices are configured with security keys, all traffic between an end device and server can be fully authenticated and encrypted.
Another important aspect with LoRaWAN end devices is that of device classes. Here three distinct classes are identified, which largely depends on their power budget:
- class A: these are devices which wake up occasionally to communicate with a server, transmit some data, etc. This could be e.g. a sensor node.
- class B: devices that interact with a server on set intervals, allowing it to also respond to requests.
- class C: in this category, the device is always powered-on and always communicating.
Just Plug It In
At this point, we should have a clear idea of what the technology behind LoRaWAN entails, and what is needed to set up a LoRaWAN. This raises the question of where exactly we would get a gateway and the other requisite hardware from. Assuming that we’re not looking at setting up a commercial operation here, we are still left with a number of straightforward options to get started.
Essentially the way to go is to purchase some off-the-shelf modules to connect to one’s computing or sensor platform of choice and also create your own gateway, or create an account with one of the open LoRaWANs active in the target region.
Here typing ‘LoRaWAN module’ into one’s search engine of choice gets you a smorgasbord of choice, ranging from Semtech’s SX1301 to Murata’s offerings or one of the dozens of alternatives, obtainable as IC to integrate into your own hardware design, as pluggable module or as entire development board (e.g. STM32L0-based). What the best choice is would mostly depend on the device class and whether it’s intended to be an end device or gateway.
With that sorted, the main question is probably whether to run one’s own gateway or not. If yes, then ThingSpeak (Ruby-based, GitHub) and The Things Stack (Go-based, GitHub) by The Things Industries are two popular options. If that isn’t your jam, or setting up gateways in the area where you intend to deploy the end devices isn’t feasible, signing up to use the ThingSpeak’s network, or The Things Network is an option. This comes with online dashboards as well, removing the need for any locally hosted server hardware.
Not The Only Game In Town
Of course LoRaWAN isn’t the only option here. Another common LPWAN option is Sigfox, though its reach among hobbyists is at this point somewhat limited. DASH7 is an interesting, open protocol, which operates just like LoRaWAN in unlicensed bands. Semtech themselves appear to see DASH7 as complementary to LoRaWAN, with DASH7’s higher data rates making it more applicable to certain scenarios. Interestingly, Semtech notes that hybrid LoRaWAN and DASH7 devices are already being deployed.
The idea behind this is that sometimes DASH7 is more efficient to use as it can complete a transaction faster with its higher bandwidth, whereas other times LoRaWAN ends up being more energy efficient. This is an aspect that is possibly commonly overlooked in comparisons between these different LPWAN technologies.
Meanwhile, Wael Ayoub et al. (2018) identify LoRaWAN, DASH7 and NB-IoT as the three main LPWAN standards. NB-IoT (Narrowband IoT) was developed by 3GPP, with the first specification being frozen in 2016. Unlike the other two standards, NB-IoT uses licensed spectrum. Both NB-IoT and LoRaWAN feature a similar range, though NB-IoT has the advantage of operating in licensed spectrum, meaning potentially less interference from the countless consumer devices that also operate in those bands.
Wrapping Up
Clearly there are more than enough options around for wireless communications to fill a wide range of needs and requirements. At the moment it would seem that LoRaWAN is the obvious LPWAN choice for hobbyists as well as for small commercial deployments, but DASH7 might make sense if you need more bandwidth.
The best part of all of this is probably how easy it is for even those with a modest budget to get started with fun projects that involve leaving sensor and actuator devices around a wide area, enabling exciting options such as farm automation and monitoring. How things will evolve here the coming years will be hard to tell, but with how unstoppable LPWAN appears to be as part of the IoT wave, it’s clear that the options will be increasing rather than decreasing.
Post a Comment