Go back –> Documentation
An 802.11 device and Bluetooth can interfere with each other when the 802.11 device operates on the 2.4 GHz band. All Bluetooth devices operate at the 2.4 GHz band. This section documents the technical details regarding the causes of interferences and solutions implemented in drivers, the 802.11 stack, and possible future enhancements.
802.11 defines channels on the 2.4 GHz band, each 20 MHz wide. Then, 802.11n allows for 40 MHz wide channels where you have a primary and an adjacent extension channel.
Bluetooth defines 79 channels for communication on the 2.4 GHz band each channel being separated by 1 MHz. The frequency range used is between 2.402 GHz and 2.480 GHz. Bluetooth's transmitted signal is spread across this 2.4 GHz band and the specification allows for 1600 frequency hops per second, the advantage being that since information is spread across a wide band of frequencies signals transmitted by other systems using a portion of the same frequency spectrum may appear as noise to only some of the frequencies used by Bluetooth device using frequency hopping and similarly only a portion of a Bluetooth transmission may interfere with signals transmitted by other systems.
|Center of frequency / freq-range (MHZ)||802.11 Channel number||BT Channel|
|2472 2462-2482||13||Not used|
|2484 2474-2492||14||Not used|
Each 802.11 channel then equals to 20 Bluetooth channels. When communication is enabled on an Bluetooth device you will get interference when the Bluetooth device hops on to any of the 20 Bluetooth channels equivalent to your 802.11 channel. Even if a Bluetooth device hops at the max allowed frequency rate of 1600 frequency hops per second there are only 79 channels available so at this rate each channel will be used around 20 times in a second.
To aid with 802.11 and Bluetooth interference issues several techniques have been implemented on Bluetooth device firmware and 802.11 devices. We elaborate on each of these techniques below.
With this technique, required for Bluetooth devices following the 1.2 spec, Bluetooth devices will scan for fixed sources of interference and adapt its own frequency pattern to avoid those with interference. This works great in low noise environments in a noisy environment could end up disabling Bluetooth communication completely.
When a Bluetooth device sits on the same system as an 802.11 device the 802.11 device can inform the Bluetooth device the 802.11 channel it is operating on and the Bluetooth device can preemptively disable communication on the respective Bluetooth channels. The advantage to this solution is the preemptive nature of preventing interference but you also end up limiting the Bluetooth's own spectrum.
With this scheme an 802.11 device and Bluetooth device can take turns in using the spectrum for communication. The 802.11 device would use a WLAN_ACTIVE signal when it is active and a Bluetooth device can use a BT_PRIORITY to categorize the priority of its different own signals.
Typically signals between an 802.11 and Bluetooth device are triggered using GPIO lines.
Under the 2-wire Bluetooth Coexistence scheme two signals are supported:
The 3-wire Bluetooth Coexistence scheme extends 2-wire scheme with a new signal from the bluetooth device:
Apart from AFS and channel skipping techniques Bluetooth coexistence is typically tested with bundled 802.11 and Bluetooth devices. This becomes more evident with 2-wire and 3-wire which relies on GPIO pins for signaling.
This section refers to Bluetooth coexistence support on existing 802.11 Linux drivers.
Once the Frequency broker is implemented add a trigger on an 802.11 channel switch to the disable the respective Bluetooth channels. This would be a general cheap BT-coex scheme independent of device interoperability.