Let WiMAX, Bluetooth, Wi-Fi coexist in handsets

Posted: 17 Sep 2007

Mobile handsets are rapidly evolving from simple cellphones into versatile multimode, multimedia devices with a plethora of connective capabilities. This development has the potential to benefit users, carriers, service providers and application developers, but it is also fraught with difficulty for handset OEMs due to intractable interference issues between certain radio protocols, such as:

‥ Bluetooth—A standard feature in midrange and high-end phones, it provides short-range connectivity to headsets, laptops (wireless PC modems and/or synchronizing capability) and peripherals such as printers.

‥ Wi-Fi—It enables users to access the Internet and make VoIP calls.

‥ WiMAX—It will soon extend the same capabilities of Wi-Fi through much greater range and robustness.

Handset manufacturers have realized that frequency proximity between Bluetooth and Wi-Fi (2.4GHz band), the co-location of their respective antennas, and the fact that the two protocols were completely uncoordinated posed a serious performance challenge to the point of malfunction. Bluetooth and Wi-Fi chipsets vendors, who added coexistence interfaces to products to enable arbitration over the shared RF medium to prevent contention and signal degradation, resolved the issue.

With the advent of Mobile WiMAX (IEEE 802.16e), OEMs face new interference challenges as the new protocol operates over several frequency bands, the most common being 2.3-2.4GHz and 2.5-2.7GHz. The frequency separation—although greater than between Bluetooth and Wi-Fi—is still not enough to prevent coexistence problems.

A typical usage scenario involves a user conducting a cellular conversation via a Bluetooth headset while simultaneously downloading e-mail or browsing the Internet through the phone's WiMAX air link. This scenario requires a mechanism to guarantee the coexistence of wireless interfaces. Without such a mechanism, voice quality and packet throughput degradation will result in a poor user experience. Given the prevalence and popularity of Bluetooth and Wi-Fi accessories to end-users, the optimal solution must operate with the existing installed device base and not assume modifications to it.

Signal interference
Figure 2 shows a system composed of a Bluetooth headset and a WiMAX-enabled mobile handset. The transmit power of a Bluetooth headset is 0dBm. When the signal is received at the handset antenna, its power level is -40dBm. The Bluetooth specification requires the receiver to handle interfering signals of up to -27dBm.

The handset WiMAX transmitter operates in the 2.5-2.7GHz band. The output power of the WiMAX power amplifier may be as high as 25dBm. The WiMAX and Bluetooth transmit antennas are close to each other. The user's hand or the surface on which the handset is placed typically cause 10dB path loss between them. This yields a +15dBm signal at the Bluetooth bandpass filter (BPF) input. The BPF must pass frequencies of up to 2.48GHz (the highest Bluetooth hopping frequency). Hence, it is unable to reject more than 3dB of the undesired WiMAX signal and so passes at least 12dBm of interference signal to the Bluetooth LNA.

Given the -27dBm Bluetooth rejection capability, it is clear that it's not capable of rejecting the WiMAX signal. Thus, blocking occurs. Moreover, such a strong signal in the Bluetooth LNA input might exceed the LNA's maximum rating and cause severe reliability issues.

In this discussion, the term "local party" denotes the party using the handset and the term "remote party" denotes the party on the other side of the conversation. Whenever the handset Bluetooth reception is blocked by a WiMAX transmission, a "click" is heard on the remote party's end.

The impact of the WiMAX blocking on the local party is less severe due to the higher path loss from the handset to the headset. Interference on the local party's end, however, cannot be overlooked completely. Probable occurrence of such "clicks" is surprisingly high.

Shown is a system composed of a Bluetooth headset and a WiMAX-enabled mobile handset. (Click to view image.)

Via higher layer
It is clear that nothing can be done to eliminate or even mitigate the interference in the radio or PHY layer since it is inherent to the system. Thus, the solution must be provided via a higher layer—i.e. the media access control (MAC) layer. In the MAC layer, it is possible to perform synchronization between the different protocols and ensure that bandwidth over the shared spectrum is allocated in a time-multiplexed, non-concurrent yet fair basis. Such a solution would eliminate any potential conflict and still maintain inherent link performance attributes.

The first step is to synchronize the protocol time bases. To do that, we must first find the lowest common denominator between the different system clocks and then ensure that they are coordinated. The Bluetooth SCO/HV3 profile's time base is 625µs, while the WiMAX time base is based on 5ms frames. This means that 15ms is the lowest common denominator time interval during which three WiMAX frames and 24 Bluetooth slots are processed. Once a solution is found to address the 15ms time interval, the repetitive pattern ensures that the solution is applicable to the mode as a whole.

Having identified the repetition pattern, it is necessary to ensure that the two time bases are synchronized and remain so throughout the concurrent operation of the links. Since the WiMAX base station determines time base, it is impossible for the mobile handset to control its phase relative to the Bluetooth time base. The Bluetooth chipset in the mobile handset (assuming it is the master over the Bluetooth link) can control the clock's phase and synchronize it with that of the WiMAX link.

In cases when the master on the Bluetooth link is the headset (not the mobile phone), it is possible to perform a master slave switch. Once it is established as "master," the handset Bluetooth chip can reset the link's clock and align it with the WiMAX clock, effectively synchronizing the two time bases. It may be required from time to time to re-sync the Bluetooth clock, as it is likely to drift relative to the WiMAX clock over a period of time.

Having synchronized the two links and identified the fundamental repetitive pattern, the next step is to establish a bandwidth allocation mechanism that considers the operation of both protocols. The Bluetooth SCO/HV3 profile defines a repetitive, six-slot period (3.75ms) during which only two consecutive slots are used for transmission, one for the master (denoted "M") and one for the slave (denoted "S"). During this interval, the mobile phone and the headset exchange uncompressed voice packets. The four other slots are unused. The profile is very basic and does not define any scheduling, jitter control (at the slot level), retransmission, error correction techniques or even CRC. As a result, any error will be noticeable as a "click" noise.

Given the basic nature of the Bluetooth voice profile, the fundamental guideline for ensuring proper concurrent operation is to guarantee uninterrupted Bluetooth transmit and receive slots. Hence, base stations must refrain from transmitting or allocating transmission opportunities to the mobile handset during these intervals (six out of 24 slots or 25 percent of the time denoted "Blocked"). Now, let us analyze the remaining 75 percent to understand which time intervals are available for the WiMAX link. Frame N is effectively unused by the mobile handset WiMAX link—the downlink interval is unused since the handset is not available to receive the MAP message at the beginning of the frame due to Bluetooth priority (slots B1 and B2). The uplink interval is also unused due to Bluetooth priority (slots B7 and B8).

During frame N + 1, the mobile handset is able to receive and decode the MAP message, allowing it to receive bursts transmitted during the interval between B10 and B12 (2.5ms) until the next Bluetooth allocation (slots B13 and B14). The uplink in frame N + 1, however, cannot be used by the mobile handset since it did not receive the MAP message of frame N, which allocated bandwidth for transmissions in the uplink interval of frame N + 1.

In frame N + 2, since Bluetooth occupies slots B19 and B20, the mobile handset will not be able to receive downlink traffic from the base station. The uplink interval of frame N + 2, which may have been assigned transmission opportunities in frame N + 1's MAP message, may be used for transmission by the mobile handset. The pattern then repeats itself as long as the two links remain active.

The addition of Wi-Fi into the coexistence scheme is relatively simple. Wi-Fi is a carrier sense multiple access/collision detect (CSMA/CD) protocol, which is not based on time allocations, but on collision detection and random back off usage.

It is impossible to synchronize an asynchronous protocol to the proposed coexistence scheme. However, it can be solved by using a mode in Wi-Fi called unscheduled automatic power save delivery (U-APSD). In this mode that is normally used to minimize Wi-Fi station power consumption, the handset may enter sleep mode. Moreover, the handset may have the access point buffer all the transmissions destined to the handset up to a predefined buffer size. When the handset exits sleep mode, it sends a trigger frame to the access point, which in turn, bursts all of its buffered data to the handset, effectively maintaining similar performance to normal CSMA/CD operation.

The mode is used in such a way to force the handset Wi-Fi mode into U-APSD sleep mode during intervals B1-B2, B7-B14, B19-B20 and B23-B24, and remaining active during the rest (10 out of 24 or 42 percent). The resulting impact on Wi-Fi throughput is marginal and insignificant.

Advantages
This scheme eliminates the coexistence problem with only marginal throughput penalty, and it operates with any commercial WiMAX base station, Wi-Fi access point (supporting U-APSD, as most do) and Bluetooth headset. Moreover, it requires no hardware changes to commercial Bluetooth and Wi-Fi handset chipsets.

- Yigal Bitran
Co-founder and Chief Technology Officer

Eran Eshed
Co-founder and Vice President, Marketing and Business Development

Let WiMAX, Bluetooth, Wi-Fi coexist in handsets
Posted: 17 Sep 2007

Mobile handsets are rapidly evolving from simple cellphones into versatile multimode, multimedia devices with a plethora of connective capabilities. This development has the potential to benefit users, carriers, service providers and application developers, but it is also fraught with difficulty for handset OEMs due to intractable interference issues between certain radio protocols, such as:

‥ Bluetooth—A standard feature in midrange and high-end phones, it provides short-range connectivity to headsets, laptops (wireless PC modems and/or synchronizing capability) and peripherals such as printers.

‥ Wi-Fi—It enables users to access the Internet and make VoIP calls.

‥ WiMAX—It will soon extend the same capabilities of Wi-Fi through much greater range and robustness.

Handset manufacturers have realized that frequency proximity between Bluetooth and Wi-Fi (2.4GHz band), the co-location of their respective antennas, and the fact that the two protocols were completely uncoordinated posed a serious performance challenge to the point of malfunction. Bluetooth and Wi-Fi chipsets vendors, who added coexistence interfaces to products to enable arbitration over the shared RF medium to prevent contention and signal degradation, resolved the issue.

With the advent of Mobile WiMAX (IEEE 802.16e), OEMs face new interference challenges as the new protocol operates over several frequency bands, the most common being 2.3-2.4GHz and 2.5-2.7GHz. The frequency separation—although greater than between Bluetooth and Wi-Fi—is still not enough to prevent coexistence problems.

A typical usage scenario involves a user conducting a cellular conversation via a Bluetooth headset while simultaneously downloading e-mail or browsing the Internet through the phone's WiMAX air link. This scenario requires a mechanism to guarantee the coexistence of wireless interfaces. Without such a mechanism, voice quality and packet throughput degradation will result in a poor user experience. Given the prevalence and popularity of Bluetooth and Wi-Fi accessories to end-users, the optimal solution must operate with the existing installed device base and not assume modifications to it.

Signal interference
Figure 2 shows a system composed of a Bluetooth headset and a WiMAX-enabled mobile handset. The transmit power of a Bluetooth headset is 0dBm. When the signal is received at the handset antenna, its power level is -40dBm. The Bluetooth specification requires the receiver to handle interfering signals of up to -27dBm.

The handset WiMAX transmitter operates in the 2.5-2.7GHz band. The output power of the WiMAX power amplifier may be as high as 25dBm. The WiMAX and Bluetooth transmit antennas are close to each other. The user's hand or the surface on which the handset is placed typically cause 10dB path loss between them. This yields a +15dBm signal at the Bluetooth bandpass filter (BPF) input. The BPF must pass frequencies of up to 2.48GHz (the highest Bluetooth hopping frequency). Hence, it is unable to reject more than 3dB of the undesired WiMAX signal and so passes at least 12dBm of interference signal to the Bluetooth LNA.

Given the -27dBm Bluetooth rejection capability, it is clear that it's not capable of rejecting the WiMAX signal. Thus, blocking occurs. Moreover, such a strong signal in the Bluetooth LNA input might exceed the LNA's maximum rating and cause severe reliability issues.

In this discussion, the term "local party" denotes the party using the handset and the term "remote party" denotes the party on the other side of the conversation. Whenever the handset Bluetooth reception is blocked by a WiMAX transmission, a "click" is heard on the remote party's end.

The impact of the WiMAX blocking on the local party is less severe due to the higher path loss from the handset to the headset. Interference on the local party's end, however, cannot be overlooked completely. Probable occurrence of such "clicks" is surprisingly high.

Shown is a system composed of a Bluetooth headset and a WiMAX-enabled mobile handset. (Click to view image.)

Via higher layer
It is clear that nothing can be done to eliminate or even mitigate the interference in the radio or PHY layer since it is inherent to the system. Thus, the solution must be provided via a higher layer—i.e. the media access control (MAC) layer. In the MAC layer, it is possible to perform synchronization between the different protocols and ensure that bandwidth over the shared spectrum is allocated in a time-multiplexed, non-concurrent yet fair basis. Such a solution would eliminate any potential conflict and still maintain inherent link performance attributes.

The first step is to synchronize the protocol time bases. To do that, we must first find the lowest common denominator between the different system clocks and then ensure that they are coordinated. The Bluetooth SCO/HV3 profile's time base is 625µs, while the WiMAX time base is based on 5ms frames. This means that 15ms is the lowest common denominator time interval during which three WiMAX frames and 24 Bluetooth slots are processed. Once a solution is found to address the 15ms time interval, the repetitive pattern ensures that the solution is applicable to the mode as a whole.

Having identified the repetition pattern, it is necessary to ensure that the two time bases are synchronized and remain so throughout the concurrent operation of the links. Since the WiMAX base station determines time base, it is impossible for the mobile handset to control its phase relative to the Bluetooth time base. The Bluetooth chipset in the mobile handset (assuming it is the master over the Bluetooth link) can control the clock's phase and synchronize it with that of the WiMAX link.

In cases when the master on the Bluetooth link is the headset (not the mobile phone), it is possible to perform a master slave switch. Once it is established as "master," the handset Bluetooth chip can reset the link's clock and align it with the WiMAX clock, effectively synchronizing the two time bases. It may be required from time to time to re-sync the Bluetooth clock, as it is likely to drift relative to the WiMAX clock over a period of time.

Having synchronized the two links and identified the fundamental repetitive pattern, the next step is to establish a bandwidth allocation mechanism that considers the operation of both protocols. The Bluetooth SCO/HV3 profile defines a repetitive, six-slot period (3.75ms) during which only two consecutive slots are used for transmission, one for the master (denoted "M") and one for the slave (denoted "S"). During this interval, the mobile phone and the headset exchange uncompressed voice packets. The four other slots are unused. The profile is very basic and does not define any scheduling, jitter control (at the slot level), retransmission, error correction techniques or even CRC. As a result, any error will be noticeable as a "click" noise.

Given the basic nature of the Bluetooth voice profile, the fundamental guideline for ensuring proper concurrent operation is to guarantee uninterrupted Bluetooth transmit and receive slots. Hence, base stations must refrain from transmitting or allocating transmission opportunities to the mobile handset during these intervals (six out of 24 slots or 25 percent of the time denoted "Blocked"). Now, let us analyze the remaining 75 percent to understand which time intervals are available for the WiMAX link. Frame N is effectively unused by the mobile handset WiMAX link—the downlink interval is unused since the handset is not available to receive the MAP message at the beginning of the frame due to Bluetooth priority (slots B1 and B2). The uplink interval is also unused due to Bluetooth priority (slots B7 and B8).

During frame N + 1, the mobile handset is able to receive and decode the MAP message, allowing it to receive bursts transmitted during the interval between B10 and B12 (2.5ms) until the next Bluetooth allocation (slots B13 and B14). The uplink in frame N + 1, however, cannot be used by the mobile handset since it did not receive the MAP message of frame N, which allocated bandwidth for transmissions in the uplink interval of frame N + 1.

In frame N + 2, since Bluetooth occupies slots B19 and B20, the mobile handset will not be able to receive downlink traffic from the base station. The uplink interval of frame N + 2, which may have been assigned transmission opportunities in frame N + 1's MAP message, may be used for transmission by the mobile handset. The pattern then repeats itself as long as the two links remain active.

The addition of Wi-Fi into the coexistence scheme is relatively simple. Wi-Fi is a carrier sense multiple access/collision detect (CSMA/CD) protocol, which is not based on time allocations, but on collision detection and random back off usage.

It is impossible to synchronize an asynchronous protocol to the proposed coexistence scheme. However, it can be solved by using a mode in Wi-Fi called unscheduled automatic power save delivery (U-APSD). In this mode that is normally used to minimize Wi-Fi station power consumption, the handset may enter sleep mode. Moreover, the handset may have the access point buffer all the transmissions destined to the handset up to a predefined buffer size. When the handset exits sleep mode, it sends a trigger frame to the access point, which in turn, bursts all of its buffered data to the handset, effectively maintaining similar performance to normal CSMA/CD operation.

The mode is used in such a way to force the handset Wi-Fi mode into U-APSD sleep mode during intervals B1-B2, B7-B14, B19-B20 and B23-B24, and remaining active during the rest (10 out of 24 or 42 percent). The resulting impact on Wi-Fi throughput is marginal and insignificant.

Advantages
This scheme eliminates the coexistence problem with only marginal throughput penalty, and it operates with any commercial WiMAX base station, Wi-Fi access point (supporting U-APSD, as most do) and Bluetooth headset. Moreover, it requires no hardware changes to commercial Bluetooth and Wi-Fi handset chipsets.

- Yigal Bitran
Co-founder and Chief Technology Officer

Eran Eshed
Co-founder and Vice President, Marketing and Business Development