The Basics of Coexistence#

This section provides a brief description of the basics of coexistence and what impact it can have on wireless applications.

Coexistence of Radio Protocols#

As more and more wirelessly connected devices are used daily by people around the world, the allocated ISM (Industrial, Scientific, and Medical) frequency bands become more and more congested, which results in interference that degrades the radio performance of individual devices. This issue is most relevant in the 2.4 GHz band, which is used by many of the most popular protocols such as Wi-Fi, Bluetooth, or Zigbee.

To avoid this problem as much as possible, all these protocols implement some measures that help in preserving message success rates. These measures can include spectrum or air time sharing (such as channel hopping and collision avoidance) or some kind of message retry capability. These solutions work well in situations where the devices that operate at the same time (coexist) use a low throughput rate, can be separated in frequency, and have sufficient isolation between them.

However, in certain applications, these parameters cannot be met. For example, consider an IoT capable Wi-Fi access point, that also implements low power protocols for home automation purposes. In that device, achieving a high Wi-Fi throughput is extremely important (since it is one of the main functions of the device), while sufficient isolation cannot be achieved between the multiple radios since they have to be located close to each other (inside the same device housing). In this case, even if the manufacturer chooses far away channels for these devices, the performance impact of their coexistence will be very noticeable (and sometimes even prevent the device from operating correctly), since different transmit and receive events will collide with each other on a regular basis.

Generally, coexistence has to be considered when designing a product with the following properties:

• Two or more radio protocols operating in the same frequency band

• High isolation between these radios is not possible (they are located close to each other)

Additionally, if at least one of the radio protocols (most likely Wi-Fi) needs to operate at a high duty cycle at least some of the time, the effect of coexistence can be a lot higher on end product performance.

Impacts of Coexistence#

A more detailed explanation of the possible impacts of coexistence can be found in Wi-Fi Coexistence Fundamentals. This application note is only intended as introductory material, with demonstrations that highlight the importance of considering coexistence during the design phase of an impacted device.

Most of the time, the biggest impact of coexistence on a gateway-like product is a high packet error rate in the low power IoT connection. This is because the active Wi-Fi transmission is acting as a high power blocker, which can reduce RX sensitivity significantly.

Of course, this sensitivity degradation does not directly impact a real world IoT application. Instead, you will experience a lower range where your devices can still communicate properly. For devices that are not located very close to the gateway, certain other effects can be observed as well. In the system level testing (which involved Zigbee and detailed later in this application note), as much as an approximately 400% MAC layer retry rate (compared to the number of packets being sent out), and a 30% application level packet lost rate for a case when high Wi-Fi throughput was enabled while the Zigbee radio was trying to receive a packet, can be seen. This effect can also be highly dependent on the duty cycle of the Wi-Fi radio, which makes the issue harder to debug and more annoying for an end customer. As an example, a Zigbee end device may not operate correctly when streaming video through a Wi-Fi connection.

It is easy to see that these numbers are unacceptably high for a home automation aimed product. This would mean that in 30% of the cases, the message does not even arrive and even if it does, the sender has to retry many times, which results in a much higher average current consumption (and shorter battery life) for the end device.

During testing, using coexistence management solutions, Silicon Labs was able to reduce these numbers to ~70% MAC layer retries with 0% application level packet lost rate (under the exact same conditions as the previous numbers), which is much more viable for a real world application.

Of course, it has to be noted that these exact numbers depend on a lot of variables in the setup (how the Wi-Fi and Zigbee devices are configured, what the exact RF environment around the devices is, and so on), so they are not directly relevant for most use cases. However, the general effects of coexistence are similar in all systems, so the results are still worth sharing.

Options for Implementing Coexistence#

A more detailed overview of this topic can be found in Wi-Fi Coexistence Fundamentals.

There are two main categories for impacted devices: unmanaged and managed coexistence.

In the unmanaged case, there is no connection between the radios so they cannot "manage" the use of the spectrum between themselves. This basically means that the effects described above will have an impact on the performance of the device. There are certain measures that can be followed in order to reduce this impact, but it cannot be completely eliminated. For these recommendations, see Wi-Fi Coexistence Fundamentals.

Managed coexistence means that the coexisting radios are aware of each other, and use a connection between them to communicate and manage radio activity. This is usually done through a PTA (Packet Traffic Arbitration) interface. For a detailed high level description of PTA functionality, refer to Managed Coexistence. For a guide on how this functionality can be configured for your applications, refer to the protocol specific documentation on (Bluetooth and Zigbee and OpenThread). It is worth highlighting that even in devices with managed coexistence, all recommendations outlined for the unmanaged case should still be followed for best performance.

In managed coexistence cases, a controller must decide which radio is able to transmit. In most cases, this is the Wi-Fi device (due to the fact that it usually has higher computational capabilities and is thus running the "main" software of the device). The most common implementation is 3-wire PTA: this is what Silicon Labs recommends to almost all of our customers. In this case, there are 3 signals between the devices:

• REQUEST: This line is asserted when the low power IoT device would like to transmit or receive.

• PRIORITY: This line is asserted for REQUEST events which have higher priority (the exact functionality of this line can be configured on both devices).

• GRANT: This line is asserted when the Wi-Fi device grants access to the spectrum (and stops any transmit activity while it is asserted).

With these 3 signals, the radios can communicate between each other to control who gets to transmit/receive and when. With some additional features and settings detailed in the protocol specific application notes this is an effective way to reduce the negative impact of coexistence to levels where it is barely noticeable in terms of performance.