LoRaWAN's ADR has a relative long convergence time, because the network server needs to collect data (SNR, packet error rate, etc.) from several uplink messages before it could calculate the ideal data rate and packet repetition parameters. For example: if a device sends UL messages in every 2 min and the NS needs 10 UL messages to calculate the packet error rate and the average SNR value, it would result in 20 min convergence time. If the NS calculates parameters based on a sliding window of the last 10 messages, this could be bit shorter, e.g.: ~10 min.
If the link budget is changing on the scale of the convergence time, ADR won't bring any benefit and it mustn't be used.
The proper solution to this challenge depends on the actual use case.
A possible solution to manage the changing link budget of parking sensors could be the following:
- When the sensor detects that a car started parking on top of it, it suspends ADR and sends immediately a few (2..5) repeated UL messages (with the same FCount number) using a low data rate so that the backend receives at least one of them. This way the backend will be able to detect that the parking lot got occupied even in case of poor radio conditions.
- When the sensor detects that the car left the parking lot, it resums ADR with the same parameters it was suspended with.
MOVING SENSORS (e.g.: Tracking Sensors)
I case of moving devices, (e.g.: asset trackers) there is no obvious way to predict the actual link budget. In such environment the tracker must use static transmission parameters (e.g.: always the same data rate and the same num. of retransmissions) and the data rate should be so slow that UL messages can be decoded comming from all area the tracker could show up.
IMPACT ON NETWORK CAPACITY
It is very important to notice, that forcing hundreds of frequently talking tracker devices using always the same low data rate at a certain area (e.g.: in the area of a factory) will generate high congestion in the network and increase the packet error rate significantly.
- The solution to this challenge is using randomly selected low datarates. E.g.: instead of using a fixed SF11 data rate, the tracker would randomly select one from [SF10, SF11, SF12] data rates. This lowers the packet error rate because there won't be any collisions between different data rates since they use orthogonal modulations.
- The above mentioned solution can be further improved by applying double transmissions so that the 1st transmission is sent with a randomly chosen high data rate [SF7, SF8] and the 2nd transmission is sent with a randomly chosen low data rate [SF11, SF12]. This helps when the tracker is at a well covered area so that the 1st transmission is successful, but the 2nd UL message is lost due to congestion caused by the longer time on the air.
WHEN SHALL A MOVING OBJECT SWITCH BACK TO ADR?
In case a moving sensor has a built-in accelerometer and can detect that motion has stopped, it may decide to use ADR again. Defining the "motion stopped" event can be done based on a time interval that the device should wait for without motion. When ADR starts again, the initial data rate should be the same that the device would start ADR with at boot time (even.g.:SF12).