There are several new products being introduced into the emerging IoT market space which include multiple radios on the same printed circuit board operating on different wireless protocols, often at the same time.  In order for these radio networks to operate efficiently and coexist, they need to have some higher level network management and control.  This article provides information about EM3xx features which are currently available and can be used by network management software and hardware to help facilitate the coexistence of the ZigBee and Thread based radios with other radio networks such as Bluetooth and Wi-Fi. For those designs where network management is not possible, there is also a discussion of best practices to utilize in order to maximize the robustness of an un-managed co-existence network.

Please note that EM3xx support for Wi-Fi coexistence is limited and Silabs's recommendation is to make use of the full PTA (Packet Traffic Arbitration) capabilities of the EFR32 parts. Please reference our Wi-Fi Coexistence Learning Center for more information.

Currently, the available functions which can be utilized for EM3xx network coexistence are Radio Hold-off (RHO), which is a feature in the software stack and PTI_FRAME (PA4) and TX_ACTIVE (PC5)/nTX_ACTIVE (PC6), which are hardware functions within the IC.

RHO is a feature of the ZigBee software stack code. It is an input function normally residing on pins PA6 or PA7. The network arbiter, which can be another radio’s MCU, asserts RHO when the non-ZigBee/Thread network radio is active. This causes the ZigBee/Thread software stack to hold off the transmission of packets, until after RHO is de-asserted. Management of the RHO pin by the ZigBee / Thread software stack is done by forcing a return of channel busy for the CCA (clear channel assessment) algorithm, which then triggers a random back-off period for packet retry with a default of up to 3 total retries.

PTI_FRAME (PA4) is hardware function that must be enabled in software and the GPIO alternate function selected in order to be utilized. The primary function of PTI_FRAME is a debug port frame signal for network level debugging. It is asserted when TX preamble begins or when RX sync is detected. Thus PTI_FRAME can be used as an input to the network arbiter to indicate the ZigBee/Thread radio is active.

TX_ACTIVE (PC5) is a hardware function which must have the GPIO alternated function selected in order to be utilized. The primary function of TX_ACTIVE is to operate an external switch within a FEM or discrete PA / LNA solution to select either the transmit path or the receive path. When asserted it marks the start of TX operation and when de-asserted it marks the end of TX operation. As an input to the network arbiter, TX_ACTIVE can be used as a flag to indicate when the ZigBee/Thread radio is transmitting. Used in conjunction with PTI_FRAME, TX_ACTIVE can also be used to identify if the ZigBee/Thread radio is in TX mode or RX mode, adding another layer of feedback to the network arbiter.  The reason for this signal combination is the ZigBee/Thread radio is not always active in RX mode when TX_ACTIVE is low.  For example, when PTI_FRAME is asserted and TX_ACTIVE is high, the radio is in TX mode.  When PTI_FRAME is asserted and TX_ACTIVE is low, the radio is in RX mode.  If PTI_FRAME is not asserted and TX_ACTIVE is low, the ZigBee/Thread radio is either not enabled or is simply not receiving packets.

nTX_ACTIVE (PC6) is a hardware function which must have the GPIO alternated function selected in order to be utilized. The nTX_ACTIVE function is the inverse of the TX_ACTIVE function which is primarily the same except that nTX_ACTIVE de-asserts at the start of TX operation and asserts at the end of TX operation and is meant for separate LNA mode switching.  nTX_ACTIVE can be used in the same manner as TX_ACTIVE as an input to the network arbiter to indicate when the ZigBee/Thread radio is active and in conjunction with PTI_FRAME to indicate when the ZigBee/Thread radio is transmitting or receiving. 

In summary, connecting the non-ZigBee/Thread network radio’s transmit active and /or receive active output to the ZigBee/Thread RHO pin allows the ZigBee/Thread radio stack to hold-off on transmitting.  Connecting PTI_FRAME and TX_ACTIVE or nTX_ACTIVE to the non-ZigBee/Thread network radio’s inputs allows the other network radio to know when the ZigBee/Thread radio is active and whether it is in transmit or receive operation.  For the functionality described in this article to be fully utilized, the customer will need to develop the appropriate level of network arbiter / management functionality into the non-ZigBee/Thread network radio’s software application.

There are some design strategies that do not involve active network management and should be utilized in all cases where the ZigBee/Thread radio cannot be controlled at the same time as the non-ZigBee/Thread radios included in the design. The following strategies are also useful for designers who are looking for a more simplistic approach in applications where co-existence is not a priority or for managed network designs as supplemental and best practice design strategies. Note that these strategies are not a replacement for the above network management functions for which the designer should always implement whenever possible for robust network operation.

• Maximize the Wi-Fi, Bluetooth or other non-ZigBee/Thread antenna isolation from the ZigBee/Thread radio antenna through null alignment and/or distance between antennas. Placing the antennas at different orientations and at the greatest practical distance between each other helps in preventing ZigBee/Thread LNA gain compression issues. In all designs, network managed or not, the antennas must be placed far enough apart for safe operation of the radios. For example, a ZigBee/Thread radio with a maximum safe input level of 5 dBm must have enough attenuation between its own antenna and that of a Wi-Fi antenna transmitting at +27 dBm to avoid damage to the ZigBee/Thread receiver. The distance providing this attenuation is therefore the absolute minimum distance allowable between the antennas.
• Specifically for Wi-Fi, operate the Wi-Fi network in 20MHz bandwidth mode to maximize the Wi-Fi channel frequency and ZigBee/Thread channel frequency separation. Wider channel frequency separation helps to prevent ZigBee LNA IP3 (third-order intercept point) issues.
• Ensure all ZigBee/Thread retry mechanisms are being employed (MAC, NWK, and APS retries). This strategy takes advantage of a general characteristic of Wi-Fi where packet transmission is not constant and is more likely to get the message through on a time gap between Wi-Fi transmissions.
• If an FEM (front-end module containing PA and/or LNA) is used to maximize the ZigBee/Thread TX level for range, insure the FEM LNA control is set to bypass (or GPIO controllable to force bypass). Having extra FEM LNA gain only makes any design inherent ZigBee/Thread LNA gain compression/IP3 issues worse.

Further references:

For enabling the hardware functions, refer to the EM3xx datasheets for more details.

http://www.silabs.com/support/pages/document-library.aspx?p=Wireless%20-%20ZigBee%20and%20Thread

For more details about CCA, refer to the IEEE 805.15.4 technical specification.