search

Lora-net / LoRaMac-node

Reference implementation and documentation of a LoRa network node.
Other
1.89k stars 1.09k forks source link

OTAA join duty cycle enforced despite LoRaMacTestSetDutyCycleOn(false) ? #397

Closed catsup closed 6 years ago

catsup commented 6 years ago

Hello,

I am performing some OTAA join failure/retry testing for which I am disabling duty cycle regulation.

However, it appears that an MLME_JOIN request still enforces duty cycle regulation for the join requests, adding lengthy delays to the testing. I am using MAC release 4.4-0, tried with regions EU868 and US915.

This appears to be due to the logic in RegionCommonCalcBackOff() and/or RegionCommonUpdateBandTimeOff(), but the reason for doing things the way they do escapes me.

Shouldn't these functions just set TimeOff = 0 for the former, or return 0 for the latter, if duty cycle regulation is disabled regardless of whether this is a join or not ?

nestorayuso commented 6 years ago

yes, the join is subject to duty cycle even if you disable duty cycle for tests.

the join is subject to the back-off procedure.

Read specification chapter "Retransmissions back-off" and this code https://github.com/Lora-net/LoRaMac-node/blob/f42be67be402a40b3586724800771bfe13fb18e6/src/mac/region/RegionCommon.c#L55

catsup commented 6 years ago

I agree that during normal operation, there is a duty cycle to be respected for join requests.

For test purposes however, I would expect a call to LoRaMacTestSetDutyCycleOn(false) to disable this along with the normal uplink duty cycle regulation, as otherwise testing takes way too long.

It seems to me that there is some logic issue in the RegionCommon code preventing this from taking effect. Possibly because the LoRaMac.c::DutyCycleOn variable is used both to check whether the region needs duty cycle and also to disable duty cycle for test purposes - a distinct variable may be needed to completely turn off duty cycle regulation..

mluis1 commented 6 years ago

The channels duty-cycle and join back-off aren't correlated. The Join back-off must be there all the time as per the LoRaWAN specification and per network operators request.

You can always change the behavior on your own implementation for debug purposes. We don't think to change this behavior in the future.

catsup commented 6 years ago

Thanks for the clarification @mluis1 .