V3 with ADR violating the fair use policy?

[mat89]

Hello collegues

I started to do some tests with ADR, which is enabled by default by TTNv3.
My nodes are based on arduino-lmic v4.0.0 (GitHub - mcci-catena/arduino-lmic: LoraWAN-MAC-in-C library, adapted to run under the Arduino environment).
My tests below are based on their example arduino-lmic/ttn-otaa.ino at master · mcci-catena/arduino-lmic · GitHub to have an easy as possible test setup, without any sleep statements or something else.

The fair use policy from TTN is:
Uplink: 30 seconds per node per 24 hours
Downlink: 10 messages per node per 24 hours

I did some tests and would like to hear your inputs regarding your toughts on ADR and the fair use policy.
All three nodes are sending an uplink message roughly every 304 seconds, as the payload is small, it is well within the fair use limit of 30 seconds per day, great!
But ADR schedules so many downlink messages, that it exceeds the fair use limit with no user scheduled downlinks at all!

All nodes were online and transmitting every ~304 seconds for 2914 Minutes (somewhat over 2 days).
All nodes and gateways in reach are stationary. The two gateways in reach are registered on the V2 network (ttn.opennetworkinfrastructure.org).

Node01 (ADR enabled with link check mode)
LMIC config option: None, ADR and linkcheckmode enabled by default after OTAA join
Uplink count: 631
User uplink count: 574
Downlink count: 56
Downlink count per 24 hours: 28

Node02 (ADR enabled with disabled link check mode)
LMIC config option: LMIC_setLinkCheckMode(0)
Uplink count: 626
User uplink count: 574
Downlink count: 52
Downlink count per 24 hours: 26

Node03 (ADR disabled with enabled link check mode)
LMIC config option: LMIC_setAdrMode(0)
Uplink count: 577
User uplink count: 575
Downlink count: 9
Downlink count per 24 hours: 4

As you can see, with enabled ADR the downlink count is already violating the fair use policy.
Can we do anything against it?
Do we have to do anything against it, or are the 10 downlink messages per day ‘user scheduled’ downlinks and ‘system scheduled’ downlinks are not part of that count?

As I’m no LoRaWAN expert, I cannot tell if this ‘has to be’ like it is, or if it is either a issue/feature from TTNv3 or from LMIC.
Any hints on this would be great!

Looking forward to an open discussion.

[descartes (Nick McCloud)]

I’ve deferred figuring out what’s going on with LMIC as there are other things to do first.

But someone asked this on Slack and the consensus was that if v3 is going wild trying to bludgeon your device in to co-operation, that’s not a part of the FUP and we shouldn’t overly stress about it.

But it is something for the community as a whole to investigate because it would be sooooo much better if the settings that need setting could be set correctly right from the off.

PS, great detail, thanks for writing it up.

[bluejedi]

IIRC with some test runs with MCCI LMIC v3.3/4.0 on TTN V3 (LoRaWAN v1. 0.3) i did notice more than once, on (rough) average about 10 (or some less) downlinks per 100 uplinks.

These are MAC commands sent by the network server to optimize network operation and should not count as part of the downlink FUP (because not controlled by the user).

I haven’t done any further investigation, assuming this is just part of / normal for V3.

The number of uplinks and downlinks can be easily visualized by using the LMIC-node example application.

[mat89]

I wanted to update here.
After approx 221 hours, it looks like this:

Node01 (ADR enabled with link check mode)
LMIC config option: None, ADR and linkcheckmode enabled by default after OTAA join
Uplink count: 2650
User uplink count: 2560
Downlink count: 114
Downlink count per 24 hours: 12

Node02 (ADR enabled with disabled link check mode)
LMIC config option: LMIC_setLinkCheckMode(0)
Uplink count: 2816
User uplink count: 2556
Downlink count: 264
Downlink count per 24 hours: 29

Node03 (ADR disabled with enabled link check mode)
LMIC config option: LMIC_setAdrMode(0)
Uplink count: 2574
User uplink count: 2562
Downlink count: 51
Downlink count per 24 hours: 6

In the long run, there are less ADR downlinks than in the beginning.
It seems for me that LMIC_setLinkCheckMode(0) will break ADR, so better to let this feature on, if you’re using ADR.