search

TheThingsNetwork / lorawan-stack

The Things Stack, an Open Source LoRaWAN Network Server
https://www.thethingsindustries.com/stack/
Apache License 2.0
975 stars 306 forks source link

Default Rx1 delay #277

Closed pdubois22 closed 5 years ago

pdubois22 commented 5 years ago

Summary: By default, the rx1 delay is 5 seconds. Is there any reason why not choosing 1 second which is the default delay in the LoRaWAN spec ?

Steps to Reproduce:

go run ./cmd/ttn-lw-stack --help | grep rx --ns.default-mac-settings.desired-rx1-delay int32 Desired Rx1Delay value Network Server should use if not configured in device's MAC settings (default 5)

What do you see now? 5 seconds delay for rx1

What do you want to see instead? Unless I am missing something stupid, 1 sec

How do you propose to implement this? change default setting ?

...

Environment: master

What can you do yourself and what do you need help with?

johanstokking commented 5 years ago

This is indeed a behavioral change from V2 to V3.

Is there any reason why not choosing 1 second which is the default delay in the LoRaWAN spec ?

Two reasons to increase it from 1 to 5;

  1. Have more time for the application-layer to drive a downlink message response to an uplink message
  2. Have time for network-layer downlink (i.e. MAC answers and acks) across clusters over peering

1 is already an issue with V2. Sometimes we make it, sometimes not. It doesn't always depend on the application; sometimes 50 ms roundtrip is too little, sometimes 200 ms already. One big uncertainty here is the backhaul of the gateway; e.g. ethernet vs 3G. Another is the latency between the network cluster and the application.

2 is a new issue with V3 as we will be getting more clusters, and also combinations of public and private clusters all exchanging traffic using the Packet Broker.

Finally, having more time in the network layer allows for more time for deduplication of incoming messages, also from other clusters. This gives more metadata which gives more accurate location information as well as potentially more downlink paths and making better use of available downlink capacity.

For the record; you can adjust these values on two levels; the network server default (the flag you mentioned) as well as per device. This gives you all the freedom you need. But I would advise against going below 3 seconds, unless you have very good reasons to do so. Note that modern LoRaWAN modules and stacks allow for deep sleep in RX1, while older modules could only sleep, drawing more power with higher RX1 delays.

willhelmx commented 4 years ago

Had a dialog with Tarun today regarding the same problem and i also think that the 5sek gives more time to process the incoming data. However as i suggested this should be put in the Atlassian https://thethingsindustries.atlassian.net/wiki/spaces/TKB/pages/116948996/Downlink+issue as there ought to be many migrations done from V2, and also the use of older types of end devices pre-programmed with 1000Msec Rx1 Windows

/A