Increase OT broadcast message reliability

[SimonEMB]

Hi everyone

I have made an application running BLE and OpenThread based on nRF5 SDK for Thread and Zigbee v4.1.0 and I am facing some interference issues with Openthread network.

I use the acknolegde mechanism of CoAP which allows to re-send the message in case of failure but it is not realy applicable with broadcast messages.
I use broadcast message as multicast message to assure some syncrhonisation of my network devices.

I did some research and found out we could increase OPENTHREAD_CONFIG_MAC_TX_NUM_BCAST in order to resend automaticaly several times a broadcast message.
(src https://github.com/openthread/openthread/issues/5347)
I have dug into openthread lib of nRF5 SDK for Thread and Zigbee v4.1.0 but I only found one reference of OPENTHREAD_CONFIG_MAC_TX_NUM_BCAST in link.h.
In link.h, we can find functions like otLinkSetMaxFrameRetriesDirect which allows to increase the number of send retries for unicast communication, but I found nothing for the broadcast message.

Would anyone have an idea about how to increase OPENTHREAD_CONFIG_MAC_TX_NUM_BCAST  ?

Does someone know another way to increase broadcast message reliability of a mesh network ?
An idea would be to adapt the openthread transmission channel, but how to select the best one ?
I have read that frequency hopping shoud be possible with openthread, but I did not found any way to enable it. I have tried solution from https://devzone.nordicsemi.com/f/nordic-q-a/75104/thread-auto-switch-channel but my project did not compile. (see the last comment)

Best regards

[Edvin]

Hello,

Openthread is a prebuilt library in the nRF5 SDK, which uses many definitions from the application. So even if it doesn't seem like definitions like the OPENTHREAD_CONFIG_MAC_TX_NUM_BCAST is being used anywhere, it will most likely be used by the openthread libraries. 

However in this case, I looked it up this definition (OPENTHREAD_CONFIG_MAC_TX_NUM_BCAST), and it is used in a file called mac.hpp (which in the nRF5 SDK is part of the openthread library). It is used to set a variable called kTxNumBcast, which is only used if another definition OPENTHREAD_CONFIG_MULTI_RADIO is set to1. By default this is set to 1 if:

#if (OPENTHREAD_CONFIG_RADIO_LINK_IEEE_802_15_4_ENABLE && OPENTHREAD_CONFIG_RADIO_LINK_TREL_ENABLE)
#define OPENTHREAD_CONFIG_MULTI_RADIO 1
#else
#define OPENTHREAD_CONFIG_MULTI_RADIO 0
#endif

where OPENTHREAD_CONFIG_RADIO_LINK_IEEE_802_15_4_ENABLE is 1 by default, but OPENTHREAD_CONFIG_RADIO_LINK_TREL_ENABLE is 0 by default.

This means that if you would like OPENTHREAD_CONFIG_MAC_TX_NUM_BCAST to be used, then you need to set OPENTHREAD_CONFIG_RADIO_LINK_TREL_ENABLE to 1. But in order to change OPENTHREAD_CONFIG_RADIO_LINK_TREL_ENABLE in the nRF5 SDK you need to rebuild the openthread libraries. Instructions on how to do this is described in this guide. Please note that in order for the library to be compatible with the SDK, you should check out the same commit that is used to build the openthread library that is used in the SDK, which is mentioned in SDK\external\openthread\project\readme.txt.

To summarize: You either need to move over to NCS, or you need to rebuild the openthread library with OPENTHREAD_CONFIG_RADIO_LINK_TREL_ENABLE set to 1 in order to utilize OPENTHREAD_CONFIG_MAC_TX_NUM_BCAST.

Best regards,

Edvin

[SimonEMB]

Hi Edvin

Thanks for your answer, I will look into it very soon and check what I can do.
In the same time I will check in the openThread lib src what is said about frequency hopping.

Best regards