Coexistence of WLAN, Bluetooth, ZigBee, and Thread in the 2.4GHz Band

This article introduces coexistence solutions for wireless technologies operating in the 2.4 GHz ISM band. Many popular wireless technologies such as Wireless Local Area Network (WLAN), Bluetooth, ZigBee, and Thread operate in the common 2.4 GHz band. Therefore, they may interfere with each other, reducing the overall throughput of all related links. Known solutions to such coexistence issues include cooperative and non-cooperative schemes for shared channels. We explore detailed information about Quantenna’s 4-wire Packet Traffic Arbiter (PTA) cooperative scheme and analyze its impact on reducing performance degradation due to interference.

Introduction

Many currently popular wireless communication technologies such as Wi-Fi®, Bluetooth[1], ZigBee[2], and Thread operate in the same unlicensed 2.4 GHz band. Due to the shared nature of the channels, these technologies interfere with each other when operating in the same time-frequency space. Depending on the strength of the interference channel and transmission power, this interference can lead to significant performance degradation. Some of these technologies have built-in protocol protections such as carrier sensing, self-adjusting frequency hopping, and hopping to partially avoid interference from other technologies using the same channel.

Figure 1 describes a typical coexistence scenario where WLAN and Bluetooth modules are located on the same QSR10G system-on-chip (SoC). The WLAN access point and Bluetooth host are both placed on the QSR10G. It shows two possible scenarios for WLAN stations (STA): the near-end scenario when the STA is close to the access point, and the far-end scenario when the STA is farther away from the access point. In the near-end scenario, the STA can hear the transmission from the co-located Bluetooth master device, while in the far-end scenario, the STA cannot hear the transmission from the master device, which can simultaneously trigger WLAN RX (without QSR10G) and Bluetooth TX events. Depending on the channel, there may or may not be a link between nearby WLAN STA and Bluetooth slave. Interference on any link may be caused by this hidden node situation due to uncertain network conditions. However, introducing cooperation between the two technologies co-located on QSR10G can reduce certain interference events. For example, limiting one link to be active at a given time. This cooperation can enhance the effectiveness of the shared channel and the overall throughput of all related links.

Coexistence of WLAN, Bluetooth, ZigBee, and Thread in the 2.4GHz Band

Figure 1: Example network where WLAN and Bluetooth clients connect to one QSR10G access point (AP)

Existing Coexistence Solutions

As early as the development of these technologies, the potential interference issues and the need for coexistence solutions were recognized. The IEEE 802.15.2 standard[3] (developed by the IEEE 802.15 Coexistence Task Group 2) addresses coexistence issues between WLAN and WPAN networks. This standard describes recommended practices and provides computer models of interference (between 802.11b and 802.15.1). It describes cooperative schemes (used when transmitters are co-located), such as:

• Alternating channel access (MAC layer scheme)This method divides the beacon interval into two parts, and both technologies use TDMA to avoid interference.• Packet traffic arbitration (MAC layer scheme)Separate PTA blocks authorize different interfaces to use the same channel for all transmissions. PTA blocks coordinate the sharing of the medium based on traffic load and priority.• Deterministic interference suppression (PHY layer scheme)This method uses programmable notch filters in WLAN receivers to eliminate narrowband Bluetooth interference.

The standard also includes the following non-cooperative schemes:

• Self-adjusting interference suppression (PHY layer scheme)This method uses self-adjusting filtering at the WLAN receiver to eliminate narrowband interference.• Self-adjusting packet selection and scheduling (MAC layer scheme)This method self-adjusts the selection of packet attributes (payload length, forward error correction (FEC) codes, and automatic repeat request (ARQ)) and schedules traffic in low-interference areas.• Self-adjusting frequency hoppingThis method actively estimates and avoids frequency hopping in high-interference WPANs.

Compared to non-cooperative schemes, cooperative schemes perform better in orthogonal channel access, thereby reducing potential interference. However, cooperative schemes require tight integration between the corresponding coexistence technologies and often involve hardware or software handshake signals.

In addition to the above technologies, frequency hopping cooperation methods can also reduce the opportunity for simultaneous access to the same channel. With this method, co-located radios avoid using public frequencies. For example, if the WLAN radio is operating on channel 1, the Bluetooth radio will avoid channels 0-21 or the ZigBee radio will avoid channels 11-14.

Quantenna’s 2-Wire Coexistence Arbiter

Quantenna uses a hardware solution based on the PTA recommended in the 802.15.2 standard to achieve cooperative coexistence. The interface uses 2 wires for handshaking between co-located WLAN and WPAN components to reduce the opportunity for simultaneous access to the common channel. Figure 1 shows the interface signals between the PTA module and external (EXT) Bluetooth/ZigBee/Thread modules.

Coexistence of WLAN, Bluetooth, ZigBee, and Thread in the 2.4GHz Band

Figure 2: Quantenna’s 4-wire interface between QSR10G PTA and external modules

The meanings and operations of the different signals shown in Figure 1 are as follows:

1. REQUEST – This is an input signal to the PTA module indicating that a request from the external module is requesting access to the channel.2. GRANT – This is an output signal to the external module indicating whether the external module has been granted permission to access the channel. This signal is valid when the external module sends a request signal, and WLAN neither receives nor sends frames.

When WLAN needs to transmit, it checks whether the external module has been granted access. If the external module is accessing the channel, WLAN will wait until the permission is revoked before transmitting. In normal mode, when WLAN is sending or receiving, any requests from the EXT module are denied. When the EXT module needs to send frames, it sends a REQUEST and waits for a GRANT before sending. When the EXT module receives a frame, it will send a REQUEST and continue to receive that frame, unaffected by the GRANT signal.

In addition to the above-mentioned 2-wire mode, the interface can also operate in 1-wire mode. In 1-wire mode, the only output from the PTA module is the Grant signal. In this mode, the Grant signal serves as an indication of WLAN being busy. When WLAN is not using the channel, the PTA will revoke the Grant signal.

The order of TX/RX events (WLAN TX, WLAN RX, EXT TX or EXT RX) may lead to different operational or interference scenarios. Figure 3 shows an example where a WLAN frame is received during an ongoing Bluetooth transmission. This situation occurs if the STA sending the WLAN frame is far from the access point and thus cannot hear the Bluetooth transmission at lower power (as shown in Figure 1).

Coexistence of WLAN, Bluetooth, ZigBee, and Thread in the 2.4GHz Band

Time: Time

Figure 3: Example of a WLAN RX event occurring during an ongoing BT TX event

Note that in the case of hidden nodes (when WLAN STA and/or EXT slaves cannot hear the transmitter), it is unavoidable for one link to receive frames while another link is transmitting.

Table 1 lists all possible sequences of TX/RX events when using a 2-wire PTA interface to reduce interference between WLAN and EXT modules, along with their impact. The enumeration ignores cases where the channel is idle and only one interface has TX/RX events while the other interface is idle.

Coexistence of WLAN, Bluetooth, ZigBee, and Thread in the 2.4GHz Band

Note: The order of TX/RX events and their impact on the coexistence interface using the 4-wire scheme.

If there is no PTA module, all situations mentioned in the table would interfere with active links. The PTA module can reduce the number of interference situations, even if it may cause transmission delays. Generally, delays are preferable to interference/conflict since conflicts can lead to packet loss requiring more than one channel time for retransmission and cascading error events. Without the PTA, transmissions will occur when another link is sending or receiving, potentially leading to packet loss. However, among the eight coexistence scenarios considered in the table, the PTA interface cannot resolve four of them. Note that all remaining issues arise when the PTA has authorized the first interface to perform TX or RX while the second interface begins to receive frames. Since the device cannot control unexpected receptions, these error situations are difficult to resolve. However, depending on link strength, these situations do not always lead to packet loss. In the next section, we evaluate the likelihood of such events occurring and their impact on performance.

Wi-Fi Preemption

Even with the standard PTA mechanism of requests and grants, if current Wi-Fi traffic is high, external traffic may also have to wait for longer intervals. In many current use cases of ZigBee, Bluetooth, Thread, etc., these external protocols are used for battery-powered sensor endpoints. In this case, additional delays and collisions can lead to more retransmissions, thereby affecting the battery life of customers. Therefore, it may be beneficial to immediately stop ongoing Wi-Fi transmissions and prioritize external traffic in the presence of such high-priority external traffic. Allowing external traffic even during ongoing Wi-Fi traffic is referred to as PTA preemption. Quantenna currently supports two preemption modes:

No TX Stop Preemption

This mode applies to cases where Wi-Fi and external traffic are used on non-overlapping channels. For example, Wi-Fi channel 1 and ZigBee channel 23 do not overlap. In this usage case, both radios can continue their communications simultaneously due to the non-overlapping channels.

TX Stop Preemption

This mode applies to use cases where Wi-Fi and external traffic are on overlapping channels. For example, Wi-Fi channel 1 overlaps with ZigBee channels 12, 13, or 14. In this usage case, due to the overlapping channels, both radios cannot continue their communications simultaneously. Simultaneous transmissions may lead to conflicts.

In this mode, whenever there is a request, PTA grants access to the external radio. If there is an ongoing transmission, PTA immediately stops the transmission. In the case of ongoing WLAN reception, PTA does not interrupt it, as we cannot control the transmission. WLAN will do its best to recover the signal in the presence of external traffic.

Without TX stop, preemption of Wi-Fi traffic has no effect as it does not share an interfering channel. However, for TCP traffic preemption, slow traffic such as 1 ZigBee frame per second may not affect Wi-Fi traffic, but high throughput such as 100 ZigBee frames per second may cause Wi-Fi throughput loss of up to 60%.

Performance Impact

In all possible scenarios related to the operation of coexistence devices, some combination of events will lead to interference scenarios. Figure 4 shows the relationship between these scenarios. All possible events are represented by the outermost circle. If the duty cycle of the devices is low enough, most events will be non-contentious, as shown in the blue portion of the outer circle. Among all possible interference scenarios, using the PTA interface can avoid certain cases, as described in Table 1. The innermost red circle represents the space of events that cannot be avoided using PTA.

Coexistence of WLAN, Bluetooth, ZigBee, and Thread in the 2.4GHz Band

No Contention: No contention Avoidable Contention: Avoidable contention Un-avoidable Contention: Unavoidable contention

Figure 4: Space of all possible coexistence scenarios

Avoidable and unavoidable contention events will lead to delays, retries, and packet loss in WLAN or WPAN traffic. This will result in performance loss. The exact events leading to such performance loss depend on the specific scheme used to resolve coexistence issues. In the next subsection, we analyze the probabilities of avoidable and unavoidable contention. Further analysis of PHY layer performance in coexistence scenarios can be found in [4] and [5].

Overview of Contention Events

To understand the proportions (probabilities) of the above scenarios and their dependence on the duty cycle of WLAN and WPAN, we calculate these probabilities as functions of duty cycle. We consider a network with the following parameters.

• WLAN traffic parameters○ Transmission rate = 60% of WLAN ON time (downlink)○ Reception rate = 40% of WLAN ON time (uplink)• EXT traffic parameters○ Transmission and reception rate = 50% of EXT ON time

Figure 5 summarizes the probabilities of WLAN traffic under two different duty cycles across all scenarios. A 10% duty cycle indicates low WLAN traffic, while a 90% duty cycle indicates high WLAN traffic. When the duty cycle of WLAN traffic is low, the probability of contention (avoidable or not) is low, and almost all non-contentious cases occur when WLAN is idle. Therefore, as the Bluetooth duty cycle increases, the proportion of idle time decreases, and the proportion of non-contentious cases increases. However, when WLAN traffic is already high, the probability of non-contention decreases with the Bluetooth duty cycle. However, the most important conclusion is that the PTA scheme can resolve more than half of the problematic situations.

Now, let’s consider some variables not accounted for in the above calculations. Since these WPAN protocols have built-in protections, not all of the above unavoidable events occur in real life. We consider the following four exceptions.

First, for Bluetooth modules, if the RX of the slave arrives after the TX of the master and the module reserves time for the entire processing, then the RX event will not occur in the middle of the WLAN event. Therefore, we no longer have the possibility of this unavoidable interference situation.

Coexistence of WLAN, Bluetooth, ZigBee, and Thread in the 2.4GHz Band

Probability of occurrence: Probability of occurrence Duty cycle for Bluetooth: Bluetooth duty cycle Duty cycle of WLAN: WLAN duty cycle Idle Channel: Idle channel No Contention: No contention Solved Contention: Resolved contention Contention: Contention

Figure 5: Event probabilities vary with Bluetooth duty cycle, showing WLAN duty cycles of 0.1 and 0.9

Second, for ZigBee, if it follows Carrier Sense Multiple Access (CSMA), the site will be able to hear ongoing WLAN transmissions in the air, so RX events will not occur in the middle of WLAN events.

Third, even if the external module and WLAN are using the same channel due to RX events, WLAN will observe narrowband interference due to the bandwidth and frequency hopping sequence used.

Finally, due to the frequency hopping mechanism of Bluetooth, even if unavoidable contention events occur, Bluetooth traffic will not always overlap with WLAN bandwidth. The proportion of overlapping time depends on the frequency hopping sequence and operating band of WLAN.

In addition to all the above considerations, cross-channel interference caused by imperfect radios will also affect interference, which is outside the scope of this document.

Conclusion

We have described and analyzed Quantenna’s 4-wire PTA scheme, which addresses coexistence issues to share the 2.4 GHz channel with different wireless technologies. If the external module has certain built-in protections, the PTA interface can potentially reduce contention situations by half or more. The side effect of contention situations (avoidable or unavoidable) is that coexistence leads to performance loss (delays in avoidable situations and rejections/losses in unavoidable situations), which we can minimize but not completely eliminate, especially in cases of near-full channel utilization.

References

[1] “802.15.1−2005 − IEEE Standard for Information technology −− Local and metropolitan area networks −− Specific requirements −− Part 15.1a: Wireless Medium Access Control (MAC) and Physical Layer (PHY) specifications for Wireless Personal Area Networks (WPAN)”.[2] “802.15.4−2011 − IEEE Standard for Local and metropolitan area networks — Part 15.4: Low−Rate Wireless Personal Area Networks (LR−WPANs)”.[3] “802.15.2−2003 − IEEE Recommended Practice for Information technology −− Local and metropolitan area networks −− Specific requirements −− Part 15.2: Co−existence of Wireless Personal Area Networks with Other Wireless Devices Operating in Unlicensed Frequency”.[4] J. Lansford, A. Stephens, and R. Nevo, “Wi−Fi and Bluetooth: Enabling Co−existence”, IEEE Network, vol. 15, no. 5, pp. 20−27, 2001.[5] N. Golmie, N. Chevrollier and O. Rebala, “Bluetooth and WLAN co−existence: Challenges and solutions”, Wireless Communications, vol. 10, no. 6, pp. 22−29, 2003.

Source: Microwave RF Network

Original Technology Column

RF Testing Original Notes

Microwave Simulation Original Notes

5G and Wireless Technology Column

Antenna-in-Package (AiP) Technology

Coexistence of WLAN, Bluetooth, ZigBee, and Thread in the 2.4GHz Band
Coexistence of WLAN, Bluetooth, ZigBee, and Thread in the 2.4GHz Band
Submission & Column Cooperation Please add the editor’s WeChat | WeChat ID: 18675536035

Coexistence of WLAN, Bluetooth, ZigBee, and Thread in the 2.4GHz Band

Leave a Comment