3

The LoRaWAN spec defines the LinkADRReq MAC command with a field (NbTrans) specifying the number of requested repeated transmissions of every frame. Actility claims that their ADRv3 algorythm uses that field to improve the packet error rate by requesting every frame to be transmitted multiple times instead of just increasing the Spreading Factor.

I have several concerns about that approach:

  • What is the impact of repeated transmissions on the capacity of the LoRaWAN Network?
  • What is the impact of repeated transmissions on the battery life time?
  • Why is a repeated SF9 transmission better than a simple SF10 transmission?
2

What is the impact of repeated transmissions on the capacity of the LoRaWAN Network? Intuitively, it would seem that repeat transmissions just load the network... and this is what will happen with a basic network server.

However it is more subtle, because a high-end network server will optimize jointly power, channel diversity (repeat) and datarate. What you are more likely to see on such optimized network server implementation is that the network server will consider that because of the channel diversity introduced by the repeat, it can also increase the datarate at the same time. So you get more packets, but shorter.

What is the impact of repeated transmissions on the battery life time? Same answer as above. Not all network servers are equal. Some will just double packets and drain the battery twice as fast, but optimized implementations might actually save power by leveraging the improved channel diversity to reduce power and time on air (increase datarate).

Why is a repeated SF9 transmission better than a simple SF10 transmission? Because of the unlicensed nature of LoRaWAN, and also absence of listen before talk in most implementations, collisions on a given channel happen relatively frequently, particularly when the network is loaded or in presence of other technologies sharing the spectrum. If the probability of such collision is say 10%, then the probability of collision occurring on two consecutive Tx on different channels is only 0.1*0.1=1% . So the gain of channel diversity is very high. The network server can use some or all of this gain to reduce Tx power or increase datarate (which make LoRaWAN more sensitive to noise, but decreases time on air and therefore energy per packet).

1

Funny how I had never seen that setting, I always though retransmits only occurred for confirmed packets. That's similar to the Sigfox strategy. Note how the wording is different between e.g. 1.0.3 and 1.1.0, though.

Multiple shorter transmissions have several advantages:

  • Each transmission occurs on a different channel
  • If there's a downlink, retransmissions stop
  • Short noise bursts / collisions have less of a chance of affecting a short frame than a longer one.

The issue is that you can use more airtime, and in regions with (very) limited duty cycles, this can be an issue. 3 transmits at SF9 probably take more airtime than one at SF10. If you have a larger SF difference then it's better (3 retransmits at SF7 use a lot less airtime than 1 transmit at SF12!).

The other drawback is that (in theory), slower data rates result in a lower sensitivity threshold, so when it's purely a link budget issue, retransmits at faster data rates will not help. But the SF-to-distance relationship is often more complex once you take into account obstacles, reflections and noise.

I haven't gone into the details of timings of the retransmits (can't find anything on the topic in the spec?). I suppose battery life impact will depend a lot on the type of device/MCU and their ability to sleep between RX and TX phases (rather than stay awake and draw a lot of power), the RX window delay, the number of retransmits, the timing for those (new TX right after RX2, or a longer wait?) and the data rates used.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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