EU868 Polite Access RAK 11720

hello,
I am new to Loawan, I have designed a new hardware using RAK 11720 and now I am trying to figure out how I can use it in EU 868. I will not be able to stay with 1% duty cycle, I will need more messages ( at least in worst case if I end in SF12 for a while). As an alternative to 1% Duty Cycle ETSI has defined “5.21 Polite spectrum access”, that gives you 2,7% duty cycle if you do LBT+Frequency hopping so if you leave a busy frequency and try at an other.

Now I wonder how the RAK device handles these issues, in fact I ask myselve who controls the frequency / channel to use for the next transmission ?

I found an AT switch AT+LBT=1 but the RUI AT Spec does not tell much what that will mean:

In case of busy channel:

  1. Will it just wait and try later ?
  2. Willl it move to a different frequency and try there ? ( wanted solution) If so what algorithm will it use ?

My second Problem is to understand the " * [LoRaWAN Regional Commands] AT+MASK] * [AT+CHE] * [AT+CHS] * [AT+BAND]

They do not seem to be applicable in EU ?

At the end, where can I find information about the channel allocation of RAK 11720 at all ?

best regards Otmar

AT+LBT works only for AS923-1 in Japan and KR920.

LBT is scanning through the channels until it finds a free one, then sends the packet.
If no free channel is found, the packet is not sent.

AT+MASK - AT+CHE - AT+CHS works only for US915, AU915, LA915, CN470

AT+BAND sets the LoRaWAN region the device will use.

thank you very much !

However “If no free channel is found, the packet is not sent.” means what exactly ?
After 1 round robin on all channels the packet is dropped ? What happens in case of an CMSG confirmed packet ? Does the Application host receive an error in that case ?, so the application level can still reinvoke retransmission if a confirmed message is important to the application.

Finally do you think your LBT implementation matches clause 5.21 of https://www.etsi.org/deliver/etsi_en/300200_300299/30022001/03.01.01_60/en_30022001v030101p.pdf

For my understanding it will match.

best regards
Otmar

If it can’t send, you will get an error response.
If you are using AT commands, it will be +EVT:TX_ERROR. If you are using a custom application, the error will be reported in the TX finished callback.

And, don’t forget, even if you enable LBT, IT WILL NOT WORK ON EU868
It is only available in AS923-1 in Japan and KR920

ok, thanks for pointing on this again ( AT+LBT does not work for EU868). Than that is useless for me in the existing version.

That raises my question, can I implement this on application level somehow to make it 5.21 of https://www.etsi.org/deliver/etsi_en/300200_300299/30022001/03.01.01_60/en_30022001v030101p.pdf compatible ? Can I listen on application Level to a channel and just direct the channel to use for a MSG command ?

Or is RAK planning a firmware update and can we team up ? We could do the test job in a German LAB in 2026 tp verify compatibility against 5.21 of https://www.etsi.org/deliver/etsi_en/300200_300299/30022001/03.01.01_60/en_30022001v030101p.pdf.

Please understand my stupid questions our knowledge is only based on theory we at charterware have not implemeted Lorawan before. Our 1. hardware sample containing STM32 CPU + RAK 11720 is just being manufactured.

You cannot interfere or listen to LoRaWAN events on application level.

We implemented LBT for LoRaWAN regions where it is mandatory. Not sure if there are any plans to make it available on other regions.

I will check with the R&D team.

thank you , I am awaiting your reply …

By the way, it is mandatory in the EU if the device needs more than 1% duty cycle on a channel.

In a nutshell the rules say:
"Either use 1% duty cycle or polite spectrum access.

Whereas polite spectrum access is defined as LBT ( CAA ) along with frequency hopping if RSSI Signal > threshold. This allows for 2,7% duty cycle on just 1 channel. Given 8 one can archieve more than 20% device airtime.
So depending on your application needs it is mandatory.

regards, Otmar
CEO charterware.net

Our LoRaWAN stack is based on LoRaWAN Regional Parameters RP002-1.0.4.

It is not mandatory and it would be even outside of the LoRa Alliance specification.

thank you,
yes I saw that before. Lorawan Alliance spec currently restricts spectrum usage far more than ETSI which is probably for effort reasons (regionality).

At the end I only have to fulfill ETSI.

I just said “it is mandatory if you would like to use more than 1% duty cycle”.

Just please give it a chance and talk to your R&D. With strict 1% usage I am not sure we can implement our application.

many many thanks for your support

Otmar