Operation of the duty cycle algorithm?

[jelledevleeschouwer]

Hi @mluis1,

I would like to have some understanding on how the current duty cycle algorithm came about. Because commit ae6f260 does not really say a lot about that.

You've set the duty cycle observation period to 1800 seconds (or half an hour). IIUC, you can have never more than 18s of consecutive time-on-air as a consequence of this. If that period is exceeded the algorithm switches back to the "constant" duty cycle management as mentioned in #520. So if you built up enough credits you can be bursty for 18 seconds, but not consecutively in the same hour. Every half hour, that works.

Now if you would hypothetically set the DUTY_CYCLE_TIME_PERIOD to 3600000, you can be bursty for 36 seconds, but after that you only backoff for creditCosts - bands[i].TimeCredits, which would violate ETSI as you already mentioned in your remark. To illustrate this fact, here is an example:

Suppose a constant message with TOA = 1483 ms is sent repeatedly and consecutively with #define DUTY_CYCLE_TIME_PERIOD 3600000 and ignoring the RX delays for illustrative purposes on a band with 1% Duty Cycle. You could transmit this message 24 times back-to-back, which gives a total TOA of 35592 ms (25 transmissions of this message would exceed the duty cycle of 36 seconds). The time that has passed since the first transmission is effectively the same as the TOA. But now the duty cycle restrictions jump into action with 74909 ms of credits left. This would yield a NextTxDelay of 148300 - 74909 = 73391 ms. After that delay, transmission is allowed again so that adds another TOA of 1483 ms. But now the total elapsed time since the first transmitted message is 1483 + 73391 + 35592 = 110466 ms. This yields a duty cycle of (35592 + 1483) / 110466 * 100 = 33.56%.

So despite reading that remark I still really wonder why you chose this current algorithm and how you came up with it? Why not just wait for the window to have moved beyond 3600 - 35.592 + 1.483 seconds (as applied to the example above) to reopen the opportunity to transmit uplink messages?

Thanks in advance,
Best regards,
Jelle

[jelledevleeschouwer]

Hi @mluis1,

Have you found the time to take a look at this already?

I was also wondering wether you wouldn't violate ETSI duty cycle restrictions using this current algorithm? I've made some brief analysis of the duty cycle computation in RegionCommonUpdateBandTimeOff and what I found is that you would indeed violate ETSI duty cycle of 1% in the EU band with current algorithm. I made a small breakdown of it in some sort of a timing diagram:

The first 12 transmissions are when the band is fully ready for transmission and enough credits are available to transmit those messages back-to-back. The diagram ignores the RX delays and assume that the application is able to schedule the transmission in back-to-back. So ignoring RX delays (in class A) for now, this takes about 17.796 seconds. The transmissions that follow those 12 are when duty cycle limiting algorithm jumps into action. Over a period half an hour this is a zero-sum game losing as much credits as you gain. Over the course of that half hour you indeed won't violate 1% duty cycle. However, when the half hour is over, you still have 1782.204 seconds left within that same hour. Given that the zero-sum game that was happening in that first half hour is still going on, because thats how the algorithm seems to work, you would still be able to transmit messages within that same hour resulting in the total air-time to exceed 36 seconds.

Could you please confirm or debunk this analysis?

Thanks in advance,
Best regards,
Jelle

[mluis1]

It has been quite some time now that we have implemented this algorithm and we don't remember anymore all the details.
We have designed the duty-cycle algorithm by following different sources proposals (#520 issue being one of them).

As per ETSI recommendations the duty-cycle enforcement must be valid over a 1 hour sliding observing window. This means for example that for a 1% duty-cycle one is allowed to have a transmit time up to 36 seconds and be silent 3564 before being able to transmit again.
In the ETSI documents it is also said that one is allowed to not comply to the restriction 5% of the time. (This project does not allow this)

We have validated this algorithm implementation and from the obtained results we believe it complies with ETSI recommendations. This is true if no modification is done on the provided code.

Why have we decided to set DUTY_CYCLE_TIME_PERIOD to 1800000?

While designing the algorithm we noticed that if DUTY_CYCLE_TIME_PERIOD was set to 3600000 the algorithm fails for the 1st hour of operation after a reset and works well for the remaining hours of operation. The reason for this situation is due to the 1 hour sliding observation window, when the stack starts the algorithm is initialized with initial values which introduce an error over the 1st hour of operation.

In order to avoid this problem we decided to reduce the observation window by 2. By doing so the 1% duty-cycle restriction is fulfilled over the first hour. However the drawback is that for the remaining hours of operation we end up with a 0.5% duty-cycle restriction (meaning max 18 seconds of transmission time).

We are aware since the beginning that this is not the best algorithm and it is the result of different compromises.

As a side note when there is no transmission on going the algorithm gains credits again. This may explain your 2nd post observations.

For your information, my colleagues have come up with a far better algorithm which works in all conditions.
Unfortunately we did not had the time to adapt and integrate it to this project.
An implementation of this new algorithm can be found at:
https://github.com/Lora-net/SWSD001/blob/master/lora_basics_modem/lora_basics_modem/smtc_modem_core/lr1mac/src/services/smtc_duty_cycle.h
https://github.com/Lora-net/SWSD001/blob/master/lora_basics_modem/lora_basics_modem/smtc_modem_core/lr1mac/src/services/smtc_duty_cycle.c

[jelledevleeschouwer]

CC: @djaeckle