BLE and Zigbee/Thread concurrency

In one of our more recent projects, a customer requested that their product supports BLE for connecting to a mobile app, as well as Zigbee or Thread for sensor connectivity. The catch was that the hardware had a single chip with wireless capabilities.?

?

Zigbee and Thread are both 802.15.4-based standards and operate in the 2.4GHz spectrum, so implementing a system that would support both at the same time does not propose such big challenges. But BLE, while still operating in the 2.4GHz spectrum, has a different modulation (GFSK) compared to Zigbee/Thread (OQPSK), so the radio must switch between the two modes. This means that only one of the protocols can work at one given time.?

Concurrent mode?

The solution provided by the wireless chip manufacturers was the “concurrent mode” (or dual mode or dynamic multi-protocol or simply multi-protocol, depending on your preferred chip manufacturer). While particularities exist in every implementation, all of them share one common idea: time-based access to the radio. ?

This is possible because neither BLE nor Zigbee/Thread require permanent access to the radio - the devices should be sleeping as much as possible. When both stacks request the radio, all implementations give priority to BLE because of its’ more stringent timing requirements. In essence, when BLE is not using the radio, Zigbee/Thread can use it.?

?

How well does it work?

Let’s take a typical scenario when the device is a Thread Border Router (we may or may not have a WiFi backhaul) and we want to be able to configure the device and Thread network from a mobile phone using BLE. We have some Thread nodes connected to the network and sending data towards the Border Router and some nodes that we might send data to from the Border Router.?

Since BLE has priority over Thread, the time that Thread has control over the radio is mostly determined by the BLE Connection Interval and Advertising Interval. At a connection interval of 300ms, Thread will have radio time around 99% of the time, while if using a connection interval of 15ms, Thread will have radio time around 90%. This compounds with relatively similar numbers for the Advertising Intervals.?

This might seem a lot, but the Thread Border Router has no control over when the other nodes send data to it. Thread Routers (and Zigbee Routers for that matter) are supposed to always be in Rx mode to be able to receive packets from End Devices that need to preserve battery.?

Both Thread and Zigbee have retries implemented in the standard, so there are multiple occasions that an End Device has to send its data to the Router.?

In practice, there should be no real issues when using BLE and Zigbee/Thread at the same time, except when you need to do heavy BLE traffic (for example when you transfer large files, such as a new firmware). ?

In the cases when you need high BLE throughput, it is our experience that Thread/Zigbee will start missing packets (even with all the retries in place). If you only have the one Router (or if the node is the Zigbee Coordinator) in the network, it can cause a full network reformation. So the Connection/Advertise intervals need to be carefully considered in these cases.?

?

Conclusion?

We have tested the BLE/Zigbee and BLE/Thread concurrent modes on several platforms and they all work, with one caveat: you have to understand how they work, know the limitations of the solution and design the products accordingly. ?

Don’t self-medicate, see a professional. ?