ADR support

[brocaar]

After the authentication / authorization for the API, I'm planning to look into ADR support. Looking forward to feedback on this, especially regarding the logic which triggers the network to request a data-rate adaption. Please share your thoughts!

[ivajloip]

Hi, I did not have that much time to think about this, but here are my initial ideas.

• When too many packets lost from a device and if nothing better can be done, try to increase the spreading factor. Better things to be done might include adding a new channel to the end-device or disabling a channel that has too much noise.
• When the signal on arrival is not very strong -> increase the spreading factor.
• When a number of times the uplink message has good signal strength and there are not many losses -> decrease the spreading factor.
• When a great number of packets are sent on some channel for some fixed amount of time, try to disable this channel on some of the devices.

[Mehradzie]

Yep. but to be honest most of the decision making is going to revolve around what numbers are too many or too few. Failing to come up with sensible numbers could cause the system to oscillate and that's the last thing you really want.

[yzk0281]

ADR is quite useful for a more efficient LORAWAN. But it seems to be a little bit complicated to realize it, I don't know if other open source LORASERVER already do the function, like TTN. Maybe we can get some useful experience from it.

[sopach]

Hello, by my opinion ADR should work as is described in LoRaWAN™ Specification chapter 4.3.1.1 Adaptive data rate control in frame header (ADR, ADRACKReq in FCtrl). Please when you plan implement this functionality ? We are prepare to test it with you. We have now own full LoRaWan network with own 15 GW and with our own developped nodes base on RFM95 with LMIC 1.5.

[brocaar]

@sopach I think the challenges are more in what should trigger a data-rate change, e.g. below which SNR / RSSI should the network-controller ask the node to change its data-rate. As well the margins, you don't want the network-controller to constantly change the data-rate up and down.

[nestorayuso]

Please consider RSSI / SNR / demodulation margin values in average of the latest 10-25 uplink messages (10-25 or since the last LinkCheckReq MAC command). If in the latest 10-25 messages some of them were lost, the algoritm should take into account to select a lower the data rate. And uplink TX power control can be done too to fine tune the link marging and increase overall capacity, although at the moment it is not implemented in other Network Servers.

[hecko]

+1 for ADR support

[brocaar]

Don’t worry, it will be there hopefully soon (as in weeks). The reason I didn’t start on it yet was because I did not know the best approach for ADR (the concept is simple, but getting the parameters right is important). The past weeks I’ve been asking many people about this and got some great feedback. I will start soon on this.

On 20 Nov 2016, at 11:11, Marcel Hecko notifications@github.com wrote:

+1 for ADR support

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/brocaar/loraserver/issues/55#issuecomment-261769453, or mute the thread https://github.com/notifications/unsubscribe-auth/AAKGeRlqMwdVJzVZIdHq7PGtnwKyqZf8ks5rABzrgaJpZM4JZtvX.

[TimelessNL]

+1

[brocaar]

For anybody interested in the progress, see https://github.com/brocaar/loraserver/pull/105. The functions are there, I still need to do the actual integration and testing.

[brocaar]

This has been released as version 0.13.0, see https://github.com/brocaar/loraserver/releases.