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 supply chain, iot, supply chain solutions, accessible asset tracking, digital transformation tools, iot innovation, iot solutions, Digital transformation, iot technology

Top 3 IoT Trends of 2022

Asset Tracking, BLE Asset Management Asset Tracking, RTLS, work in process for glass manufacturing, in transit GPS tracking, glass manufacturing processes, lost shipping containers, asset monitoring, glass manufacturing companies

The State of Asset Tracking in the Glass Manufacturing Industry

Asset Tracking, BLE Asset Management Asset Tracking, outdoor asset tracking, supply chain, asset tracking solution, real-time location, workflow optimization, equipment, tech innovation, industrial iot solution

SuperTag: The Innovative Asset Tracking Solution

For more information on Link Labs products, book a demo

Get Started Now