Lora-net/LoRaMac-node

DutyCycle restriction not ETSI compliant

Closed this issue · 1 comments

Discussed in #1563

Originally posted by Waganama September 14, 2023
Hi,

I'm trying to figure out how you implement the algorithm to calculate TimeCredits consumption for DutyCycle restriction.
Before the commit b6f383c (Refactored and improved the way the duty-cycle is managed), there was a mention of sliding window, but i can't find it after.

For now i can only find where TimeCredits for a band are consumed (after a TxDone) but how are they resupplied over time ? For what i understand, TimeCredits for a band is only set to its MaxTimeCredits only DUTY_CYCLE_TIME_PERIOD ms or more after last time the band has been updated.

For me, the actual duty cycle management allow the example below but doesn't respect duty cycle limitation.

example

I was able to reproduce the test explained in my schema.
I disable ADR, force DR_0 and send uplink of 51bytes. Also, i make sure that only the 3 frequencies (868.5, 868.3 and 868.1) are used, so only one Band is consumed which is BAND1.

My device is joined and i send one uplink of 51bytes (time on air is 2.79s approx.).
Then, I wait around 45min
I send uplinks of 51 bytes as many as i can before reaching duty cycle restriction (I was able to send 11 uplinks)
The stack informs that I have to wait 580090ms (~9min). So I wait
After ~9min I resend uplinks of 51 bytes as many as i can before reaching a new duty cycle restriction (I was able to send 12 uplinks)
Conclusion :
In 1 hour (and event in 13min), I was able to send 24 uplinks which take 2.79s time on air to be sent in one band.
Total time of air is 66.96s which is way more than 36s.

image

Can you explain how we can guarantee the duty cycle limitation at any time and why do you not use the sliding window for the duty cycle anymore ?

The duty-cycle management algorithm is believed to be correctly implemented as we have run several verification over time without seeing it break the ETSI rules.

This topic has been discussed several times in the past. Please refer to other open issues or discussions about the details.
We have moved your original Issue to the Discussions tab as there is no evidence yet that there is an issue.

I am closing this newly re-created issue as a discussion can take place under #1563 before deciding if there is an issue or not.

In the future it would be nice if you could post this kind of questions on the project Discussions tab. It is a better place to engage discussions and then we can agree if it is an issue or not.