Adaptive Frequency Hopping for Reduced Interference between Bluetooth® and Wireless LAN

by Charles Hodgdon
Ericsson Technology Licensing
May 2003

1. Abstract

Devices communicating by means of Bluetooth wireless technology run the risk of causing and encountering interference in environments where other wireless technologies are in use. Wireless LAN and other applications based on the IEEE 802.11 specification are the most relevant examples of such technologies. These operate in the same unlicensed 2.4 GHz ISM (Industrial, Scientific and Medical) radio band as does Bluetooth.

To improve performance in these environments, a technique known as Adaptive Frequency Hopping has been introduced by the Bluetooth Special Interest Group (SIG) to diminish the impact of such interference. Also referred to as AFH, this technique can be implemented through various methods, each with its own inherent set of advantages and drawbacks. Ericsson, a leader in the field of Bluetooth wireless technology, uses a method well suited for its broad based Bluetooth design solution sold as intellectual property (IP). Ericsson’s implementation of AFH is further enhanced through the use of other standard and proprietary techniques, providing excellent audio quality for voice centric applications in the presence of multiple wireless technologies.

2. Introduction

While Bluetooth and Wireless LAN, also known as WLAN, were earlier labeled as competing technologies, manufacturers have discovered over time that this is not necessarily the case. Some have even gone so far as to develop products that feature both technologies, such as wireless access points. There is now widespread market acceptance of both Bluetooth and WLAN, which has lead to a greater incidence of coexistence between the two, most commonly in computer network environments.

Coexistence in the unlicensed 2.4 GHz band however, comes with a price. Unlicensed means that competing, or complementary, technologies are free to operate in this frequency band, which has in turn given rise to interference that impinges on the quality of communication. To most users, deterioration of quality may be more apparent in voice centric applications than in data centric applications. For example, one is more likely to be aware of poor sound quality while using a Bluetooth headset than of the extent to which data packets must be retransmitted between one’s notebook PC and a network access point.

The Bluetooth industry, through the Bluetooth SIG, has responded by taking measures to reduce interference in environments where multiple wireless technologies coexist. Version 1.2 of the Bluetooth Specification, being adopted in 2003, includes Adaptive Frequency Hopping, a technique proven to be an effective remedy to the problem of interference in WLAN and similar environments.

3. How AFH works

Bluetooth products developed prior to the emergence of working AFH solutions employ another form of frequency hopping, which is random by design. These first generation Bluetooth devices use 79 of the 83.5 available channels in the 2.4 GHz band, hopping across these channels in a random fashion and at a rate of 1600 times per second. As soon as another wireless device is introduced into the environment this type of hopping results in occasional collisions. Without AFH Bluetooth lacks the ability to avoid these conflicts, and thus to adapt to its environment. The result is illustrated in Figure 2.1 below, showing an environment where both Bluetooth (BT) and Wireless LAN (WLAN) are in operation.

Figure 2.1 — Collisions resulting from random frequency hopping Adapting to the environment

In contrast to the above, Adaptive Frequency Hopping allows Bluetooth to adapt to the environment by identifying fixed sources of interference and excluding them from the list of available channels. This process of re-mapping also involves reducing the number of channels to be used by Bluetooth. The Bluetooth Specification requires a minimum set of at least twenty channels. Figure 2.2 shows the same environment as illustrated above, but now with Adaptive Frequency Hopping activated.

Figure 2.2 — Collisions avoided using Adaptive Frequency Hopping

Identifying “bad” channels

The Bluetooth Specification does not dictate how bad channels are to be identified, a process commonly referred to as ‘Channel Assessment,’ so developers implementing AFH are faced with the task of selecting the most appropriate method for each particular solution. Currently there are two prevailing methods for performing Channel Assessment with Adaptive Frequency Hopping: RSSI (Received Signal Strength Indication) and PER (Packet Error Rate).

Both RSSI and PER are well known techniques for determining which channels may already be occupied. These two methods differ, however, when it comes to maintaining a perception of the current channel status. The method used by PER for repeatedly testing and reassessing bad channels is less accurate than RSSI, and can lead to temporary setbacks. Yet there are a number of other concerns when using RSSI, such as the fact that RSSI consumes more power than PER. RSSI can also require that bandwidth be taken from other functions when there is a lack of available slots.

Same Channel Communication

To further improve resilience against frequency static interferers like WLAN devices, AFH requires that Bluetooth devices communicate using the Same Channel Method. Normally, slaves respond using another frequency channel than that used by the master. With AFH, however, both master and slave communicate over the same frequency channel. This is done to avoid instances where the master transmits on a “good” channel while the slave responds on a “bad” one (or vice versa), as this would lead to several retransmissions.

Since the master and slave transmit on the same frequency, the channel hopping rate is reduced by 50% to just 800 times per second. While this can render Bluetooth devices more sensitive to interference from other Bluetooth devices, the benefit derived from doing so far outweighs this minor drawback. Furthermore, the Same Channel Method is useful for Channel Assessment, and essentially makes channel classification by slaves redundant.

4. Changes in SIG specification

To facilitate the introduction of AFH it was necessary for the Bluetooth SIG to update the Bluetooth Specification concerning the baseband, Link Manager Protocol (LMP) and Host Controller Interface (HCI). These changes, among others, are included in version 1.2 of the Bluetooth Specification, currently being adopted. As the qualification process for the new specification advances, additional changes will be required concerning the test specifications as well.

Baseband

The updated baseband describes the algorithm used for generating an adapted hop channel set. This operation is performed through an added function for re-mapping the hop channel set as illustrated in Figure 4.1 below.

Figure 4.1 — Algorithm includes added re-mapping function

LMP

The Link Manager Protocol has been updated with the addition of new messages for communicating the bit mask that identifies which channels may be used and which are to be avoided. The bit mask consists of 79 bits, with the first bit representing channel 0 and the last bit representing channel 78. A bit value of 1 indicates that the channel is to be used, while a value of 0 specifies that the channel be excluded from the hop set.

In some implementations of AFH Bluetooth slaves may also be empowered to perform Channel Assessment, i.e. to identify bad channels. In order for this function to be of use, further modifications have been made to the LMP, enabling the master to retrieve this information through requests to the slaves. The master is then able to use the information acquired from the slaves when generating the new hop set.

HCI

Modification of the Host Controller Interface consists basically of two new commands. The first is used to exclude certain channels from the list of possibles. The HCI may not dictate which channels are to be used, but does have the ability to discard certain channels. One example is the co-location of Bluetooth and WLAN in a notebook PC. If the host controller is aware that WLAN is installed and running on the PC, it can then send a command instructing that all channels used by WLAN be avoided. The other HCI command introduced for AFH enables the host to obtain the channel map currently in use.

5. Is AFH good enough?

AFH is designed to identify and exclude channels that are in continuous use by other devices or technologies, i.e. static sources of interference. WLAN, for example, occupies a bandwidth of 20 MHz and does not perform any type of frequency hopping. The algorithms implemented for AFH identify these channels with no difficulty, and perform the desired re-mapping. Devices using frequency hopping, however, such as other Bluetooth devices, are likely to cause just as much interference as they normally would.

Another matter is that of co-location, i.e. when both WLAN and Bluetooth are present in the same device. AFH protects well against interference as long as WLAN and Bluetooth are not co-located. This issue is however being addressed by other, collaborative techniques.

The answer to the question of whether or not AFH is good enough is also dependent upon just how the technique is implemented. The Bluetooth Specification requires that the Bluetooth host controller be capable of sending a command dictating which channels are bad and therefore not to be used. The host, however, cannot always be relied upon to know which frequencies are being used by other systems. Therefore, in order for AFH to be truly effective the link manager must be able to perform Channel Assessment, something not stipulated by the Specification but necessary for achieving a truly effective implementation of AFH.

6. Ericsson’s implementation of AFH

At first glance implementing Adaptive Frequency Hopping may not seem like much of a challenge, it being a fairly simple concept. But the existence of several special cases such as disabling AFH for Park mode, as well as the fact that AFH can be controlled bi-directionally, makes the implementation more complicated. Making it work is one matter, but making it perform optimally is another. This is where long experience and a deep understanding of Bluetooth wireless technology provide a significant advantage.

Ericsson’s implementation of AFH is built on efficient algorithms and filters enabling the link manager to successfully perform Channel Assessment and making AFH far more effective than is required by the Bluetooth Specification. The following criteria have been applied when developing an AFH solution for integration with Ericsson’s Bluetooth IP design solutions:

• Lowest impact on CPU load for minimal power consumption
• Smallest footprint concerning both software and hardware
• Easiest integration with a wide range of radio chips

Added features

Ericsson’s implementation of AFH is further enhanced by additional techniques aimed at boosting sound quality. One of these is Extended SCO, another new feature of Bluetooth 1.2. This function makes it possible to detect and to re-transmit lost or destroyed voice packets bi-directionally, with virtually no reduction of realtime performance. Another feature called PPEC (Pitch Period Error Concealment) is an Ericsson proprietary technique for filling in missing voice samples in the baseband audio modulation. Working together these techniques offer excellent voice quality in voice centric applications, which is always a primary concern for Ericsson in the development of Bluetooth wireless technology.

The Bluetooth wordmark and logos are trademarks owned by the Bluetooth SIG, Inc., and are used by Ericsson Technology Licensing under license. Third party brands and names are the property of their respective owners. Product specifications are subject to change without notice.

© 2003 Ericsson Technology Licensing AB, SE-221 83 Lund, Sweden.

Printed in June 2003, LZT 108 6699