• State Not Answered
  • Replies 1 reply
  • Subscribers 89 subscribers
  • Views 1134 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 266531
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Limitations of running concurrent multi-protocol application

anusha_14

Hello Nordic support,

In case of using concurrent multi-protocol (BLE + ZigBee or BLE + Thread using time-sliced mode) on Nordic devices (especially nrf52840), are there any limitations on the amount of BLE tasks and the 2nd protocol tasks that can be performed?

For example, can I have an application with intensive BLE traffic along with Thread protocol?  Is the main idea for having BLE + 2nd protocol to support applications that can interact with a phone via BLE and ue 2nd protocol for communication with other devices?

Could you please provide your inputs on this?

Regards,

Anusha

Parents
  • 0

    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

Reply
  • 0

    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

Children
No Data
Related
Terms of service