The recently published paper, “Do LoRa Low-Power Wide-Area Networks Scale?” by Martin Bor and Utz Roedig of Lancaster University, UK raises the issue of scalability in LoRaWANTM networks.

Their conclusion is that “According to our study presented in the paper current installations based on LoRaWAN do not [scale]. (Section 6)” The paper estimates that about 120 nodes can safely be deployed using a single LoRaWAN gateway, assuming each node transmits 20 bytes every 16.7 minutes. Many connected applications will find this density too limiting.

One of the core features in Symphony LinkTM, the Link Labs LoRa protocol, is a dynamic parameter selection algorithm that improves throughput and reliability dramatically, particularly for networks without multiple gateways.

LoRaWAN’s issues with scalability are the result of 5 factors:

  1. All gateways and nodes use the same channels for all transmissions.
  2. Time on air can be quite long. (up to 2 seconds)
  3. All uplink transmissions are uncoordinated (Pure Aloha)
  4. All gateway transmissions (Acknowledgement and downlink traffic) take the gateway “off the air,” unbeknownst to nodes trying to transmit.
  5. SX1301 based LoRa gateways have only 8 receiver modems to process simultaneous traffic.

The LoRa Alliance (Link Labs is a member) will find it difficult to adequately address these limitations because of the stated goal of maintaining backwards compatibility. It is hard to add organizing features to a network that needs to tolerate legacy, uncoordinated nodes at the same time.

Symphony Link improves scalability in 6 ways:

  1. Frequency Block Hopping
  2. Dynamic Transmit Power and Spreading Factor Selection
  3. Synchronous Uplink Slotting
  4. Variable Uplink/Downlink Time Boundary
  5. Compressed Acknowledgements
  6. Quality of Service
  7. Listen before talk

Frequency Block Hopping

In Symphony Link, each node is paired with one gateway at a time. This gateway advertises the uplink frequencies available to nodes in the current frame. This allows gateways to pseudorandomly use the entire ISM spectrum for uplink traffic, while minimizing uplink collisions with other gateways/networks.

Additionally, if a gateway detects interference in a certain part of the band, it will not place uplink channels in that spectrum.

By using block hopping to create hundreds of uplink channels, Symphony Link nodes are fully FHSS (Part 15) compliant, which means that transmit power can be 1W, if needed. LoRaWAN certification in the US requires a lower power “Hybrid” mode, since LoRaWAN hops over only 8 fixed channels.

Dynamic Transmit Power and Spreading Factor Selection

lora_adaptive_Data_Rate-300x209
Adaptive data rate and power.
 

In order to take full advantage of the orthogonal spreading factors (SF) (gateway can hear multiple transmissions per channel), the node must use the SF with the shortest time-on-air.

Additionally, since LoRa has only 20 dB of dynamic range (ability to hear weak signals in the presence of strong signals), nodes close to the gateway must transmit at less than full power.

Symphony Link nodes accomplish this by measuring the RSSI of the gateway frame header (every 2 seconds) just prior to transmitting. It then calculates the reverse link budget, and adjusts power output and SF to match. It also applies a user settable link penalty to ensure that fast fading does not eat into the signal-to-noise (SNR) ratio.

Synchronous Uplink Slotting

LoRa_uplink_slotting-300x256
Uplink slotting Scheme
 

LoRaWAN is a “pure Aloha” network, which means that nodes transmit whenever they want, without being coordinated. These networks have a maximum efficiency of about 16%. When you add time slots, you can double this efficiency.

However, in order to add slotting, you need to have some sort of synchronizing signal. In Symphony Link, the gateway frame header sets the available slot timing at each spreading factor. Then nodes can randomly choose a timeslot to minimize the chance that they interfere with another node.

Variable Uplink/Downlink Time Boundary

LoRa_uplink_downlink-300x138
Variable Uplink Downlink Time Boundary
 

When a LoRaWAN gateway transmits, nodes in that network do not know that it is essentially unavailable. In Symphony Link we added a variable uplink/downlink boundary so that nodes know when the gateway is available and when it is not.

LoRaWAN addresses this issue with a centrally controlled network server sharing downlink traffic among many gateways, but for use cases without the budget for many gateways, it is unlikely to help.

Compressed Acknowledgements

LoRaWAN acknowledgments are an expensive resource since any time spent acknowledging a message is time that the gateway is not available to receive uplink traffic.

Symphony Link groups all acknowledgements into one highly compressed message which all nodes that transmitted in the previous frame receive.

Quality of Service

Simply put, QOS allows certain nodes to use more resource than others, so that important traffic is prioritized over less important traffic. This way in networks that are congested the most important messages (alarms, etc.) will still get through.

Listen before talk

Finally, Symphony Link nodes check that the channel is clear of any neighbor nodes prior to transmitting. If they do detect another user in that slot, they hop to a new channel instantly.

WhitePaper 20Download 20CTA

 

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

The 3 P's of IoT Innovation

Subscribe to Link Labs' blog weekly update!

Subscribe

Subscribe to Link Labs' blog weekly update!