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

Jennifer Halstead

Written by Jennifer Halstead

Jennifer Halstead, MBA, CPA brings more than 20 years financial industry experience to Link Labs. She began her career in finance within the pharmaceutical industry and has continued in both public accounting and private companies. She passed the CPA exam with the 3rd highest score in the state and completed her MBA with an accounting concentration (summa cum laude). Jennifer has worked with several software companies and has led multiple venture financing, merger and acquisitions deals. She has helped companies expand internationally and has managed the finance department of a startup to 33 consecutive quarters of growth prior to acquisition. After the acquisition, she served as the Controller of Dell Software Group’s Data Protection Division where she managed a portfolio of multiple hardware and software products to scale and achieve over triple-digit growth worldwide in 18 months. Jennifer brings a depth of finance experience to the Link Labs team.

Related Blogs

Asset Tracking, BLE Asset Management Election Integrity, RTLS, asset tracking system, automation, Elections, legal concerns, chain of custody, mail-in ballot

How Counties Can Avoid Public Scrutiny During Elections

Asset Tracking, BLE Asset Management RTLS, supply chain, remote assets, gps, satellite, automation, Satellite GPS tracker

How Satellites Optimize Supply Chains and Logistics

Asset Tracking, BLE Asset Management Asset Tracking, RTLS Solution, RTLS, asset monitoring, rtls asset tracking, Utilization, process efficiencies, manufacturing, Downtime, historic data, predictive data

Why Monitoring Utilization Improves Process Efficiencies

Subscribe to Link Labs' blog weekly update!

Subscribe

Subscribe to Link Labs' blog weekly update!