Wireless coexistence studies and mitigation technologies for unlicensed 2.4 GHz frequency bands have been around for at least 20 years. The issue is that different 2.4 GHz wireless technologies meet different needs for the same devices, and therefore must operate simultaneously without noticeable performance degradation. This two-part article discusses the growing need for a Wi-Fi and Zigbee/Thread managed coexistence and explores coexistence techniques through industrial design, co-management technologies, and best practices for Internet of Things (IoT) applications in the 2.4 GHz band. In part one we addressed elements of unmanaged coexistence. In part two, we will focus on managed coexistence.

Market trends of higher Wi-Fi transmit power, higher Wi-Fi throughput, and integration of Wi-Fi and IEEE 802.15.4 radios into the same device have the following impacts:

Advantages:

• The host can implement frequency separation between Wi-Fi and IEEE 802.15.4
• Co-located Wi-Fi can force a Wi-Fi network to 20 MHz bandwidth
• Wi-Fi and IEEE 802.15.4 radios can communicate on 2.4 GHz Industrial, Scientific, and Medical (ISM) transmits and receives

Disadvantages:

• Higher Wi-Fi transmit power requires greater antenna isolation
• Higher Wi-Fi throughput results in higher Wi-Fi duty cycles
• Antenna isolation is limited by device size (only 15-20 dB isolation is not unusual)

Assuming frequency separation achieves the “far away” channel case and Wi-Fi only uses 20 MHz bandwidth, a +30 dBm Wi-Fi transmit power level at 100 percent duty cycle requires 45 dB antenna isolation to receive a -80 dBm IEEE 802.15.4 messages. This is generally not achievable in small devices with co-located Wi-Fi and IEEE 802.15.4.

Managed coexistence takes advantage of communication between the co-located Wi-Fi and IEEE 802.15.4 radios to coordinate each radio’s access to the 2.4 GHz ISM band for transmit and receive. Silicon Labs has implemented a coordination scheme for the EFR32 wireless SoC compatible with Wi-Fi devices supporting Packet Traffic Arbitration (PTA)[1]. This PTA-based coordination allows the EFR32 to signal the Wi-Fi when receiving a message or wanting to transmit a message. When the Wi-Fi device is made aware of the EFR32 SoC requiring the 2.4 GHz ISM band, any Wi-Fi transmit can be delayed, improving zigbee/Thread message reliability.

PTA support hardware options

PTA is described in IEEE 802.15.2 (2003) Clause 6 and is a recommendation, not a standard[1]. IEEE 802.15.2 originally addressed coexistence between IEEE 802.11b and IEEE 802.15.1 (Bluetooth Classic) and does not describe an exact hardware configuration. However, IEEE 802.15.2 recommends that the PTA implementation consider the following (PTA commands represented in capitals):

• TX REQUEST from IEEE 802.11b to PTA and TX REQUEST from IEEE 802.15.1 to PTA
• TX CONFIRM from PTA to IEEE 802.11b and TX CONFIRM from PTA to IEEE 802.15.1
• STATUS information from both radios:
• Radio state [TX, RX, or idle]
• Current and future TX/RX frequencies
• Future expectation of a TX/RX start and duration
• Packet type
• Priority (Fixed, Randomized, or QoS based)

In considering the radio state, transmit/receive, and frequencies, IEEE 802.15.2 describes interference possibilities as shown in Table 1.

[Table 1 | IEEE 802.15.2 2.4 GHz ISM Co-Located Radio Interference Possibilities[1].]

From Table 1, the frequency separation recommendations for unmanaged coexistence are also required for managed coexistence:

• IEEE 802.15.2 “In-Band” is equivalent to Co-Channel (significant Wi-Fi impact on co-channel IEEE 802.15.4)
• IEEE 802.15.4 “Out-of-Band” covers both Adjacent and “Far Away” Channel (~20 dB improvement in “Far Away” Channel vs. Adjacent Channel)

As such, for managed coexistence, Silicon Labs recommends continuing to implement all of the Unmanaged Coexistence recommendations:

• Frequency separation
• Operate Wi-Fi in 20 MHz bandwidth
• Antenna isolation
• zigbee/Thread retry mechanisms
• FEM LNA in bypass

In reviewing existing PTA implementations, Silicon Labs found that the PTA master implementation has been integrated into many Wi-Fi devices from many manufacturers, but not all Wi-Fi devices support a PTA interface. Figure 1 shows the most common Wi-Fi/PTA implementations supporting Bluetooth.

[Figure 1 | Typical Wi-Fi/Bluetooth PTA implementations.]

3-wire PTA

One example of a common PTA configuration is the 3-Wire configuration shown in Figure 1. In this case, a PRIORITY signal is used in conjunction with REQUEST and GRANT to signify that a high- or low-priority message is either being received or transmitted. When a REQUEST is received, the Wi-Fi/PTA device compares this external priority request against the internal Wi-Fi priority, which may be high/low or high/mid/low, and can choose to either GRANT Bluetooth or Wi-Fi (Note: PRIORITY can be implemented as static or time-shared (enhanced) priority).

• Static: PRIORITY is either high or low during REQUEST asserted for the transmit or receive operation
• Time-shared: PRIORITY is either high or low for a typical 20 µs duration after REQUEST asserted, but switches to low during receive operation and high during transmit operation

Given the relatively low RF duty cycle of IEEE 802.15.4, static PRIORITY can always be asserted at the Wi-Fi/PTA input with the EFR32 PTA operating in 2-Wire mode. This frees a GPIO pin on the EFR32 and eliminates a circuit board trace.

Test results

Silicon Labs conducted extensive testing of its PTA implementation for IEEE 802.15.4 with multiple Wi-Fi chipsets. In summary, the following observations were based on measured results:

Network form success during active Wi-Fi

• The PTA feature substantially improves 802.15.4 network form success. The most significant improvement was observed in “far away” channel cases.
• Even with the PTA feature enabled, network formation success:
• Is less robust than throughput traffic as network form uses broadcast, non-ACK’ed messages.
• Is best on “far away” channels, but degrades when co-channel or adjacent channel to Wi-Fi.
• Is most impacted when CoEx Wi-Fi is primarily transmitting at a high Wi-Fi RF duty cycle.

MAC retries during active Wi-Fi

• The PTA feature substantially reduces 802.15.4 MAC retries; retries are virtually eliminated when CoEx zigbee is transmitting.
• Even with the PTA feature enabled, MAC retries:
• Are most reduced on “far-away” channels, but degrade when co-channel or adjacent channel to Wi-Fi.
• Are most impacted when CoEx zigbee is primarily receiving at high Wi-Fi RF duty cycle.

Message Failure during Active Wi-Fi

• The PTA feature substantially reduces 802.15.4 message failure. Message failure is virtually eliminated when CoEx zigbee is transmitting and not co-channel to Wi-Fi.
• Even with the PTA feature enabled, message loss:
• Is most reduced on “far-away” channels, but degrades when co-channel or adjacent channel to Wi-Fi.
• Is most impacted when CoEx zigbee is primarily receiving at a high Wi-Fi RF duty cycle.

Figure 2 shows results from one of the tests carried out by Silicon Labs and highlights the positive impact that PTA has, when enabled, on zigbee message failure rates in the presence of Wi-Fi. Message failure is reduced further by re-enabling APS retries (disabled in the tests shown in Figure 2 below).

[Figure 2 | Message failure (percent): CoEx Wi-Fi stream => Remote Wi-Fi & Remote zigbee => CoEx zigbee RX stream.]

Conclusions

As the Internet of Things (IoT) expands and evolves, an increasing number of Wi-Fi-enabled gateways will add Bluetooth, zigbee, Thread and other wireless protocols to enable communication with connected devices in homes and buildings. Moreover, as home and building automation systems increasingly add cloud connectivity, more and more home controllers will add Wi-Fi to their existing low-power radios. Consequently, there will be enormous growth in the number of gateway/controller type devices that include Wi-Fi and other 2.4 GHz radios and protocols, including Bluetooth low energy (BLE) and IEEE 802.15.4-based zigbee and Thread.

Co-located, strong Wi-Fi can have a substantial impact on IEEE 802.15.4 performance. IEEE 802.15.4 performance with co-located Wi-Fi can be improved through unmanaged and managed coexistence techniques. Unmanaged coexistence recommendations include:

• Implement frequency separation
• Operate Wi-Fi with 20 MHz bandwidth
• Increase antenna isolation
• Use zigbee/Thread retry mechanisms
• Remove FEM (or operate FEM LNA in bypass).

With market trends toward higher Wi-Fi TX power, higher Wi-Fi throughput, and integration of Wi-Fi and IEEE 802.15.4 radios into the same device, unmanaged techniques alone may prove insufficient, so a managed coexistence solution becomes necessary. Even with a managed coexistence solution, all unmanaged coexistence recommendations are still necessary.

Wi-Fi/IEEE 802.15.4 coexistence test results show substantial IEEE 802.15.4 performance improvements when PTA is utilized:

Improved network formation success:

• However, network formation utilizes broadcast messages, which are not retried
• If possible, network formation success can be further improved by temporarily reducing Wi-Fi traffic during devices joining IEEE 802.15.4 network

Substantially reduced MAC retries:

• Reduces message latency
• Improves end-node battery life
• Frequency separation remains important, as best managed coexistence performance is for “far-away” channels

Substantially reduced message failure:

• IEEE 802.15.4 network remains operational, even during high Wi-Fi duty cycles.

Terry Dickey is a Staff Applications Engineer at Silicon Laboratories, Inc.

David Egan is Senior Marketing Manager, IoT Software Platforms, at Silicon Laboratories, Inc.

Silicon Labs

www.silabs.com

Facebook

LinkedIn

Twitter

YouTube

References:

1. IEEE (2003), “802.15.2: IEEE Recommendation for Information Technology – Telecommunications and information exchange between systems – Local and metropolitan area networks – Specific requirements Part 15.2: Coexistence of Wireless Personal Area Networks with Other Wireless Devices Operating in Unlicensed Frequency Bands”, IEEE