Introduction to IoT: Everything You Need to Know About LoRa and LoRaWAN
You can’t explore the world of IoT for long without hearing about LoRa and LoRaWAN. These technologies have been growing in popularity for a couple of years now, but what exactly are they and how can you use them?
What is LoRa?
LoRa is short for “long range”, and refers to a radio technology specifically designed to operate at long range while using very little power.
Its proponents claim that LoRa works at distances of tens of miles, and can run for years on a single coin cell!
Well, you might want to take such claims with a pinch of salt, but it’s certainly true that the power consumption and range of LoRa radios is very impressive.
But is LoRa Too Good to Be True?
For line-of-sight applications on mountain peaks or aboard weather balloons, some of the actual reported figures are very impressive, in the order of 10km or even higher. Of course, as with all wireless technology, the ideal scenario often breaks down badly in the real world.
But even in challenging environments, such as indoors, even between adjacent buildings, LoRa can perform very well: certainly better than competing technologies such as WiFi or ZigBee.
It’s always very hard to quantify wireless performance. As with all radio communication, the exact range you can expect to receive will vary greatly depending on many factors, including, but not limited to:-
- obstacles such as buildings, trees and terrain
- antenna design, power and elevation
- atmospheric conditions
- channel frequency
- chosen data rate
- interference, and contention from other devices
So will it work for you? Unfortunately there’s no way of knowing in advance. If you have a clear LoS between your antennae, then it will almost certainly work. If not, then you’ll have to try it out.
I’ve personally seen LoRa cope well in situations where no similar technology would stand a chance. For example, I’ve had a usable signal (at very low rate) at 3km range with absolutely zero line of sight over rural terrain quite dense with trees in full leaf.
But with LoRa there are more factors to consider than pure range…
Low Power Performance
The other USP of LoRa is its very low power demands.
LoRa was designed with IoT in mind. A node may be solar- or battery-powered and only wake up once an hour to send tiny data packet containing a temperature measurement or similar.
In this use case, a LoRa node would spend 99.9% of its time in an ultra-low-power sleep. The radio has a feature called channel activity detection (CAD) which can wake it from a low power state when it detects the start of a message, without performing an expensive RSSI scan as other radios would.
In addition, LoRa radios are very sensitive, and able to receive signals many times weaker than other wireless technologies. Increasing receiver sensitivity rather than transmitter power enables the system to operate at lower overall power levels.
But… and there had to be a but, didn’t there? All this increased performance at low power levels does come at a significant cost: data rate. The average bit rate you can expect to achieve with LoRa is probably several orders of magnitude lower than you would get with other wireless technologies.
The factors affecting the practical data rates you can expect are discussed below.
Effective Data Rate of LoRa
The effective raw data rate you can expect to achieve will be affected by four factors:-
- Low headline data rate
- Half-duplex transmission
- Duty cycle
- Transmit power
Low Headline Data Rate
Compared to peer technologies, the biggest difference you’ll notice with LoRa is that even the advertised data rates are rather low. Depending on the exact channel configuration, LoRa can typically only handle raw data rates of between 250 bit/s and 11 kbit/s in Europe, and between 980 bit/s and 21.9 kbits/s in the US.
This is far lower than we have become accustomed to in small wireless systems. But when you read the small print it gets worse. A lot worse…
Even if you’ve never actually used a walkie-talkie, you probably know from films and TV that each speaker must take turns and say “over” at the end of each transmission. If they didn’t, they would both be transmitting at the same time and wouldn’t hear the other person.
A LoRa radio works the same way. It can only transmit or receive on a given channel. It cannot do both at once, which makes the radio link half-duplex. This halves the data rate of the channel, assuming both uplink and downlink are used to send data. (Which may not be true. If the link is only used for one-way communication, being half-duplex would not matter.)
So if the maximum raw data rate is 11 kbit/s, then for bidirectional communications the effective data rate is halved to 5.5 kbit/s
Because LoRa operates on unlicensed bands, it’s subject to some fairly stringent government regulations. In most jurisdictions, including Europe, the most severe of those is called the duty cycle. (Things are different in the US, where the FCC imposes frequency hopping rules instead. I won’t cover those here.)
The duty cycle is the percentage of time a device is allowed to transmit for.
The regulations are slightly complicated when you consider all the possible LoRa channels, but for most purposes the maximum duty cycle in the EU channels is defined as 1%.
So if a device was to transmit continuously for 1 second, it must then remain silent for the next 99 seconds.
This scheme provides a kind of ad-hoc, randomised time-division multiple access (TDMA). It’s a way of sharing a limited resource (a radio frequency band) between multiple devices. TDMA is used in many radio systems, including cellular networks, where devices usually transmit in precisely timed slots.
Because LoRa does not guarantee message delivery, and includes an error-checking code to detect receive errors (see below), this ad-hoc form of TDMA works purely on the statistical likelihood that if devices only transmit for 1% of the time then there would have to be a fair number of devices sharing the same channel before collisions become a big problem.
So that’s why the duty cycle is a good thing, but it definitely presents a severe restriction on throughput. The 1% duty cycle reduces the effective data rate of 5.5 kbit/s calculated above to a mere 55 bits/s!
But that would only be meaningful for applications wishing to send and receive data continuously. LoRa is not designed for that use case, but rather for small packets of data sent infrequently, so in reality the duty cycle should not pose a major problem for a well-designed system.
A final restriction is the government limit on the maximum power you can use when transmitting in the LoRa bands. Again, this varies by jurisdiction: in Europe is is limited to 25 mW, and in the US it’s significantly higher at 501mW.
For hobbyists and others using readymade LoRa modules, this is not something you’ll necessarily have to deal with, but if you’re building your own antenna or gateway then you should be aware of the laws.
LoRa Channel Parameters
The parameters of a physical LoRa link can be adjusted to compensate for signal conditions, required data rate and power constraints. The possible parameters are the channel number (frequency), the channel bandwidth and the spreading factor.
Spreading Factor (SF)
The most significant parameter is the spreading factor. Increasing it will reduce the data rate but increase the range.
A major advantage of using different spreading factors is that different devices can transmit on the same frequency at the same time, and if they’re using different spreading factors then they will not interfere with each other. This is a key feature of spread spectrum modulation, allowing many devices to operate on the same channel frequency.
The bandwidth of most LoRa channels is 125kHz. On the EU863-870 (868MHz) band there is a single channel that can operate at 250kHz, and that’s where the headline 11kbit/s data rate can be achieved. Almost all other channels operate at 125 kHz, giving a maximum data rate of 5.5 kbit/s.
Note: Normally, hackers and developers casually use the term bandwidth when talking about a network’s data rate, measured in bits/s. In wireless systems (and, indeed, communications in general), this can lead to confusion because the term bandwidth specifically refers to the width of the transmission channel, measured in kHz or MHz.
Practically speaking, if a communications channel has a higher bandwidth then it will have a correspondingly higher data rate, so the casual use of the term does hold true.
But to avoid confusion, I’ve avoided using the term bandwidth when I mean data rate.
Immunity to Interference
LoRa’s combination of multiple frequency channels, different spreading factors and a very low duty cycle have the great advantage of allowing a large number of devices to operate in the same physical area.
In addition, the operating frequency of LoRa is relatively low compared to, say, WiFi. It is much closer to the old 2G cellular frequencies. This gives improved penetration of buildings and other obstacles, resulting in large operating area.
This increased range is a good thing, but also a double-edged sword because it increases the likelihood of devices interfering with each other.
This is especially important when you realise that LoRa may not be the only protocol using the band. Since it operates on an unlicensed band, there may be other signals using different modulation schemes present on the same frequency. For example, on the EU 868 MHz band, other protocols such as ZigBee and Sigfox can be present.
Once the frequency spectrum starts to get crowded, interference will inevitably occur. LoRa is designed with this in mind. For those occasions where a packet collision occurs, or some interfering device drowns out the signal, LoRa has built-in error correction in the form of CRC codes. This will cause corrupted data packets to be rejected by the receiver.
LoRa is Only the Physical Layer
The LoRa protocol, as you might find implemented on a module for Arduino or Raspberry Pi, defines only the physical layer (PHY) of the network.
This is an important distinction. It means the device is not directly addressable, which is OK for a network of two devices such as this very handy pair of ESP32 modules. Any more than two, though, and you’ll need some way for each node to know which data packet is for them.
In networking, the physical layer is the lowest layer of the protocol stack. For a multi-node network, other layers need to be added above PHY in order to allow device addressing, packet routing, guaranteed delivery, etc, etc.
What is LoRaWAN?
LoRaWAN is a protocol built on top of LoRa to enable device addressing and management over a wide area. Crucially, it adds the MAC (Media Access Control) layer. It also defines an application layer above that, and security protocols.
I’m not going to go into too much depth here. The Things Network website already has a lot of clear, easy-to-read information on LoRaWAN.
Briefly, though, LoRaWAN is a more lightweight protocol stack than others you may be familiar with. It simply defines the MAC and Application layers, and completely eliminates the Network (IP) and Transport (TCP) layers of TCP/IP, for instance.
The MAC layer is what makes network devices addressable. IP addresses are Internet Protocol addresses, used globally, but on a local network your computer is identified by your ethernet or WiFi MAC address. In theory, every computer (or rather, network adapter) in the world has a unique MAC address.
MAC stands for Media Access Control, and it’s responsible for two main things:-
- Device addressing
- Channel access control
LoRaWAN MAC Layer: Device Addressing
LoRaWAN defines several layers of addressing, the most important being the device address. The Things Network defines it thus:-
LoRaWAN devices have a 64 bit unique identifier (
DevEUI) that is assigned to the device by the chip manufacturer. However, all communication is done with a dynamic 32 bit device address (
DevAddr) of which 7 bits are fixed for The Things Network, leaving 25 bits that can be assigned to individual devices, a procedure called Activation.
LoRaWAN MAC Layer: Channel Access
Channel access in LoRaWAN is achieved by having three classes of device that can access the radio channel in defined ways:-
- Class A: can transmit uplink at any time, but only listens for downlink responses in two predefined windows after transmitting;
- Class B: Like Class A, but in addition can receive downlink messages at regular scheduled times;
- Class C: Also extends Class A but listens all the time it’s not transmitting.
Class A devices use least power; Class B uses slightly more, and Class C uses significantly more.
Security is obviously a big deal nowadays, so LoRaWAN has been designed with security in mind.
Network Session Keys are used to validate messages with the LoRaWAN network.
In addition, Application Session Keys provide end-to-end encryption from each node to the application server endpoint. All payload content is encrypted.
Limitations of LoRaWAN
Before deciding if LoRaWAN is suitable for an application, you should bear in mind the following:-
- LoRaWAN requires a gateway such as this one, which aggregates packets from many LoRa nodes and forwards them to another network, usually TCP/IP.
- Use short binary messages, not JSON/XML or anything else heavily text-based;
- Do not transmit more often than every few minutes at the most;
- Keep the data rate as high as possible to shorten the duty period;
- Downlink messages are discouraged in LoRaWAN: it’s recommended they’re avoided if possible, or kept to the bare minimum otherwise;
- Message confirmations are actively discouraged, largely because it requires downlink messages. Systems should try to work without confirmations;
- LoRaWAN nodes cannot communicate with one another, so peer nodes deployed on location cannot directly share data.
Much of the above applies to the underlying LoRa technology, too, but some of it is because of LoRaWAN’s potentially global reach, notably the downlink/confirmation restrictions. Public LoRaWAN implementations such as The Things Network have to think about the load on gateways and backend infrastructure as well as airtime issues.
Other LoRa Protocol Stacks
There are other protocol stacks built on top of LoRa. For private networks and industrial applications that do not need global, public access, network implementors are free to use whatever technology suits their needs.
Commercial products such as Symphony Link are designed to work with LoRa devices but to solve different problems, such as mesh-like networks, guaranteed delivery, efficient TDMA, and so on.
Hobbyists can also build their own protocols. If the burden of using LoRaWAN is too great for your needs, or you don’t want to buy an expensive LoRaWAN gateway, I’d recommend you start with some cheap LoRa modules and make them do what you need.
Coming Next: A Budget, Single Channel LoRa-MQTT Gateway
In my next article, I’m going to show you how to build a budget, single channel LoRa-MQTT gateway. This will allow a DIY MQTT broker to subscribe to one, and then several, LoRa nodes.
Don’t forget to join my mailing list so you can be first to hear about this project!
Thanks for Reading & Get in Touch
Have you made a great project using LoRa or LoRaWAN? I’d love to see your photos and hear your stories. Please send me feedback, either by leaving a comment below or by contacting me directly.
You can also follow me on Twitter.