Techniques mitigate interference between 802.11 and Bluetooth
Techniques mitigate interference between 802.11 and Bluetooth
By Terry Bourk, Senior Director, Advanced Products, Silicon Wave Inc., San Diego, Calif., Member Bluetooth Review Board, EE Times
November 8, 2002 (12:18 p.m. EST)
URL: http://www.eetimes.com/story/OEG20021107S0022
Bluetooth is a personal-area-networking technology and as such may be used in areas where 802.11 is operating. Many devices will incorporate both technologies, and users will expect to use them simultaneously.
An example of such a co-located device is a PC with a Bluetooth mouse and 802.11b/g for wireless connection to a LAN. We can expect to see cell phones or multiuse devices with 802.11b/g for hot spots and Bluetooth for cable replacement to the PC, headset or printer.
Users report cases of acceptable performance with Bluetooth and 802.11b/g devices operating near each other. The inherent protections of direct-sequence spread-spectrum (802.11b), orthogonal frequency division multiplexing (OFDM; 802.11g) and frequency hopping (Bluetooth), combined with a protocol that detects errors and resends packets, provide adequate behavior in many cases. Isn't this enough?
Consider the probability of an 802.11b packet transmission's surv iving when Bluetooth is active nearby. At the 11-Mbit/second rate for 802.11b, a packet takes about 1 millisecond of air time. A Bluetooth connection using one-slot packets (or performing paging) would generally have two packets that overlap the 802.11 packet. Such an overlap would lead to a failure of the 802.11 transmission only if the frequency was within a certain range. The nominal range is the 20 MHz of the 802.11 channel.
Based on random frequency hopping for Bluetooth, the probability of the two Bluetooth packets' being outside a range is about 0.752 = 0.5. A 50 percent throughput is expected if the Bluetooth is fully active. However, if 802.11b is operating at its lowest data rate (1 Mbit/s), packets are 10 milliseconds in duration, and the probability of getting the packet through becomes 1 percent (0.7516).
A similar analysis for the impact of 802.11 on Bluetooth also predicts moderate to high impact, depending on the strength of the interfering signal and the combined duty cycles . The Bluetooth transmission will typically experience only one collision from the 802.11 packets, but for the Bluetooth transmission to be effective two packets (Tx and Rx) must be successful (single bit sequence number). This again makes the probability of success 0.752 = 0.5.
Although 50 percent throughput is not very good, often the nearby 802.11 device will have a relatively low duty cycle and thus the Bluetooth packets will experience much less interference. But loss of more than 5 percent of the transmitted packets on a Bluetooth audio link causes noticeable degradation, and when the failure rate exceeds 10 percent the audio quality will be significantly impaired. Thus, more stringent control over interference is needed.
The simple model that 802.11 and Bluetooth will interfere when the Bluetooth frequency is within the 20 MHz of an 802.11 channel is only valid for a limited range of carrier to interference level (C/I). If the 802.11 level is 30 dB stronger, the interference range wil l expand to 40 MHz. With further increases, the Bluetooth sensitivity will be impaired over the entire ISM band. And finally, at extreme interference levels into either receiver, front-end overload will cause all reception to be blocked.
For data applications, some companies are deciding simply to "tough it out" and let the retransmit protocol get the data over the channel. But that approach can be dangerous. Higher-layer protocol timeouts and fallback algorithms may compound the impact by taking action. More important, the error-detection schemes (header error checks and cyclic redundancy checks) in Bluetooth and 802.11b/g can be overpowered by errors in data and will be fooled into passing along erroneous data to link management protocols and to the user-level applications. It is incumbent on system designers to avoid such situations.
Acceptable performance
We have found that collaborative real-time control based on some form of hardwired signaling between 802.11 and the Bluetooth device can provide acceptable performance. Each of the following techniques can provide significant benefits in specific scenarios, and in some cases all are required:
- Bluetooth packet-type selection. The Bluetooth specification advises implementers to select packet type to optimize throughput. As two devices are moved away from each other and as the signal level gets close to the threshold, such an algorithm would shift to more robust packet types (forward error correction and shorter length). This can be effective in extending operating range but has minimal benefit for interference scenarios.
Packet type is relevant over at most a 9-dB range of receive signal strength. Real-world interference has a wide range of interference levels, making packet-type selection almost meaningless.
Packet length is not a strong factor in range-limited scenarios, but it can be useful for minimizing interference. If the interference is bursty with clear periods on the order of a few milliseconds, then making the Bluetooth packets shorter will result in fewer collisions.
- 802.11 awareness of Bluetooth. It is important that 802.11 devices not react to interference as though the problem was caused by range. Rather than drop to lower data rates (and hence increase packet duration) to make the modulation more robust, 802.11 devices should do the opposite: 802.11 designs need to consider reducing payload size and accept the poorer packet efficiency as a trade-off for reduced collision rates when Bluetooth is active.
- Frequency separation. Adaptive frequency hopping (AFH) will have a major impact on coexistence. The Bluetooth Special Interest Group is working to upgrade the Bluetooth specification to enable AFH.
In some cases the improvement provided by AFH will be dramatic, restoring both 802.11 and Bluetooth to full throughput. But AFH is not a panacea; indeed, its effectiveness is highly dependent on the relative amplitudes of the Bluetooth and 802.11 sign als. AFH will be effective only if the 802.11 receive level in the Bluetooth receivers is low enough that at least some part of the ISM band has acceptable C/I. For example, if 802.11 is received at - 20 dBm the Bluetooth threshold will be raised over the entire ISM band. Around 20 channels will be unusable, and even those outside that range will have elevated thresholds that may block Bluetooth.
Having multiple 802.11 access points near a Bluetooth piconet will cause Bluetooth to be squeezed down to a small set of frequencies and will cause more accentuated Bluetooth-on-Bluetooth interference, forcing the Bluetooth devices to be less friendly to 802.11.
The ability of Bluetooth devices to detect interference is not assured (especially if the duty cycle of the 802.11b/g is low or the active device is farther away), and the time needed to adapt to the changes in interference will reduce the benefits that can be realized.
Two ancillary techniques can help control C/I. The first is sp atial separation. Antenna design and placement/orientation especially in co-located systems can greatly reduce interference, but C/I is subject to the local environment.
Power control can also manage C/I. Power control is mandatory for Bluetooth devices with transmit powers above 4 dBm but is optional for others. When Bluetooth performs power control, it helps the other Bluetooth piconets or 802.11 networks that are nearby.
- Mode switching. Interference is particularly problematic in co-located devices. Proximity of the radios can increase the interference level to the point that the techniques described above break down. Operating only one radio at a time obviously prevents interference. In a co-located device, the systems can coordinate their activity with a mode switch, based on such lower-layer procedures as beacon reception (in 802.11) or paging (in Bluetooth) or by interleaving packets to make the operation appear to be simultaneous.
The challenges of such a te chnique are mostly in the scheduling and priority setting of the two systems. Silicon Wave and Intersil have such a solution with Blue802TM technology. The basic trade-off is the sharing of time in some ratio. With bursty communications, the packets of one system can be sent while the other is idle and vice versa; hence the users do not perceive any loss in throughput.
Mode selection can be usefully combined with frequency separation techniques to improve performance for particular frequencies or operating conditions.
With low levels of interference and/or low duty cycle of the two technologies, it is possible to depend solely on the inherent immunity of Bluetooth and 802.11b/g. Packet selection and algorithm controls in Bluetooth and 802.11 will help but do not generally provide a significant benefit. Adding AFH to Bluetooth will be a major step forward.
In co-located devices such as PCs or cell phones with 802.11 and Bluetooth, even the full combination of the above techniques may not be adequate.
Related Articles
- Quality of Service at Layer 2 (MAC) of an 802.11 Wireless LAN System
- Evaluating Wideband 802.11 WLAN Radio Performance
- Chip makers question need to redraw 802.11 map
- Adaptive Frequency Hopping for Reduced Interference between Bluetooth® and Wireless LAN
- What's the Difference Between CXL 1.1 and CXL 2.0?
New Articles
- Quantum Readiness Considerations for Suppliers and Manufacturers
- A Rad Hard ASIC Design Approach: Triple Modular Redundancy (TMR)
- Early Interactive Short Isolation for Faster SoC Verification
- The Ideal Crypto Coprocessor with Root of Trust to Support Customer Complete Full Chip Evaluation: PUFcc gained SESIP and PSA Certified™ Level 3 RoT Component Certification
- Advanced Packaging and Chiplets Can Be for Everyone
Most Popular
- System Verilog Assertions Simplified
- System Verilog Macro: A Powerful Feature for Design Verification Projects
- UPF Constraint coding for SoC - A Case Study
- Dynamic Memory Allocation and Fragmentation in C and C++
- Enhancing VLSI Design Efficiency: Tackling Congestion and Shorts with Practical Approaches and PnR Tool (ICC2)
E-mail This Article | Printer-Friendly Page |