2

Consider a LoRaWAN in which multiple nodes are attached to gateway. The page at link-labs states that, once a message has been delivered, there is no acknowledgement of receipt. However, nodes in LoRaWAN can request acknowledgements. When acknowledgement is requested cloud chooses gateway to respond at a fixed time. But, while that gateway is transmitting back to the node, it stops listening to everything else. So if an application needs a lot of acknowledgements, it will very likely spend more time transmitting acknowledgements than listening, which will eventually lead to a network collapse.

So is there any solution to avoid such collapse?

Improve this question

3 Answers 3

Reset to default
3

As you correctly stated in the wording of your question, the time a gateway spends on transmitting LoRaWAN Downlink Messages is a very expensive network resource. In practice there are several technics applied to keep the time gateways spend on sending downlink messages low:

  • Applying a Duty Cycle rule for downlink messages. You can set a rule on your network server that says that no transmitting devices (neither gateways nor end devices) are allowed to spend more than a certain percentage (e.g.: 1%) of the total time. If an end device can be reached through multiple gateways, the network server can select the one that has more free duty cycle left.
  • RX2 Optimization:
    Instead of using the RX1 receive window with a low data rate (e.g.: SF12) for downlink messages, the Network Server can prefer using the RX2 receive window with a higher data rate (e.g.: SF9). This would shorten the time-on-air of downlink messages. This technic can be effectively used in the EU868 band since in EU the TX power of the RX2 receive window is 500mW while in the RX1 receive window it is only 25mW. (TX with SF12,25mW has similar link budget to TX with SF9,500mW)
  • Uplink packet repetition:
    You can configure your end devices so that instead of sending confirmed uplink messages (that are asking the GW to send downlink confirmations) you rather make your end devices repeat every uplink messages 2 or 3 times with the same uplink frame counter value. These packets will be deduplicated by the Network Server and this way the packet error rate will be significantly lower making UL confirmations not necessary.
  • Installing a more dence GW network:
    This always helps since end devices will be closer to gateways that allows the gateways using higher data rate for the communication. Higher data rate always results in shorter time on the air.
Improve this answer
2

In a LoRaWAN network, any device can ask for an acknowledgement, but with the tacit understanding that it's entirely up to the "network server" to decide if an acknowledgement will be sent or not. The rule for efficient LoRaWAN network management are not part of the LoRaWAN specification and depends on the know-how of the people coding, configuring and operating the network server. The LoRaWAN specifications only give you commands, rules and levers to act on.

For example, any collapse, or significant performance reduction of a network can be avoided by:

  • categorizing devices in several "Quality of Service" classes
  • selectively acknowledging devices and prioritizing the one that are considered "more important"
  • limiting the number of ACKs a device can ask and receive every day
  • having rate limiting rules (per network, per gateway) and dropping ACK attempts for low-QoS devices as soon as some threshold is passed
  • not always using the "best" gateway to send ACKs, but another gateway "in range" of the target device, but one that is less "critical" (eg. see little or no traffic that is not also seen by at least another gateway)
  • shutting down traffic for misbehaving devices
  • having enough gateways for proper spatial redundancy
  • using more aggressive "Adaptive Data Rate" rules for low-QoS devices

A 'naive' network is good enough for lots of simple cases, but if you want scalability, reliability and some immunity to attacks, you have to go way beyond what comes "out of the box" of most LoRaWAN network servers. It's no rocket science either, we're talking good real-time metrics, Pythons scripts and some human supervision :)

Improve this answer
0

If the application running on network requires ACK for every downlink, then it can choose to downlink CNF messages.

End-devices can piggyback the application payload along with ACK bit in further uplink. This can be done at intervals desirable for the end-device.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.