3

For static objects, LoRaWAN has a very neat 'Adaptive Datarate (ADR)' feature that is key to the scalability of the protocol, it allows the network server to select the fastest uplink datarate compatible with target packet error rate (to conserve energy and minimize collisions), but also to control power and repeat (channel diversity). A lot of the value add of LoRaWAN network servers is here.

However, it only works for static objects as this optimization depends on a stable radio channel. For a moving object (or one with unstable radio channel like a parking sensor when car is parked), what are the best practices to select uplink datarates, power and repeat ? When the motion stops, what should be the initial datarate, power & repeat settings ?

Improve this question
3
  • I'm not sure the case of a parking sensor (where the range of possible scenarios is known, the distance to gateways is fixed, etc.) is comparable to an actually moving device. Also, for a moving device, parameters will probably depend on lot on the environment (outdoors or indoors, line of sight or not, distance to gateways, if the device transmits while actually moving, at what speed, etc.), as well as how much packet loss/delay you can afford and the frequency of the updates and length of data you need. Not sure there's a one-size-fits-all solution here.
    – jcaron
    Oct 6, 2021 at 12:21
  • For a parking sensor, when no car is parked on top, the radio environment is relatively stable, so ADR can be used. but when a car parks the radio link degrades significantly due to large metallic mass. Your are right to say that this is a bit different compared to moving device, because the effect of this mass is somewhat determinictic relative to ADR datarate, so IMHO heuristics like "use ADR datarate as reference, but switch back 1 datarate when a car is parked" could probably work. When in motion, you have no reference so it is more tricky.
    – Olivier HERSENT
    Oct 7, 2021 at 15:12
  • I’d probably go a bit further than “a” car is parked, and go with the fully empty and the completely full scenarios which give you a range of best/worst.
    – jcaron
    Oct 7, 2021 at 16:31

1 Answer 1

Reset to default
1

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.

PARKING SENSORS
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).

Improve this answer
1
  • The strategy is probably also influenced by the region (e.g. in regions like the EU where they are strong duty cycle constraints), amount of traffic, battery capacity, and whether packet loss and/or latency are important for the application or not.
    – jcaron
    Oct 19, 2021 at 21:02

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.