Driving Wi-Fi, zigbee, and Thread coexistence in the 2.4 GHz band, part 1: Unmanaged coexistence

April 28, 2017

Driving Wi-Fi, zigbee, and Thread coexistence in the 2.4 GHz band, part 1: Unmanaged coexistence

Wireless coexistence studies and mitigation technologies for unlicensed 2.4 GHz frequency bands have been around for at least 20 years. The issue is t...

 

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.

The addition of Wi-Fi radios into home automation controllers will be an enabler for the growth of IoT devices in the connected home, as this will provide connectivity from home devices to Internet and cloud services. Predictions by ABI Research suggest that, while there will be, on average, less than seven devices shipped for every home controller in 2017, by 2020 this number will rise to an average of almost 10 devices shipped for every home controller[1]. The ON World report considers the broader wireless sensor network market (which includes home automation) and predicts that, of the projected two billion wireless sensor node (WSN) devices that will ship in 2020, one in seven will contain a Wi-Fi radio[2].

The growth of IoT is closely linked to growth in the inclusion of Wi-Fi radios in home controllers and the convergence of home controllers with home gateways/routers.

The need for Wi-Fi coexistence strategies

An expected increasing ratio of end devices to controllers, illustrated in Figure 1, also means that the home controller itself will get busier with RF traffic because it will deal with more end nodes (connecting via IEEE 802.15.4) and other low-power wireless networks. The result is an increasing duty cycle of low-power radios on these controllers. An effective coexistence strategy must ensure that the interference between Wi-Fi and other radio protocols is managed and that its impact on overall system performance is minimized.


[Figure 1 | Relationship between Smart Home Controllers and Smart Home Devices shipped over time[1].]

In the past, coexistence strategies between Wi-Fi and low-power, low-data-rate radios, such as IEEE 802.15.4/zigbee in home controllers, was not a great issue, and studies, such as Thonet, Allard-Jacquin & Colle focused on unmanaged coexistence between wireless networks and devices within a network, not radios collocated within a device[3]. For the limited number of home controllers that contained Wi-Fi radios, simple mechanisms were sufficient to stop transmission on one radio when another was transmitting. It’s easy to see why this has been an adequate approach up to now:

  • To date, most home automation implementations have been driven by the home automation system, with a Wi-Fi or Ethernet connection to the cloud being an additional feature, not the main feature
  • Until now, home gateways have typically had just one low-power radio in the design as well as Wi-Fi
  • The total volume of home automation systems deployed has been relatively low

As home automation becomes more mainstream, more home gateway and access point manufacturers and Internet service providers (ISPs) will introduce low-power radios into their Wi-Fi-enabled gateways. Moreover, these gateways will likely have more than one low-power radio included in addition to Wi-Fi and, in some cases, could have as many as three or four 2.4 GHz radios within a single gateway, allowing for Bluetooth and one or two IEEE 802.15.4 radios (e.g. zigbee and Thread). Therefore, managed coexistence strategies will be required to ensure that all radios on the board can operate successfully.

The 2.4 GHz ISM band supports Wi-Fi (IEEE 802.11b/g/n), zigbee and Thread (IEEE 802.15.4), Bluetooth, and Bluetooth low energy. The simultaneous and colocated operation of these different 2.4 GHz radio standards can degrade the performance of one or more of the radios. To improve interference immunity, each of the 2.4 GHz ISM radio standards supports some level of collision avoidance and/or message retry capability. At low data throughput rates, low power levels, and/or sufficient physical separation, these 2.4 GHz ISM standards can coexist with no significant impact on performance. However, recent customer trends are making coexistence more difficult:

  • Increased Wi-Fi transmit power level for “extended range”
  • +30 dBm Wi-Fi Access Points are now common
  • Increased Wi-Fi throughput
  • Depending on achievable signal-to-noise ratio (SNR), high throughput requirements for file transfers and/or video streaming may result in high Wi-Fi duty cycles within the 2.4 GHz ISM band
  • Integrating Wi-Fi, zigbee, Thread, and Bluetooth low energy (BLE) into the same device for gateway functionality (this integration is required by home automation and security applications and provides easier end-node commissioning using Bluetooth low energy)

Wi-Fi impact on zigbee and Thread

Worldwide, Wi-Fi supports up to 14 overlapping 20/22 MHz bandwidth channels across the 2.4 GHz ISM band with transmit power levels up to +30 dBm. Similarly, 2.4 GHz zigbee and Thread support 16 non-overlapping 2 MHz bandwidth channels at 5 MHz spacing with transmit powers up to +20 dBm. These Wi-Fi and zigbee/Thread channel mappings are shown in Figure 2.


[Figure 2 | 802.15.4 and 802.11b/g/n Channel Mapping (Worldwide).]

Actual channels available vary by country. For example, in the USA, Wi-Fi channels 1 through 11 are available, and zigbee channels 11 through 26 are available, although channels 25 and 26 require reduced transmit power levels to meet FCC requirements.

To better understand the effects of Wi-Fi on zigbee and Thread, Silicon Labs measured the impact of a 100 percent duty-cycled IEEE 802.11n (MCS3, 20 MHz bandwidth) blocker transmitting at various power levels while receiving an IEEE 802.15.4 message transmitted at various power levels. The results for co-channel, adjacent channel, and “far-away” channel are shown in the following three figures. All IEEE 802.11n and IEEE 802.15.4 power levels are referenced to the Silicon Labs Wireless Gecko SoC (EFR32MG1) RF input. The test application was developed using Silicon Labs’ EmberZNet PRO (zigbee) stack with a test application (NodeTest) running on an EFR32MG-based device under test (DUT) and a test script to control the DUT and RF test equipment. Since this is an IEEE 802.15.4 focused test, results are identical for Wi-Fi blocking Thread.


[Figure 3 | 100 percent Duty Cycled 802.11n Blocker with Desired 802.15.4 at Co-Channel.]


[Figure 4 | 100 percent Duty Cycled 802.11n Blocker with Desired 802.15.4 at Adjacent Channel.]


[Figure 5 | 100 percent Duty Cycled 802.11n Blocker with Desired 802.15.4 at “Far-Away” Channel.]

From these three figures, as well as other measurements using the EM35x/EM358x device (not shown), the key observations about the impact of Wi-Fi on zigbee/Thread are:

Co-Channel:

  • EFR32MG1 can receive an IEEE 802.15.4 signal down to 6 dB weaker than aggregate Wi-Fi transmit power (100 percent duty cycle)
  • EM35x/EM358x with and without front end module (FEM) to boost the signal can receive an IEEE 802.15.4 signal down to 6 dB weaker than aggregate Wi-Fi transmit power (100 percent duty cycle).
  • IEEE 802.15.4 transmits can also be blocked by Wi-Fi transmit power tripping the IEEE 802.15.4 -75 dBm Clear Channel Assessment (CCA) threshold


Adjacent Channel:

  • EFR32MG1 can receive a -80 dBm IEEE 802.15.4 signal with -35 dBm or weaker Wi-Fi transmit power (100 percent duty cycle).
  • EM35x/EM358x without FEM can receive a -80 dBm IEEE 802.15.4 signal with -38 dBm or weaker Wi-Fi transmit power (100 percent duty cycle), -43 dBm or weaker with Skyworks SE2432L FEM Low Noise Amplifier (LNA) enabled

“Far-Away” Channel:

  • EFR32MG1 can receive a -80 dBm IEEE 802.15.4 signal with -15 dBm or weaker Wi-Fi transmit power (100 percent duty cycle)
  • EM35x/EM358x without FEM can receive a -80 dBm IEEE 802.15.4 signal with -22 dBm or weaker Wi-Fi transmit power (100 percent duty cycle), -27 dBm or weaker with Skyworks SE2432L FEM LNA enabled

In a real-world environment, Wi-Fi is typically not 100 percent duty cycle and only approaches 100 percent during file transfers or video streams in low Wi-Fi SNR conditions. In the previous three figures, the EFR32MG1 device (or EM35x/EM358x) receive sensitivity varies as the Wi-Fi blocker turns ON/OFF. The net result is the ability to see weaker signals when Wi-Fi is OFF, but not when strong Wi-Fi is ON (actively transmitting).

Unmanaged coexistence

Unmanaged coexistence relies on the inherent characteristics of the wireless protocol, simple configuration tools, or network management. There is no specific handshaking between the Wi-Fi radio and other IoT radios. The unmanaged coexistence recommendations that follow provide guidance on maximizing the EFR32MG1 or EM35x/EM358x message success with strong nearby Wi-Fi.

Implement frequency separation

From the observations in the previous section, co-channel operation of IEEE 802.15.4 with 100 percent duty cycle Wi-Fi blocks most of the IEEE 802.15.4 messages and must be avoided. Also, EFR32MG1 tolerates a 20 dB stronger Wi-Fi signal in the “far-away” channel case than in the adjacent channel case. IEEE 802.15.4 network performance is improved by maximizing the frequency separation between the Wi-Fi network and the IEEE 802.15.4 network.

If the Wi-Fi and IEEE 802.15.4 radios are implemented with a common host (MCU controlling both radios), then the host should attempt to maximize the frequency separation. For Wi-Fi networks, the access point (AP) establishes the initial channel and, in auto channel configuration, is free to move the network to another channel using the Channel Switch Announcement (introduced in IEEE 802.11h) to schedule the channel change.

Operate Wi-Fi with 20 MHz bandwidth

Since Wi-Fi/IEEE 802.11n uses OFDM sub-carriers, third-order distortion products from these sub-carriers extend one bandwidth on either side of the Wi-Fi channel. IEEE 802.11n can operate in 20 MHz or 40 MHz modes. If operated in 40 MHz mode, 40 MHz of the 80 MHz ISM band is consumed by the Wi-Fi channel. However, an additional 40 MHz on each side can be affected by third-order distortion products. These third-order products can block the IEEE 802.15.4 receiver and are the primary reason adjacent channel performance is 20 dB worse than “far-away” channel performance.

In proposing the 40 MHz mode for IEEE 802.11n, the Wi-Fi standard anticipated potential issues with other 2.4 GHz ISM devices when Wi-Fi operated in 40 MHz mode. During association, any Wi-Fi station can set the “Forty MHz Intolerant” bit in the HT Capabilities Information. This bit informs the Wi-Fi access point that other 2.4 GHz ISM devices are present, forcing the entire Wi-Fi network to 20 MHz mode.

If the Wi-Fi and IEEE 802.15.4 radios are implemented with a common host, then the host should have the Wi-Fi radio set the “Forty MHz Intolerant” bit during association to force the Wi-Fi to 20 MHz mode, improving the IEEE 802.15.4 performance.

If the application requires Wi-Fi to operate in 40 MHz mode, frequency separation must be maximized by placing Wi-Fi channels and the IEEE 802.15.4 channel on opposite ends of the 2.4 GHz ISM band.

Increase antenna isolation

From observations in the previous section, minimizing the Wi-Fi energy seen by the IEEE 802.15.4 RF input improves the 802.15.4 receive range. For example, in the “far-away” channel case with 100 percent Wi-Fi duty cycle, a -80 dBm IEEE 802.15.4 message can be received when the Wi-Fi energy at the EFR32MG1 input is -15 dBm or less. If the Wi-Fi transmit power level is +10 dBm, 25 dB or more antenna isolation between the Wi-Fi transmitter and the IEEE 802.15.4 RF input is sufficient to always receive a -80 dBm 802.15.4 signal, Wi-Fi ON or OFF.

Increased antenna isolation can be achieved by:

  • Increasing the distance between antennas – In open-space, far-field power received is proportional to 1/R2, where R is the distance between antennas
  • Taking advantage of antenna directionality – A monopole antenna provides a null along the axis of the antenna, which can be directed toward the Wi-Fi antenna(s)

Use zigbee/Thread retry mechanisms

The IEEE 802.15.4 specification requires retries at the MAC layer. To further improve message delivery robustness, Silicon Labs EmberZNet PRO stack also implements network (NWK) retries, wrapping the MAC retries. The user application can also take advantage of APS retries, wrapping the NWK retries.

Remove FEM (or operate FEM LNA in bypass)

Devices such as the EFR32MG1 SoC can deliver nearly +20 dBm transmit power and have excellent receiver sensitivity without an external FEM. However, many other IEEE 802.15.4 radios use an external FEM to increase transmit power to +20 dBm for increased range (in regions where this is permitted (e.g. the Americas)). The additional FEM LNA receive gain also improves sensitivity, but degrades the linearity performance in the presence of strong Wi-Fi.

For best receive sensitivity in the presence of strong Wi-Fi blockers, either eliminate the FEM, or operate the FEM LNA in bypass mode. This recommendation is a trade-off as receive sensitivity without Wi-Fi blockers is improved with FEM LNA gain enabled.

In part 2, we address aspects of managed coexistence.

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. ABI Research (2015), “Home Automation Systems Market Data 2Q 2015”

2. OnWorld (2015), “WSN Markets”

3. Thonet, G., Allard-Jacquin, P., Colle, P. (2008), “zigbee – Wi-Fi Coexistence: White Paper and Test Report”.

 

 

Terry Dickey, Silicon Labs