Courtesy of Mobile Handset DesignLine
(06/18/2007 3:10 PM EDT)
Here are the basics of WiMAX/Bluetooth coexistence and a proposed solution to ensure the simultaneous and flawless interface operation to maintain their inherent high performance with standard, commercial Bluetooth and WiFi gear.
By Yigal Bitran, Eran Eshed, Altair Semiconductor
Mobile handsets are rapidly evolving from simple cellular phones to versatile multi-mode, multi-media devices with a plethora of connective capabilities. This development has the potential to benefit users, carriers, web-services providers and application developers, but it is also fraught with difficulty for handset OEM’s due to intractable interference issues between certain radio protocols. Examples include:
* Bluetooth; a standard feature in mid/high-end phones that provides short range connectivity to headsets, laptops (wireless PC modems and/or synchronizing capability), and such peripherals as printers
* WiFi, which enables users to access the Internet and make VoIP calls
* WiMAX, which will soon extend the same capabilities of WiFi through much greater range and robustness
Handset manufacturers realized years ago that frequency proximity between Bluetooth and WiFi (2.4GHz band), and the co-location of their respective antennas–combined with the fact that the two protocols are completely un-coordinated, posed a serious performance challenge to the point of malfunction. Bluetooth and WiFi chipsets vendors, who added coexistence interfaces to products, enabling arbitration over the shared radio frequency medium to prevent contention and signal degradation, resolved the issue.
With the advent of Mobile WiMAX (IEEE802.16e), OEMs face new interference challenges as the new protocol operates over several frequency bands (defined by ‘profiles” in WiMAX terminology), the most common being 2.3-2.4GHz and 2.5-2.7GHz. The frequency separation, although greater than between Bluetooth and WiFi, is still not enough to prevent coexistence problems.
A typical usage scenario where a user is conducting a cellular conversation via a Bluetooth headset, while simultaneously downloading email or browsing the Internet through the phone’s WiMAX air link, will necessitate 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 with end-users of Bluetooth and WiFi accessories (e.g. Bluetooth headsets, WiFi routers), the optimal solution must operate with the existing installed device base and not assume modifications to it.
WiMAX and Bluetooth interference
The previously described scenario will be used to analyze the interference pattern that emanates from WiMAX to Bluetooth air links, and determine its impact. Figure 1 shows a system comprised 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 in this example operates in the 2.5-2.7GHz band. The output power of the WiMAX Power Amplifier (PA) may be as high as +25dBm. The WiMAX and Bluetooth transmit antennas are in close proximity to each other, with the user’s hand, or the surface on which the handset is placed, typically causing 10dB path-loss between them. This yields a +15dBm signal at the Bluetooth Band Pass 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 Low Noise Amplifier (LNA).
Given the -27dBm Bluetooth rejection capability, it is clear that it is not capable of rejecting the WiMAX signal, and therefore blocking occurs. Moreover, such a strong signal in the Bluetooth LNA input might exceed the LNA’s maximum rating and cause severe reliability issues.
Click here for Figure 1.
For the purposes of 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 higher path loss from the handset to the headset, however interference on the local party’s end cannot be overlooked completely. Probable occurrence of such “clicks” is surprisingly high. Assuming the following scenario (explained in the next section), the Bluetooth receiver in the handset can be expected to be active ~1/6 of the time, and depending on the WiMAX usage scenario, will be blocked at increased frequency as traffic intensifies. As mentioned previously, there is a negative impact of Bluetooth transmission on WiMAX reception, but it is less severe.
Solving the coexistence challenge
Given the analysis of the scenario in the previous section, it is clear that nothing can be done to eliminate, or even mitigate the interference in the radio or Physical Layer (PHY) since it is inherent to the system. Therefore, 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.
There are various scenarios and use cases that need to be addressed, i.e. varying combinations of WiMAX, Bluetooth and WiFi transmission and reception, each in different link scanning, establishment, and activity modes. For illustrative continuity purposes, the same use case defined in the previous sections will be used to help explain the proposed coexistence solution. Later we will add a WiFi air link to the same use case–which is characterized by the following elements:
* An active WiMAX link between a mobile handset and a WiMAX base station
* An active Bluetooth voice link, operating in SCO/HV3 mode (the standard profile used by commercial Bluetooth headsets)
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 625us, 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 twenty-four 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 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 on the other hand, assuming it is the master over the Bluetooth link, has the ability to control the clock’s phase and synchronize it with that of the WiMAX link.
In cases where the master on the Bluetooth link is the headset—not the mobile phone), it is possible to perform a Master Slave Switch (“MSS” in Bluetooth terminology). 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. Figure 2 describes the time and phase relationship between the two air links.
Click here for Figure 2.
Having synchronized the two links and identified the fundamental, repetitive pattern, the next step is to establish a bandwidth allocation mechanism that takes into account 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 Cyclic Redundancy Check (CRC). As a result, any error will be noticeable as a “click” noise.
WiMAX frames are comprised of a MAP message, broadcast by a base station to all registered mobile stations, that maps the reception intervals for different mobile stations in the same WiMAX frame, while allocating transmission intervals in the subsequent WiMAX frame. Following the MAP message is a downlink interval, or “zone” (in WiMAX terminology), that is used for broadcast, multi-cast and uni-cast transmissions by the base station to the registered mobile stations. Following the downlink zone, there is an uplink zone for mobile stations that received transmission allocation times during the previous WiMAX frame, to transmit. This pattern is repeated for every WiMAX frame.
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 twenty four slots, or 25% of the time denoted “BLOCKED”). Now let us analyze the remaining 75% 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 mobile 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 not 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 underlying requisite concept for this scheme is the need for the WiMAX link to avoid transmissions during certain periods of time. This can be achieved in two ways:
1. The mobile handset can use one of the WiMAX sleep modes to avoid interacting with the base station during the relevant periods of time. The drawback of this method, is the possibility of packet error rate (PER) in the WiMAX transmissions occurring during Bluetooth slots “B13” and “B14”, but which has a low probability of occurrence, and in any event, can be mitigated by Forward Error Correction (FEC) and retransmissions effective in WiMAX.
2. Based upon pre-negotiated handset capability information, the base station scheduler refrains from making receive and transmit allocations during the two slots “B13” and “B14”. This technique requires a small addition to the WiMAX standard to support coexistence capability negotiation between the handset and base station.
The addition of WiFi into the coexistence scheme is relatively simple. WiFi, similarly to Ethernet, is a Carrier Sense Multiple Access/Collision Detect (CSMA/CD) protocol, which is not based on time allocations, but rather collision detection and random back off usage.
It is impossible then to synchronize an asynchronous protocol to the proposed coexistence scheme. It can, however be solved by using a mode in WiFi called Unscheduled Automatic Power Save Delivery (U-APSD). In this mode, which is normally used to minimize WiFi station power consumption, the handset may enter sleep mode and 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 way this mode is used in the proposed coexistence scheme, is to force the handset WiFi-mode into U-APSD sleep mode during intervals “B1”-“B2”, “B7”-“B14”, “B19”-“B20” and “B23”-“B24,” and remaining active during the rest (ten out of twenty four, or 42%). The resulting impact on WiFi throughput is marginal and insignificant.
The rest of the slots in Figure 2 (marked “OP”), represent transmission and reception opportunities that may or may not be available for a certain air link, and could be assigned using any conventional priority algorithm. The advantages
The advantages of the proposed coexistence scheme are:
1. Eliminates the coexistence problem with only marginal throughput penalty
2. Operates with any commercial WiMAX base station, WiFi access point (supporting U-APSD, as most do) and Bluetooth headset.
3. Requires no hardware changes to commercial Bluetooth and WiFi handset chipsets
The coexistence of WiMAX, Bluetooth and WiFi in handsets and handheld devices poses an engineering challenge as their transmission over adjacent radio frequency bands may conflict and severely degrade performance. The proposed coexistence scheme eliminates this challenge by synchronizing the WiMAX and Bluetooth clocks, time-sharing the radio frequency band (in a way that minimizes the performance impact on the respective radio links), and operating WiFi in U-APSD mode.
About the Authors
Yigal Bitran is a co-founder and Chief Technology Officer at Altair Semiconductor. Previously, Yigal worked at Texas Instruments where he was CTO of the Broadband Communications Group in Israel. Prior to TI, he served as Vice President of R&D at Libit Signal Processing, which was acquired by TI in 1999. Yigal Bitran has authored more than 20 patents and published numerous papers in a broad range of scientific and technical publications. He holds a B.Sc. and M.Sc. (Cum Laude) in Electrical Engineering from Tel Aviv University and an Executive MBA from the Kellogg-Recanati Program.
Eran Eshed is a co-founder and Vice President of Marketing and Business Development at Altair Semiconductor. Previously, he worked at Texas Instruments as Director of Cable Modem Marketing. Prior to that, he held various hardware and silicon development and management positions at TI and Libit Signal Processing. Eran holds a B.Sc. in Electrical Engineering from the Tel Aviv University. He can be reached at: Eran@altair-semi.com