Improving LoRaWAN Scalability


By Brian Ray
Link Labs Chief Technology Officer

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

Figure 1. Adaptive data rate and power.

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

Uplink slotting Scheme

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

Variable Uplink Downlink Time Boundary

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.

If you are interested in learning more about the differences between LoRaWAN and Symphony Link, please download our whitepaper:

Symphony Link vs LoRaWAN Guide Thumbnail

  • John Haig

    I think there are many operators that are going to be a little torqued at Semtech when they realize that these limitations are not just marketing fluff. Nice work LL.

  • Jaap Groot

    Interesting read, especially the conclusion part which was not mentioned above:

    “Our study also shows that LoRa networks can scale quite well if they use dynamic transmission parameter selection and/or multiple sinks. For both aspects more work is required as protocols
    for dynamic transmission parameter selection and strategies for useful sink deployment must be developed.”

    For a complete and clear view on scalability do not hesitate to contact [email protected] or visit the open house of the LoRa Alliance on 25 January in London ( – events) to discuss this and other topics with operators who have rolled out large scale networks and projects with LoRa.

    • John Haig

      I doubt many operators with large scale networks have seen more than a few hundreds nodes per cell at this early point. When you have to deploy gateways at the density proposed in this paper, why not just deploy a 3GPP technology? I think this post is more aimed at companies looking to use LoRaWAN for a single gateway application anyways.

    • Brian Ray

      Yes, most LoRaWAN customers (that are not network operators) use a single gateway for their application, which is the primary audience for this post. LoRaWAN SF allocation is not truly dynamic, as it is set statically by the network server, and the gateway must send a unicast message to a node to change it. If the link conditions change such that a node can no longer receive a low SF message, the node will remain until the application layer on the node changes the SF upwards. This is why synchronous SF adaptation has proven very important to scalability.

      • hobo

        > If the link conditions change such that a node can no longer receive a low SF
        >message, the node will remain lost until the application layer on the node
        >changes the SF upwards.

        Just do not change SF setting for second receive window.

        • Brian Ray

          What about for a node that was not requesting an acknowledgement?

          • hobo

            Not sure how is this related to node’s ability to receive a low SF message. In any case the node will open RX1 and then RX2 after sending uplink msg, even if uplink ‘s unconfirmed. If NS suspects that the node is unable to receive the messages with low SF, NS can swith to sending downlink on RX2 with SF12. Yes, some downlinks will be lost in this case, but the node itself will not be totally lost.
            Have I missed something in your posts/reasonings?

          • Brian Ray

            What if the NS is unable to hear the unacknowledged uplink at low SF? That’s the case I’m referring to. Also, in your example how does the node know to switch RX2 to SF12? (which is a very, very expensive transmission by the gateway)

          • hobo

            >What if the NS is unable to hear the unacknowledged uplink at low SF? That’s the case I’m referring to.

            This is not the same as “the link conditions change such that a node can no longer receive a low SF message”. That’s why I didn’t quite catch you initially, sorry for misunderstanding caused.

            >Also, in your example how does the node know to switch RX2 to SF12? (which is a very, very expensive transmission by the gateway)

            SF12 is default SF for RX2, both in US and EU. That’s why I said ‘do not change SF setting for second receive window.’

          • Brian Ray

            How would the following scenario be handled?

            1) NS assigned a node uplink SF of 7. Everything works.
            2) Link conditions change such that only SF10+ message would make it.
            3) Node sends unacknowledged uplink (At SF 7).
            4) Nothing heard in RX1 or RX2 (expected).

            I believe it will take the node a long time to figure out that the NS never responded, since it only send MAC traffic infrequently for un-ack’d messages.

            Perhaps I misunderstand how this works.

          • hobo

            From the spec:
            “If an end-device whose data rate is optimized by the network to use a data rate higher than its lowest available data rate, it periodically needs to validate that the network still receives the uplink frames. Each time the uplink frame counter is incremented (for each new uplink, repeated transmissions do not increase the counter), the device increments an ADR_ACK_CNT counter. After ADR_ACK_LIMIT uplinks (ADR_ACK_CNT >= ADR_ACK_LIMIT) without any downlink response, it sets the ADR acknowledgment request bit (ADRACKReq). The network is required to respond with a downlink frame within the next ADR_ACK_DELAY frames, any received downlink frame following an uplink frame resets the ADR_ACK_CNT counter. The downlink ACK bit does not need to be set as any response during the receive slot of the end-device indicates that the gateway has still received the uplinks from this device. If no reply is received within the next ADR_ACK_DELAY uplinks (i.e., after a total of ADR_ACK_LIMIT + ADR_ACK_DELAY), the end-device may try to regain connectivity by switching to the next lower data rate that provides a longer radio range. The end-device will further lower its data rate step by step every time ADR_ACK_DELAY is reached. The ADRACKReq shall not be set if the device uses its lowest available data rate because in that case no action can be taken to improve the link range. ”

            So yes, it will take a long time to figure out that something is wrong with the link (although the node will not be totally lost).

            I should also say that it is really poor idea to force a node to use SF7 only. Hardly can imagine why someone may need this.

            And, also, for Class C devices, RX2 is open almost permanently, so NS may do some checks too.

            P.S. I amn’t trying to say that LoRaWAN design is ideal or LoRaWAN is better than Symphony or… There’s a lot of (nontrivial) troubles. And it definitely wasn’t designed to be used in small private networks with single gateway 🙂

          • Brian Ray

            Thanks. That’s how I thought it worked. Thanks for engaging. I enjoyed the discussion.

    • Ian M.

      Semtech has marketing police. Ha!

    • hobo

      >5. SX1301 based LoRa gateways have only 8 receiver modems to process simultaneous traffic.

      IMO this is more important topic to discuss. There’s at least one LoRaWAN Certified home alarm and at least one LoRaWAN Certified coppertheft protection module. It seems that eight (or, in worst case, sixteen) nodes continiously transmitting LoRa preamble will make deaf all gateway around (at least, in Europe. Yes, I understand this is illegal, but… Coppertheft is illegal too 🙂

      BTW, I’m not sure that Symphony is tolerable to this type of “jamming”.

      • Brian Ray

        I agree this will “jam” the LoRa modems in the SX1301. This is a more dangerous type of jamming, since it works down to -130dBm+. It is really “software” jamming.

        Symphony Link “hops” the receive frequencies every 2 seconds, so you’d have to be participating in the network as a node to know where to hop your jammer.

      • Miromico AG Wireless

        Thats one of the disadvantages of wireless communication based products and services in general. Any such service can be jammed no matter what technology stays behind. Its only a question of effort (time, skills, money). But when you think about it seams to me like any communication can be jammed or canceled out. For example would a housebreaker at first spray the CCTV and cut sensor wires and power source to the house alarm system. But like in the alarm business in wireless services are always options to detect tempering quite fast.

  • Pat Burns

    It would be great to hear thoughts on LoRaWAN’s over-the-air firmware updating capability. It is difficult to overstate how essential this is in for even a 120 node IoT network, not to mention one with even greater endpoint density.

    • Jaap Groot

      Hi Pat, agreed. As mentioned below please come and meet us to discuss.

      • Pat Burns

        I am a fan of LoRa, but it is just astonishing that viable OTA firmware updates were not part of the requirements gathering process for LoRaWAN. Would love to hear your thoughts here on Brian’s blog …

        • Brian Ray

          The 1% duty cycle limit is probably the reason that it was not designed in. I do agree that it is a big limitation.

    • Brian Ray

      I will save you a trip to London :-). Firmware transfer for LoRaWAN is nearly impossible. This post explains in more detail:

    • Miromico AG Wireless

      Beside that OTA firmware updates are not included in the standard its possible never the less. We develop wireless products and services for our customers since 10 years and ongoing. Over-the-air firmware updating capability was done in 3 out of 4 developments. The 4th developments would have profited from OTA as well but customers decided against an implementation due to short term financial aspects. Not everybody has the insight or experience to see the necessity and financial advantages of OTA updates from the beginning.

      We do LoRa development since about 4 years. We are located in Zürich, Switzerland and have close contact to the community of Semtech and IBM Engineering who did hardware and LoRaWAN technology. From our insights and experience with LoRa, LoRaWAN, ETSI and FCC regulation its perfectly possible to add OTA firmware updates to LoRaWAN. But besides that we are member of the LoRa-Alliance we can’t effort to develop an implementation on our own and push it free of charge into the standard. That is things that only large companies can do. The fact that Link Labs has managed to include it into their own stack shows that its possible. And the 1% duty cycle under ETSI is a oversimplification. Just have a look into ETSI EN 300 220-2 V3.1.1 (2016-11) starting from page 24 and you get the idea that there are multiple options.

      Our first LoRa-based development was a bidirectional Ultra Long Range High-Performance radio link for First Person View Drone enthusiasts. Tested distance is 100 km or 62 miles. This development was for a customer and is leading the drone racing market as well as the segment of long range enthusiasts. Naturally the firmware is updated OTA. It provides a 150 frames per second update rate under 868 MHz ETSI regulation.

      Another large scale development was a wireless and battery powered door locking system for a leading Swiss door components company. The system scales from 1 door up to tenths of thousands of doors distributed over multiple continents. All wireless components get new encrypted firmware via OTA updates. That is working in the field since about 6 years now under stringent 868 MHz ETSI regulations.

  • Tidratec

    So how Symphony Link works when the system needs several gateways?
    Are the gateways interfer with each other?
    How nodes know to which GW to speak?

    • Brian Ray

      Nodes are always joined to one gateway or repeater at a time. Gateways transmit their frame header on 1 of 96 channels (US) or in a TDMA slot (ETSI). The gateway tells the nodes where the uplink channels will be in that frame.