A recent webinar from ARM and the The Things Network generated an extensive set of questions and answers about using LoRa and LoRaWAN wide area networks for the Internet of Things. More than 700 people joined the webinar, and the recording is available at the bottom of this edited Q&A.
This was triggered by the development of the Mbed LoRaWAN stack - the pull request was opened on November 27th, and should be released in Mbed OS 5.8 - around February 2018.
The L-TEK FF1705, which was used in the webinar, will be available soon from L-TEK. Other development boards you can use (that are available today) are the Multi-Tech mDot EVK and the Multi-Tech xDot. In addition, you can use any Mbed OS 5 compatible development board together with the SX1272 or SX1276 shield. The L-TEK FF1705 hardware design is open source. The design files are in the Mbed HDK.
You can get LoRa modules (MCU + LoRa radio) from around $11 from various vendors (if you buy a few hundred). The SX1272 (just the radio) is selling for $3.90 on DigiKey for 3,000 or more units.
Gateway prices range from $100 to $2,500, depending on your needs. A cheap (and readily available) way to get started is using an IMST iC880A concentrator board ($140) and a Raspberry Pi. If you need IP67 certification, GPS, cellular backhaul, etc. the price goes up. However prices are already coming down. Three years ago the cheapest LoRa gateway was $1,500. A year ago it was $500, and now we're down to less than $100 for indoor gateways. We expect new integrated gateways at less than $50 to become more available in the coming year.
All Mbed libraries for LoRa (regardless of vendor) support both ABP and OTA activation. We strongly recommend OTA, as it's more secure. ARM and The Things Network have been working on a multicast firmware update solution over LoRaWAN. This requires standardization of a few new specifications in the LoRa alliance, which we expect to happen in Q1 2018. An article (and a video) describing the approach is here, and reference firmware is here (based on Mbed OS 5 running on an Arm Cortex-M3 with 32K RAM).
The LoRa radio IP has been licensed to ST and Microchip. We expect them to come out with integrated SoCs at some point.
A device needs different radios as you move from the EU to the USA - 868 MHz radio for EU, 915 MHz for US. Theoretically someone could make a radio that spans both the 868 and 915 MHz bands, but dual FCC and EC certification are incompatible for LoRa radios. The highest throughput in an EU868 plan is 11 kbps (SF7 125 kHz), and in a US915 plan 12.5 kbps (SF8 500 kHz).
We recommend not using 3G for LoRaWAN backhaul, as the default RX1 window occurs one second after a TX window, and 3G latency can make you miss this window.
For development purposes, a gateway with good availability is the MultiTech Conduit with a 915 or 868 mCard. The Things Gateway will ship globally from January 2018 at a lower price. For deployment, there are numerous options: for large scale indoor deployments, besides the Conduit and The Things Gateway, the Kerlink iFemtocell, Tektelic Pico, for outdoor also MultiTech’s, Kerlink’s, Gemtek’s, Tektelic’s, Cisco’s, and so on. Often, you can wire an outdoor antenna to an indoor gateway too. But there are limitations on the maximum antenna gain in many locations.
How fast can a LoRaWAN device move and still be able to communicate with a gateway?
For the PHY layer, this depends on the spread factor that you use. If the coherence time of the LoRa signal is smaller than the symbol time of the LoRa signal, then you'll see high packet loss. According to this paper this happens at 40 km/h for SF12, and at 160 km/h for SF7.
On the MAC layer you can run into issues when using Adaptive Data Rating (ADR) with moving devices. The network cannot reliably detect a good data rate for the device while it's on the move (as this is not re-negotiated in every message). It’s better to use a custom algorithm for changing the data rate based on the RSSI and SNR of received messages on the end-device.
What is the maximum number of devices in a real scenario. For example, if I have a single gateway, what would be the maximum number of devices that can send a small packet five times an hour?
It's hard to determine this as it's very dependent on the data rates that the devices use. A typical LoRa gateway can demodulate eight messages at the same time (on eight different channels). If we assume a one second air time per message (which is probably higher than you'd see in real life), perfect timing distribution, and perfect channel distribution, we’ll see (3,600 * 8 = 28,800) messages an hour, which is 5,760 devices.
Having a higher data rate (lower spreading factor) helps tremendously with cell capacity. Air time for a message on SF7 is under 100 ms. Adaptive Data Rating (ADR) helps here, as it can optimize network load by switching devices to the optimal spreading factor.
On the MAC layer you can run into issues when using Adaptive Data Rating (ADR) with moving devices. The network cannot reliably detect a good data rate for the device while it's on the move (as this is not re-negotiated in every message). It’s better to use a custom algorithm for changing the data rate based on the RSSI and SNR of received messages on the end-device.
What is the maximum number of devices in a real scenario. For example, if I have a single gateway, what would be the maximum number of devices that can send a small packet five times an hour?
It's hard to determine this as it's very dependent on the data rates that the devices use. A typical LoRa gateway can demodulate eight messages at the same time (on eight different channels). If we assume a one second air time per message (which is probably higher than you'd see in real life), perfect timing distribution, and perfect channel distribution, we’ll see (3,600 * 8 = 28,800) messages an hour, which is 5,760 devices.
Having a higher data rate (lower spreading factor) helps tremendously with cell capacity. Air time for a message on SF7 is under 100 ms. Adaptive Data Rating (ADR) helps here, as it can optimize network load by switching devices to the optimal spreading factor.
LoRa 2.4GHz
There's nothing that ties LoRa modulation specifically to the sub-GHz spectrum, so we’re very interested to see how this will work in 2.4 GHz. The big advantage of 2.4 GHz over sub-GHz is that it works everywhere, and there's no regional band differences. In addition, maximum TX power is higher. The downside is that path loss in 2.4 GHz is higher (6-10 dBM over 900 MHz per kilometer), and the band is a lot busier.
What's nice about the SX1280 chip is BLE PHY compatibility, so you can have a single chip handling both BLE and LoRa. That's pretty cool. Will have to see how it holds up, but for smart city deployments under 1 km this could be very nice.
What about 433MHz? LoRa as a modulation is very powerful and does not require usage in the 800-900 bands. Indeed, there are regional parameters defined for the 433 MHz band, but so far there hasn’t been much market demand. 433 MHz would allow for even better range (perhaps 1.5-2 times as much as 915 MHz), due to lower path loss, but this will come at the expense of lower data rates.
Do software-defined radios have a (potential) role in LoRA?
Yes, and there have been demonstrations of this already. What makes it challenging are the current price and intellectual property rights.The Things Conference will cover software-defined radio for LoRa.
LoRa is really the physical layer, and there are different messaging protocols that exist on top of LoRa. LoRaWAN is the standard messaging protocol defined by the LoRa Alliance. Gateways are simply LoRa gateways: the LoRaWAN stack is implemented in the end device and in the network server; gateways are transparent and only translate LoRa traffic to IP traffic and vice-versa. We recommend using LoRaWAN because there is a wide variety of devices and network servers available, and it’s a feature rich protocol with a built-in MAC layer and security mechanisms.
There's nothing that ties LoRa modulation specifically to the sub-GHz spectrum, so we’re very interested to see how this will work in 2.4 GHz. The big advantage of 2.4 GHz over sub-GHz is that it works everywhere, and there's no regional band differences. In addition, maximum TX power is higher. The downside is that path loss in 2.4 GHz is higher (6-10 dBM over 900 MHz per kilometer), and the band is a lot busier.
What's nice about the SX1280 chip is BLE PHY compatibility, so you can have a single chip handling both BLE and LoRa. That's pretty cool. Will have to see how it holds up, but for smart city deployments under 1 km this could be very nice.
What about 433MHz? LoRa as a modulation is very powerful and does not require usage in the 800-900 bands. Indeed, there are regional parameters defined for the 433 MHz band, but so far there hasn’t been much market demand. 433 MHz would allow for even better range (perhaps 1.5-2 times as much as 915 MHz), due to lower path loss, but this will come at the expense of lower data rates.
Do software-defined radios have a (potential) role in LoRA?
Yes, and there have been demonstrations of this already. What makes it challenging are the current price and intellectual property rights.The Things Conference will cover software-defined radio for LoRa.
LoRa is really the physical layer, and there are different messaging protocols that exist on top of LoRa. LoRaWAN is the standard messaging protocol defined by the LoRa Alliance. Gateways are simply LoRa gateways: the LoRaWAN stack is implemented in the end device and in the network server; gateways are transparent and only translate LoRa traffic to IP traffic and vice-versa. We recommend using LoRaWAN because there is a wide variety of devices and network servers available, and it’s a feature rich protocol with a built-in MAC layer and security mechanisms.
LoRaWAN 1.1
The main differences are security enhancements, the introduction of a Join Server, and the formalization of Class B devices. If you want more information on how these work, Johan hosted a webinar on LoRaWAN 1.1; the video is here.
The main differences are security enhancements, the introduction of a Join Server, and the formalization of Class B devices. If you want more information on how these work, Johan hosted a webinar on LoRaWAN 1.1; the video is here.
The LoRaWAN 1.1 specification just came out, and we expect device and network support to become available in the first quarter of 2018. The Things Network Stack V3 will support LoRaWAN 1.1 and will be fully open source from 2018 Q1.
Security
LoRaWAN uses AES 128-bit keys for message integrity code (CMAC) and encryption of application payload (ECB). There are two session keys in LoRaWAN 1.0.x and four in LoRaWAN 1.1, which are issued by a trusted third party Join Server (optional). The network server only works with the network session keys and cannot see application payload nor derive security keys when working with a trusted third party Join Server. See the LoRaWAN 1.1 specification and back-end interfaces document.
Through these keys, LoRaWAN provides message level integrity and payload encryption with AES 128-bit keys on two levels: the network and the application level. LoRaWAN 1.0.x had some security vulnerabilities that have been addressed with LoRaWAN 1.1. See more information about security in LoRaWAN here.
The Application Key is a Pre-Shared Key (PSK) that needs to be kept secret, as it's used to do the initial authentication with the network (in return for session keys). Typically you'd inject the keys in a factory or during distribution in a trusted domain of control or in a secure element. But for development you can just put them in firmware, which is what we did in the demo.
The recommended way to store keys is with a secure element in the end device. Various device makers in the LoRa Alliance are currently working on this, including Gemalto and ST. Since security in LoRaWAN uses symmetric root keys, we recommend using a trusted third party Join Server as well.
The message integrity code (MIC) is calculated through AES 128-bit CMAC (RFC4493). This MIC is appended to each message and both the end device and the network server verify message integrity using the network session key. See the LoRaWAN specification for more information.
LoRaWAN 1.1 uses JoinEUI instead of AppEUI. The AppEUI was typically issued by the device maker, while the JoinEUI will be issued by the Join Server,. Ideally, the device maker provisions end devices securely on a trusted third party Join Server; the JoinEUI typically identifies a batch of end devices. The owner of the end devices then configures the network server to use. So, when a network server receives a join request from a device, it contacts the Join Server based on the JoinEUI. The Join Server sends session keys only to the network server that is configured by the owner of the devices.
BLE 5.0
It's definitely a great step in the right direction. BLE 5 can give a 12 dB link budget improvement over BLE 4, which is a big improvement; in free space it quadruples the distance! This makes BLE 5 a lot more suitable for smart home and smart office solutions where you need more range, and it puts it close to the range of 802.15.4 technologies (like 6LoWPAN and Zigbee). In addition, adding mesh networking to BLE is great, especially with everyone's phone being a potential edge router, which will give extensive coverage.
However, LoRa still offers a much better link budget (maximum 151 dBm for LoRa vs. 108 dBm for BLE 5), so for anything that needs to span more than an office, LoRa is still a better choice. But it's great to see radio technology moving more to long range; better choice choice between radio technologies is good for innovation.
Both have their advantages. The main advantage of LoRaWAN is that anyone can build a network without requiring permission from Sigfox. A downside is that you can only source the radios from Semtech, whereas there are many Sigfox radio vendors. Sigfox radios are also slightly cheaper at the moment. Technically, LoRaWAN has a better link budget from gateway to device, as it was built for two-way communications from the start.
MQTT bridge
MQTT is the developer's primary method of sending and receiving messages on the network. We also support HTTP integration, which is very convenient for web developers. There is also RESTful storage as well as numerous integrations with third party IoT platforms.
Yes, The Things Network works with devices and gateways on any frequency plan, and all data can be grouped together regardless of physical location. The routing regions of The Things Network are also interconnected, so that it’s one big global LoRaWAN network.
The Things Network is provided free of charge and there are no usage restrictions. There is a Fair Access Policy to keep LoRaWAN in general scalable. As it is a community network, there is no service level agreement (SLA) available, but we do provide that for private networks with the same technology through The Things Industries.
The Things Network can be used free of charge. Private networks through The Things Industries come at about 150 euro a month for 1,000 devices.
Arm Mbed OS is provided free of charge under the Apache 2.0 license, even if you ship 1,000,000 devices.
LoRaWAN uses AES 128-bit keys for message integrity code (CMAC) and encryption of application payload (ECB). There are two session keys in LoRaWAN 1.0.x and four in LoRaWAN 1.1, which are issued by a trusted third party Join Server (optional). The network server only works with the network session keys and cannot see application payload nor derive security keys when working with a trusted third party Join Server. See the LoRaWAN 1.1 specification and back-end interfaces document.
Through these keys, LoRaWAN provides message level integrity and payload encryption with AES 128-bit keys on two levels: the network and the application level. LoRaWAN 1.0.x had some security vulnerabilities that have been addressed with LoRaWAN 1.1. See more information about security in LoRaWAN here.
The Application Key is a Pre-Shared Key (PSK) that needs to be kept secret, as it's used to do the initial authentication with the network (in return for session keys). Typically you'd inject the keys in a factory or during distribution in a trusted domain of control or in a secure element. But for development you can just put them in firmware, which is what we did in the demo.
The recommended way to store keys is with a secure element in the end device. Various device makers in the LoRa Alliance are currently working on this, including Gemalto and ST. Since security in LoRaWAN uses symmetric root keys, we recommend using a trusted third party Join Server as well.
The message integrity code (MIC) is calculated through AES 128-bit CMAC (RFC4493). This MIC is appended to each message and both the end device and the network server verify message integrity using the network session key. See the LoRaWAN specification for more information.
LoRaWAN 1.1 uses JoinEUI instead of AppEUI. The AppEUI was typically issued by the device maker, while the JoinEUI will be issued by the Join Server,. Ideally, the device maker provisions end devices securely on a trusted third party Join Server; the JoinEUI typically identifies a batch of end devices. The owner of the end devices then configures the network server to use. So, when a network server receives a join request from a device, it contacts the Join Server based on the JoinEUI. The Join Server sends session keys only to the network server that is configured by the owner of the devices.
BLE 5.0
It's definitely a great step in the right direction. BLE 5 can give a 12 dB link budget improvement over BLE 4, which is a big improvement; in free space it quadruples the distance! This makes BLE 5 a lot more suitable for smart home and smart office solutions where you need more range, and it puts it close to the range of 802.15.4 technologies (like 6LoWPAN and Zigbee). In addition, adding mesh networking to BLE is great, especially with everyone's phone being a potential edge router, which will give extensive coverage.
However, LoRa still offers a much better link budget (maximum 151 dBm for LoRa vs. 108 dBm for BLE 5), so for anything that needs to span more than an office, LoRa is still a better choice. But it's great to see radio technology moving more to long range; better choice choice between radio technologies is good for innovation.
Both have their advantages. The main advantage of LoRaWAN is that anyone can build a network without requiring permission from Sigfox. A downside is that you can only source the radios from Semtech, whereas there are many Sigfox radio vendors. Sigfox radios are also slightly cheaper at the moment. Technically, LoRaWAN has a better link budget from gateway to device, as it was built for two-way communications from the start.
MQTT bridge
MQTT is the developer's primary method of sending and receiving messages on the network. We also support HTTP integration, which is very convenient for web developers. There is also RESTful storage as well as numerous integrations with third party IoT platforms.
Yes, The Things Network works with devices and gateways on any frequency plan, and all data can be grouped together regardless of physical location. The routing regions of The Things Network are also interconnected, so that it’s one big global LoRaWAN network.
The Things Network is provided free of charge and there are no usage restrictions. There is a Fair Access Policy to keep LoRaWAN in general scalable. As it is a community network, there is no service level agreement (SLA) available, but we do provide that for private networks with the same technology through The Things Industries.
The Things Network can be used free of charge. Private networks through The Things Industries come at about 150 euro a month for 1,000 devices.
Arm Mbed OS is provided free of charge under the Apache 2.0 license, even if you ship 1,000,000 devices.
Related stories:
No comments:
Post a Comment