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.

 20170206_Symphony Link vs. LoRaWAN_Reverse

Written by Brian Ray

Brian is the Founder and CTO of Link Labs. As the chief technical innovator and leader of the company, Brian has led the creation and deployment of a new type of ultra long-range, low-power wireless networking which is transforming the Internet of Things and M2M space.

Before starting Link Labs, Brian led a team at the Johns Hopkins University Applied Physics Lab that solved communications and geolocation problems for the national intelligence community. He was also the VP of Engineering at the network security company, Lookingglass, and served for eight years as a submarine officer in the U.S. Navy. He graduated from the U.S. Naval Academy and received his Master’s Degree from Oxford University.

Related Blogs

Asset Tracking, BLE Asset Management healthcare, Asset Tracking, AirTag, RTLS, iiot, equipment and tool tracking, gps, manufacturing, logistics, cost effectiveness, Differentiation, Data Utilization

Recap: Why Choose Link Labs for Asset Tracking and Monitoring?

Asset Tracking, BLE Asset Management Scalability, Cloud Native Applications, containers, Flexibility, Resiliency, Dev Ops, microservices

Cloud Native Applications on the Rise

Asset Tracking, BLE Asset Management proof of delivery, logistics, efficiency, tracking, Omnichannel Tracking, Returnable assets, employee efficiency, sustainability, lower stock, production line shutdown

2022 IoT Logistics Trends

Subscribe to Link Labs' blog weekly update!


Subscribe to Link Labs' blog weekly update!