Important Note: Link Labs is the maker of Symphony Link, an alternative protocol for LoRa focused on high-reliability industrial and enterprise use cases. More below.

When looking to understand LoRaWAN and its ideal use cases, and limitations, it is important to understand a bit of history. LoRaWAN (then called LoRaMAC) was developed by Semtech (the sole owner of the LoRa PHY IP) in collaboration with IBM Research (they subsequently left the project). The assumptions when the protocol was designed were:

  • To be used by Mobile Operator Networks
  • In a Single Coordinated Network
  • In the 868 MHz Frequency Unlicensed Band

These are important assumptions, because the resulting protocol has:

  • 1% Duty Cycle Limit (for both all the transmitters AND the gateway)
  • Common frequency channel map
  • MAC (Layer 2) processing only in the cloud

In order to support the 1% duty cycle limitation for the gateway, in particular, many tradeoffs are necessary:

  • Nearly all uplink messages are unacknowledged
  • All gateways in range see all uplink traffic
  • All encryption is handled using static keys

Since all uplink messages are unacknowledged and uncoordinated, LoRaWAN is considered a “pure-aloha” scheme. Such a network has about 18% efficiency. This means that 82% of packets are lost when a LoRaWAN network is fully utilized. Since most messages are unacknowledged, the end node does not know its message was missed. In order to prevent this, some users may transmit more often, thus compounding the problem. Read this easy to understand post about Aloha Networks.

If acknowledgements are added to this system, the efficiency fails even more. This is because whenever the base station is transmitting, it cannot listen. The end nodes do not know that the gateway cannot hear them. Since the gateway can only transmit 1% of the time, this only results in about 1.65% additional packet loss.

Additionally, if someone else is using a LoRaWAN network, all of their traffic counts against your capacity as well. This is because all of the gateways are tuned to the same common frequencies.

Another important consideration for LoRaWAN is the near/far problem. Since LoRa only has 20-30dB of co-channel dynamic range, nodes that are close to the gateway drown out nodes that are far away. This is less of a concern in large MNO networks since ideally several gateways are in range.

Our friends at The Things Network have put together this piece on LoRaWAN Limitations as well.

All that said, the ideal use case for LoRaWAN is:

  • Simple sensors that need to transmit infrequently
  • Missing 5-85% of data at times is okay
  • Little ability to control this device
  • No ability to update device firmware over-the-air
  • Deployed in the dozens to hundreds
  • Can deploy several gateways to cover every node

Some Automatic Meter Reading is a great example of a good use case for LoRaWAN. For meters that update the reading, say once per hour, it does not matter if some readings are missed, as long as some make it through.

Symphony Link solves many of these problems. Briefly, here is how:

1. Framing: The gateway transmits a frame header every 2 seconds, which contains information about which uplink channels are available and when the uplink window opens.

2. Compressed acknowledgements: In Symphony Link, by default, all uplink messages are acknowledged. To accomplish this, all acknowledgements are mixed together into one compressed message that all nodes (that just transmitted) receive.

3. Variable uplink/downlink time slotting: The gateway decides how long it needs to transmit based on queued downlink traffic. It tells nodes when the the downlink window is complete, so that the nodes never transmit when the gateway is not listening

4. Uplink time slotting: Because of the synchronous framing, the uplink windows are slotted which adds about 100% more capacity. This is further increased by adding a variable CSMA window before each transmission.

5. Variable power and spreading factor: The end node receives the RSSI of the framing message of the gateway and dynamically adjusts its power and spreading factor to match the link plus a setable margin factor. This maximizes capacity, mitigates fast fading, and prevents the near/far problem mentioned above.

6. Quality of service: Nodes register a QOS factor (0-15) with the gateway, and this limits their ability to access channels in each frame. It also provides a way for the gateway to limit uplink during times of congestion.

7. Multicasting: By assigning groups of nodes into multicast groups, the amount of downlink needed for control and file streaming is limited.

8. Fixed 256 byte MTU: 12 bytes is too small for most applications. Symphony Link provides a fixed 256 byte MTU, and handles all the sub-packetization (by SF) and retries at the MAC layer.

9. Firmware over the air: Because of the powerful multicast features in Symphony Link, firmware files can be steamed out to nodes.

10. PKI based session AES keys: Symphony Link does not used fixed key encryption. Every node established a secure AES session using Diffie-Helmann, with the node public key provided by the server. This is known industry-wide as the most secure channel encryption scheme.

Want to learn more? Get in touch.


WhitePaper Download CTA

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

How To Use GPS Tracking to Improve Fleet Efficiency

Asset Tracking, BLE Asset Management

How To Leverage Fleet Tracking For Success

Asset Tracking, BLE Asset Management

How Asset Tracking Transforms the Future of Your Company

Subscribe to Link Labs' blog weekly update!

Subscribe

Subscribe to Link Labs' blog weekly update!