Limitations of using LoRaWAN- impact on security, cost, and reliability.
Many Link Labs customers use LoRa for wireless connectivity in their control-centric projects. LoRa is a great choice for such applications because the long range, high link budget nature of LoRa means that a large area, such as an entire building, campus or several city blocks, can be covered with a single gateway.
Most customers have tried to use the standard LoRaWAN protocol for their application before deciding to use Symphony Link, which is our alternative private network protocol also built with LoRa, optimized for industrial sensing and control, and very customizable. Here are the reasons they choose Symphony Link:
Multicast is necessary for controlling multiple points at once. You can imagine that for many control-based applications, controlling more than one device at a time is important. There may be need to switch on all the streetlights on a block or lock every door in a hallway in an emergency. Demand response applications also almost always require multicast control as well.
In LoRaWAN all messages are unicast (one-to-one).
This is because of how encryption, authentication, and provisioning is handled in LoRaWAN. A unique set of keys/IDs are preconfigured for each endpoint, and then stored in the LoRaWAN server. The only way to address multiple nodes at once with LoRaWAN is through a work around where the node identity and key set is shared between multiple nodes. In that case, the LoRaWAN network thinks it is transmitting a downlink message to a single node, but in reality multiple nodes can decrypt it. This is problematic because it violates the security architecture of LoRaWAN, prevents proper layer 2 functions (like message acknowledgments), and requires the customer to handle addressing and other functions at the application layer. (See page 11- In this LoRaWAN Security Article)
In Symphony Link, there are multiple session keys established for each node, a unicast key, and one or more multicast keys. This allows nodes to be addressed individually, in groups, or across the entire network. This powerful innovation has made Symphony Link a great tool for customers with control centric use cases. It is also what enables Symphony Link to support over-the-air firmware upgrades of endpoint devices.
Cost of installation: Repeaters
Repeaters are devices that relay signals between end nodes and gateways, when a direct connection is not possible.
There is no concept for repeaters in LoRaWAN.
While there are claims that repeaters are not necessary because the range of LoRa is so great (See #11 in this article), we disagree. Deep building penetration with a comfortable signal margin would require multiple LoRaWAN gateways in many cases.
Symphony Link repeaters function by fitting the frame header, downlink, uplink, and relay frame inside of one Symphony Link frame by using one higher spread factor. This decreases the link budget of a repeater by 3 dB, but has no effect on latency.
For applications like street light control or demand response, it is a very cost efficient architecture to have one central gateway connected to one repeater per neighborhood. Those repeaters only need power (even solar power), and not a data connection. Some of our customers combine a repeater into an endnode, so that they can function both as a controller and a repeater.
Reliability: Multi-Network Interference and Acknowledgements
LoRaWAN was designed as a protocol for a single operator large scale network. Since it is instead being used by multiple parties in different ways:
All LoRaWAN traffic from any network interferes with every network in range.
Since all LoRaWAN channels are shared, any LoRaWAN packet is seen and demodulated by all gateways in range, no matter who owns them. If there is a carrier operated LoRaWAN network and several private LoRaWAN networks operating in an area, performance of all networks will suffer due to collisions. For control applications this is especially troublesome, as reliability is an important consideration.
Symphony Link uses a different modulation scheme than LoRaWAN, and thus LoRaWAN traffic does not interfere with Symphony Link. Additionally, Symphony Link networks automatically manage channel allocations to prevent co-channel interference between networks. Symphony Link can operate 96 simultaneous networks in the 900 MHz band without downlink interference.
Since all Symphony Link transactions are acknowledged, both uplink and downlink, any messages that are missed will be repeated until they are received.
Latency. Class C downlink in LoRaWAN is fully asynchronous, and if one-to-one control is an architecture that works, the latency is less than Symphony Link. This works for AC powered applications, since for Class C LoRaWAN, the receiver runs continuously, drawing ~10mA. Symphony Link uses a 1 or 2 second frame interval so latency can be as much as 2 seconds for a control message, but by using wakeup channels in Symphony Link, battery powered controllers are possible. This is a key feature for locks and other battery powered controllers.
Other Symphony Link Features.
While not necessarily as important to control applications, it is worth mentioning that some customers require these Symphony Link unique features as well:
-Time Sync- Network-wide time broadcast allows time stamping and time based applications to run at the end point. This can be important in control applications as well. That way lights can be programmed to turn on/off at certain times, instead of commanded every time.
-Firmware upgrades over the air- change application firmware after deployment.
-Auto-provisioning and encryption- no per-device key management in production.
-Real Time Power and Data Rate Control- Allows nodes to stay connected if RF conditions change quickly, and solves the LoRa near-far problem, in which close nodes prevent far nodes from being heard.
-Quality of Service- Allows important messages to get priority over lower priority messages in congested networks.
In conclusion: We understand the appeal of using the free LoRaWAN system for IoT applications. In the case of control applications, most customers will find the architecture limiting, as it was not designed for this purpose. Symphony Link was designed with control as the primary use case. If you are interested in learning more about Symphony Link, please get in touch.