The LoRaWAN wireless specification is a protocol developed by the LoRa Alliance for use with LoRa LPWA wireless technology from Semtech. This protocol was originally designed by IBM Research and Semtech for use by Mobile Network Operators (MNOs) in wide area public networks in Europe. It is now managed by the LoRa Alliance, an alliance of those focused on the use of LoRaWAN for MNO networks worldwide. The specification itself reflects these assumptions.
There are a few design assumptions that make the MNO use cases for the LoRaWAN specification clear:
- All frequency channels are fixed.
The LoRaWAN specification was designed for a single MNO network, so two or more uncoordinated networks sharing the band, will result in layer 2 interference. Read this blog post for more information. - The network is completely asynchronous. Anytime the gateway is transmitting, it cannot listen for uplink traffic, yet the nodes don’t know the gateway’s receiver is offline. This is less of a concern in large MNO networks, since many gateways would (ideally) be within reach. At least one might be in “listen” mode.
There are several other assumptions, including the security model that make LoRaWAN appropriate for MNOs, but we’ll keep this short.
You should use the LoRaWAN specification in your project if both of these are true:
1. You want to connect to a existing LoRaWAN MNO network. Obviously you cannot connect to a LoRaWAN MNO network, unless you use LoRaWAN.
2. You have a low-density, infrequently-transmitting, uplink focused use case. LoRaWAN does best when downlink and acknowledgements are not required. Automatic meter reading (AMR) is a good example. Most meters don't need to be read too often, and in most cases, the number of gateways required to adequately cover a given geography will provide enough capacity for the uplink traffic from the meters. It is best if there are no other networks nearby as well, because as discussed above, two LoRaWAN networks will interfere with each other. EnerTrac/Senet is a good example of using LoRaWAN for heating oil and propane tank monitoring and delivery.
When should you not use the LoRaWAN specification?
1. If you need high reliability. LoRaWAN is a lossy protocol, due to its uncoordinated, asynchronous nature. If multiple LoRaWAN networks are present in your area, additional interference will increase your packet-error-rate. Also, since LoRa has a low co-channel dynamic range, without a closed-loop power control scheme, any nodes close to the gateway will drown out nodes far away.
2. You don’t want to manage every end-node key separately. LoRaWAN currently requires a unique set of keys be programmed into each node at the factory, and then transferred to the server or gateway which will connect to that node. For small deployments, this is not a problem, but for IoT practitioners who need thousands of connections, it quickly increases cost and complexity significantly. MNOs need this level of access sophistication (think SIM card), but for private networks it is a cumbersome design. For a deeper dive on the LoRaWAN key structure and security, check out this independent analysis.
3. You want to fill in coverage with repeaters (such as deploying in commercial buildings). The LoRaWAN specification has no option for repeaters. You just deploy more internet-connected gateways, which can, even using a low-cost DIY gateway, cost 5-10x more than a simple repeater.
4. You need the ability to update firmware over-the-air. With LoRaWAN, you could never multicast enough downlink traffic to effectively update an end node’s firmware. You would need to have a way to physically upgrade the device, or ensure that updates were not needed.
Link Labs has solved these problems, and if you’d like to learn more about Symphony Link, the de facto standard for LoRa Private Networks, click here.
