EU868 duty cycle sub bands source and values

[adriansmares]

References https://github.com/lorabasics/basicstation/issues/164

Currently LBS decides what the sub band duty cycle in the EU868 region using the following function:

https://github.com/lorabasics/basicstation/blob/ba4f85d80a438a5c2b659e568cd2d0f0de08e5a7/src/s2e.c#L360-L366

My interpretation here is that LBS considers the following sub bands, with ETSI 300-220-2 v3.2.1 notation:

• 868.0 MHz to 868.6 MHz at 1% duty cycle (This is known as band M)
• 869.4 MHz to 869.65 MHz at 10% duty cycle (This is known as band P)
• 869.7 MHz to 870.0 MHz at 1% duty cycle (This is known as band P, too. I don't know if this an editorial mistake or not.)
• Every other frequency at 0.1% duty cycle

Per above ETSI document, there are a couple of bands missing:

• 863.0 MHz to 865.0 MHz at 0.1% duty cycle (This is known as band K, and would be covered by the general fallback above, so this is ok)
• 865.0 MHz to 868.0 MHz at 1% duty cycle (This is known as band L, and it is missing)
• 868.7 MHz to 869.2 MHz at 0.1% duty cycle (This is known as band N, and falls under the fallback, so this is ok)

The main problem is that the frequencies between 865.0 and 868.0 (band L) are marked as 0.1% duty cycle, while the normative act seems to point that they should have 1% duty cycle. I tried to also look at other implementations:

LoRamac-node seems to consider band L as a 1% duty cycle: https://github.com/Lora-net/LoRaMac-node/blob/2bf36bde72f68257eb96b5c00900619546bedca8/src/mac/region/RegionEU868.c#L59-L62 https://github.com/Lora-net/LoRaMac-node/blob/2bf36bde72f68257eb96b5c00900619546bedca8/src/mac/region/RegionEU868.h#L199-L203

LoRa Basics Modem seems to consider band L also at 1% duty cycle: https://github.com/Lora-net/SWL2001/blob/3258275fbceb02090300cac8cf651d00fb418e0b/smtc_modem_core/lr1mac/src/smtc_real/src/region_eu_868_defs.h#L305-L310 https://github.com/Lora-net/SWL2001/blob/3258275fbceb02090300cac8cf651d00fb418e0b/smtc_modem_core/lr1mac/src/smtc_real/src/region_eu_868_defs.h#L298

Am I misinterpreting the sub band function in LBS, or is band L really missing and marked as 0.1% duty cycle ?

PS: A secondary issue seems to be that LBS mixes all of the sub bands with the same duty cycle in a single 'bucket', but all of the other implementations separate sub bands with a different duty cycle (so M is a different sub band from P, even though both have 1% duty cycle). I can open another issue for this problem, but it is very closely related to this one.

[johanstokking]

On a side note; it would be very helpful if the gateway can be instructed to be under control of the NS and let the NS manage the duty cycle.

[beitler]

Hi @johanstokking @adriansmares Thanks for submitting the issue. Both these things should be possible to address. I see also some activity on this regard by @reissjason in MultiTech fork. Would you guys be willing to collaborate and prepare a PR for this?

[reissjason]

The duty-cycle algorithm used by basic station blocking downlinks after transmission is not ideal for gateways that need to respond to random uplinks from end-devices. Blocking the transmission for X seconds leads to more time-on-air by end-devices. Bringing the correct band duty-cycles is a temporary fix where the LNS is scheduling downlinks according to the full regulations.

The windowed approach is better, but synchronizing different algorithms between gateway and LNS is an issue. The current protocol does not immediately NAK a downlink that will be blocked, which would allow another gateway to be scheduled.

The best solution would be to allow the LNS to disable gateway duty-cycle limitations when it is able to take the responsibility of regulatory time-on-air duty-cycle. This would require the nodc option to be moved from development only into the production builds.

[adriansmares]

Indeed this our stance as well:

1. nodc should be allowed in production builds, and a feature flag for this should be available. The feature flag is important because the LNS needs to know that it has full control over the duty cycle management, and does not have to synchronize the algorithms.
2. For cases in which the LNS did not provide nodc, the latest regulatory bands should be used.

A NAK would be nice for debugging purposes, but in high latency environments the LNS doesn't have enough time to round trip to each gateway and ask 'please transmit this'. It is more important that the LNS has full control over the scheduling decision, as it is the only entity aware of all of the possible downlink paths.

[beitler]

Thanks for your comments. I agree that a nodc control (and the corresponding feature flag) makes sense. We might have to check on the implications of such a control for the certification process of gateways. Will it complexify the certification process if the gateway firmware does not guarantee that the appliance will adhere the regional rules for spectrum access? I think in the past there were concerns raised by some gateway vendors. Stations strategy to circumvent this issue was to allow the nodc control only for 'debug' builds. But we certainly should revisit this decision in alignment with gateway vendors.