Advertisement
Product Releases
Advertisement

Bluetooth and 802.11b Coexistence Issues

Mon, 08/30/2004 - 7:47am

How FHSS and, in particular, AFH, make Bluetooth a good neighbor to 802.11b.


By Robin Heydon

Today, just about anywhere one goes they are likely to find that both the home and the office use WLAN and WPAN environments. With these technologies comes the oft talked about benefits of mobility and flexibility that Bluetooth and other wireless technologies offer.

Nowadays, it is generally understood that Bluetooth and WiFi (802.11b) do not compete with each other, both in terms of technology and application. But as the number of devices operating within the license-free 2.4 GHz band continues to rise, and those devices are increasingly used side-by-side, such as an office environment, interference issues raise their ugly head, and it is becoming apparent that the issue of interference must be tackled. Theoretically, they aren't supposed to interfere with each other, but in reality, the do, for a number of reasons.

Interference Metrics

Devices unable to cope with interference will suffer deterioration in quality — something much more readily identifiable by the user for real-time applications such as audio and video, as opposed to data. So the predicted influx of Bluetooth enabled headsets and landline telephones for business use will co-exist successfully when sat next to a network of WiFi enabled PCs.

Bluetooth Metrics

Bluetooth uses FHSS to ensure its robustness against interferers. It "hops" 1600 times per second over all 79, 1 MHz channels in the 2.4 GHz band. Any interference on one frequency is quickly detected, and 1/1600th of a second later, a different frequency is used to transmit the information. FHSS has always been a core feature of the Bluetooth specification to defend against interference.

With Bluetooth and WiFi increasingly being integrated side-by-side into the one product (such as a laptop PC) the potential risk interference increased and FHSS alone may not be sufficient to deal with the problem. So during the development of the latest specification of Bluetooth (version 1.2), it was clear that the question of interference was going have to be dealt with once and for all.


Figure 1. A block diagram of adaptive hop selection mechanism.

Given the unique nature of the Bluetooth SIG, whereby companies are encouraged to discuss their ideas for the development of Bluetooth, there was no shortage of suggestions for ways of tackling this issue. A new working group within the Bluetooth SIG, the Coexistence Working Group, was chartered to solve the problem.

Peaceful Coexistence

The Coexistence Working Group brought many competing Bluetooth technology companies together to discuss possible solutions. Over time, the evaluations of various proposals were studied, and a single technical proposal created from the best parts of all the individual proposals. The Bluetooth SIG encourages decisions by consensus, to ensure the whole group is behind the final draft, and very little voting needs to be done.

Solving the coexistence issue did not occur in a single 'eureka' moment, but rather a general increase in the collective wisdom of the group towards the chosen solution. The solution was written down, and then presented to the Bluetooth Architectural Review Board for its initial review — one of many.

AFH — An Eloquent Solution

Eventually the technique of AFH was chosen. This allows a single channel map to be distributed to a slave device that makes decisions when using a modified hopping kernel (see Figure 1). If a channel that would have been selected was marked as being bad, then a new channel is chosen from the set of good channels. Also, the same channel is used on transmission and reception by the master device. This allows better correlation on the master of channels that were bad because the slave transmission was not received by the master in a given slot.

As can be seen on in Figure 2, Bluetooth hops all over the 2.4 GHz band. Unwittingly, this can cause interference to static frequency devices in the same band. AFH avoids interference by dynamically changing the frequency hopping sequence of devices, thereby restricting the number of channels that a Bluetooth device can hop across. This allows a set of frequencies to be left open for use by other systems such as WiFi (see figure 3).

Regulatory authorities in various countries, such as the FCC, define the minimum set of channels that can be used. However, to ensure maximum interoperability between devices throughout the world, the Bluetooth specification requires a minimum set of at least 20 channels that must be marked as good by the master, even though this is higher than some authorities allow.

AFH does not just specify the new hop selection mechanism, but also defines how signaling is used to allow slaves to notify the master of their characterization of the channel, and the master to notify the slaves of a new hopping sequence. Signaling needed to be defined via the LMP, but the use of this data by the master was not defined in the original Bluetooth specification. These areas are strictly specified including the signaling formats for LMP packets and the Baseband hopping kernel.


Figure 2. Frequencies used over time before AFH is enabled.


Figure 3. Frequencies used over time after AFH is enabled.

Areas not defined in the specification include channel classification algorithms. This allows developers of Bluetooth products to use their own different methods for these, and they are then able to compete with each other in the market place. The question of whether to define how to perform channel assessment was a hotly debated subject. It was also undecided if timing requirements should be placed on the implementations that could be tested during qualification.

Channel Classification

Channel classification can be done using two basic methods: either by measuring the packet error rate, or by measuring the received signal strength. The packet error rate gives a direct indication of how many packets for each frequency were not received correctly, and can be used on the master to determine which channels should be marked as bad. The slave can use any spare time to measure the received signal strength of all the channels periodically and to determine if any channels have slightly higher signal strength than the normal background energy. These channels would probably be identified as bad to the master.

It was decided that no specification should be defined for channel classification. However, most implementations can now classify and signal bad channels in just a few seconds, much faster than originally imagined, showing how powerful market demand can be.

Another requirement of inclusion of new technologies into the Bluetooth specification is that they must be backwards compatible with specifications that were already adopted. That is to say that if AFH is to be included in the latest version 1.2 of the Bluetooth specification, it must not impede discoverability or connectivity with any other Bluetooth devices, including those built according to an earlier specification. Also, the associated changes that also needed to be made in the BLM, HCI and GAP must all be backwards compatible. These changes were written up as change requests on the specification.

The specification change requests were debated, incorporated into the current specification, reviewed again, and then adopted for prototyping. During the adoption for prototyping period, no commercial products could be sold. However, prototypes could be built and extensively tested to ensure interoperability. Problems found during interoperability testing resulted in either a change or clarification in the specification, or a redesign of a complete section. AFH started its testing early, and by the end of the third interoperability session no further problems were found. The interoperability requirements of the Bluetooth SIG require a minimum of three independent implementations of each improvement before it can be adopted and then used in commercial products. AFH achieved approximately a dozen implementations, all working perfectly, a testament to the quality of the process used.

Interoperability Testing

Interoperability testing was performed as private working group testing events as well as at interoperability testing events co-located with the Bluetooth Unplugfests: open events where anybody can test their Bluetooth products under complete non-disclosure agreements with all other platforms. These events have been very successful in increasing and ensuring interoperability after the specifications have been released. AFH is still being tested at these events even though its now been adopted for many months.

The first wave of Bluetooth products to include AFH is now appearing on the market. This development is particularly relevant as Bluetooth enabled mobile handsets, headsets and WLANs become ubiquitous. As the 2.4 GHz band becomes more crowded, it has become imperative that devices employ some kind of intelligence that allows them to be aware of other wireless devices, and to behave in a manner that will not add to frequency band clogging. Because of the way the Bluetooth SIG works, and through such groups as the Coexistence Working Group, the Bluetooth community not only demonstrates that it can coexist with itself, but also welcomes the challenge of coexisting with other seemingly competing wireless technologies. By recognizing the full picture of the space in which Bluetooth lives, designers are able to ensure that its success continues and grows as well as allowing others space.

Glossary of Acronyms
AFH - Adaptive Frequency Hopping

BLI - Baseband Link Manager

FCC - Federal Communications Commission

FHSS - Frequency Hopping Spread Spectrum

GAP - General Access Protocol

HCI - Host Controller Interface

LMP - Link Manager Protocol

SIG - Special Interest Group

WiFi - Wireless High-Fidelity

WLAN - Wireless Local Area Network

WPAN - Wireless Personal Area Network

Advertisement

Share this Story

X
You may login with either your assigned username or your e-mail address.
The password field is case sensitive.
Loading