RE: Limitations of running concurrent multi-protocol application

Jørgen Holmefjord — Tue, 16 Mar 2021 10:51:26 GMT

Hi,

Since there is only one radio available, the dynamic multiprotocol solution will use time-slicing of the radio to share the resources between the protocols. BLE will not be affected by running a dynamic multiprotocol solution, as the Softdevice will always get the highest priority to handle timing-critical tasks. BLE have much stricter timing requirements than Thread/Zigbee does, so BLE/softdevice will get the time it requires, while the rest of the radio time is allowed for the other protocol through the timeslot API.

With high BLE activity, the performance on Thread/Zigbee will be reduced quite a lot, see some examples in Dynamic multiprotocol performance. This may cause problems in certain roles, as routers may miss packets that should be relayed (causing retransmissions and delays), or coordinators/leaders being prevented from commission new devices.

We do have an example showing BLE scanning + Thread SED role, where BLE activity is quite high, but here the Thread portion is reduced to Sleepy End Device to reduce packet loss in Thread protocol. You are not limited to any specific BLE configuration in the multiprotocol solution, but you need to make sure that the load on each protocol is balanced to reduce the probability of the Thread/Zigbee protocol suffering from radio-time starvation, preventing it from handling its tasks.

Best regards,
Jørgen