Bluetooth has a lot to offer the handset developer. Quick, easy connections between devices can turn a handset into a convenient modem for a laptop or PDA, for example.
Integrating Bluetooth functionality in to a cell phone, however, is not an easy task. While Bluetooth and cell phones operate at different frequencies, costly interference can be encountered in the RF front end. Additionally, implementing Bluetooth in a mobile architecture forces design engineers to make some tough hardware and software choices in the baseband section of a mobile architecture.
In this article, we'll look at some of the key choices that designers face when implementing Bluetooth in a mobile architecture. Specifically, we'll focus on software integration, hardware integration, and RF compatibility issues raised by integrating Bluetooth into a GSM cellular system.
RF Integration
Probably the biggest headache for design engineers is ensuring co-existence between the Bluetooth and GSM radios when they are in the same system architecture. One of the key concerns here is protecting the GSM transceiver from spurious radiate products created by the Bluetooth front end.
The minimum sensitivity of a GSM receiver is -102 dBm (note: many GSM receivers achieve a -108 dBm sensitivity figure). The required carrier-to-noise for GMSK, the main GSM modulation scheme, is 5 dB and for minimum impairment any spurious should be an extra 10 dB lower. Thus, the target protection for GSM is approximately -122dBm.
The Bluetooth specification, on the other hand, calls for testing to prove spurious better than -36 dBm measured in 1 MHz steps across the 30 MHz to 1GHz. Therefore, there is roughly an 86 dB gap between the performance of the Bluetooth receiver and the requirements of a GSM mobile.
This gap is not as insurmountable as it may first appear. A number of design techniques are available to bridge the sensitivity gap between Bluetooth and GSM transceivers.
In most GSM phones housing Bluetooth, the transceivers are not directly coupled together. There is antenna isolation due to transmission loss from one antenna to the other and due to the narrowband nature of the antennas. This antenna coupling loss cannot be assumed to be very large, perhaps only 10 dB, with an extra 5 dB for the antenna filtering action.
Positioning of the handset can also impact coexistence between the receivers. There is no way to control how an end user will position a handset. Therefore, designers must account for users placing the handset on a metal filing cabinet or in a car glove box, which could both couple and detune the antennas.
When dealing with noise issues, designers need to be concerned with narrowband and broadband spurious component(Figure 1). Narrowband spurious components are generated when the IF, local oscillator (LO), synthesiser comparison, and crystal reference frequencies from both Bluetooth and GSM radios are mixed together in the same mobile phone architecture.
Figure 1: Diagram of the narrowband and broadband spurious in the 1900 MHz band.
For mobile phone designers, the solution to this problem lies in knowledge of the Bluetooth chip architecture. Many of the commercial Bluetooth radios use a low IF or direct conversion receiver architecture and operate from full-frequency, 2.4 GHz oscillators or half-frequency oscillators. If the Bluetooth chips employ a sensible synthesizer comparison frequency, designers can account for any potential spurious signals, if there any at all, in the GSM bands.
A More Insidious Problem
Broadband noise is a more insidious problem. If the Bluetooth module is generating sufficient broadband noise it could reduce the sensitivity of all the GSM channels.
The target broadband spurious protection figure for GSM is approximately -122 dBm at 160 kHz, which equates to a thermal noise floor of -174 dBm/Hz. The equivalent output from the Bluetooth module assuming 15 dB antenna loss is only 15 dB above this noise floor. If the Bluetooth output filter has attenuation at the GSM band of 40 dB, the Bluetooth module's power amplifier must provide a noise floor of -120 dBm/Hz at the output.
This is not so much a limitation of the output amplifier as the modulator. Assuming a class 3 output with 0 dBm nominal output power, it requires a VCO and an I/Q modulator, if used, with a noise floor of at least -122 dBc/Hz. These figures are achievable, but in a low-cost Bluetooth IC place fairly strict requirements on tolerances.
Protecting Bluetooth Reception
While we've spent a good deal of time looking at the impact Bluetooth has on a GSM radio, it's also important to explore the impact that a GSM radio has on a Bluetooth product when housed in a mobile architecture.
Similar to the GSM radio, designers must be concerned about the impact of spurious signals form the GSM radio on the Bluetooth transceiver. The minimum sensitivity of a Bluetooth receiver is defined as -70 dBm. The required carrier-to-noise for demodulating Bluetooth's FSK modulation is about 19 dB. Thus, the absolute minimum protection for Bluetooth reception is -89 dBm. Since there are more sensitive receivers and an extra 10dB margin is needed for negligible impairment, a spurious level below -99 dBm is needed.
The GSM type approval calls for spurious at 1 to 12.75 GHz to be below -30 dBm measured in 100 kHz steps. Again there is a large gap, of 70 to 80 dB, between requirement and verified immunity.
In general, GSM chips are more complicated than Bluetooth chips. This allows more scope for the generation of spurious products from the IF, LO, synthesiser comparison, and crystal reference frequencies.
Fortunately, knowledge of the GSM chip architecture makes it possible to predict where spurious products can be generated. Choosing IF frequencies and LO frequencies whose lower order harmonic sums and differences do not cross the Bluetooth band is probably the only way to ensure that there are no blocked Bluetooth channels. The effect of a blocked channel depends on the data profile being carried, but in general, data will be automatically be retransmitted and audio will suffer some muting.
Similar to above, designers must also consider the impact that broadband noise, generated by the GSM transceiver, has on the Bluetooth radio. As stated above, Broadband noise protection of the Bluetooth receiver needs to be -99 dBm within a 1 MHz channel. This is equivalent to -159 dBm/Hz noise floor, which is only 15 dB above the room temperature thermal noise floor.
This requirement should not be hard to achieve with GSM phones, which do not use diplexers, and yet still have to meet very low noise emissions of -79 dBm or -71 dBm in the GSM receive channels. To avoid broadband spurious signals, designers can implement offset loop power oscillator followed by a power amplifier offering limited gain and the ability to generate wideband noise. Note: To avoid broadband noise, an antenna coupling factor of 15 dB and the natural roll off of power amplifier gain must be taken into account.
The Software Element
While RF issues plague designers, software integration is equally as challenging. When implementing Bluetooth software, the main questions designer must grapple with is: Should the required profiles, upper stack, and lower stack remain housed in an embedded Bluetooth module or should the embedded host CPU serve as a host for some or all of this software? Here's a look at the pluses and minuses of both options.
Figure 2 highlights a mobile phone architecture that turns to a complete embedded Bluetooth module for housing all upper and lower stack functionality as well as all Bluetooth profiles.
Figure 2: Example of a mobile phone architecture where the Bluetooth protocol stacks and profiles remain housed in an embedded module.
Interfacing to an embedded module can offer several advantages over an implementation where the protocol stack and profiles are resident on the host processor. One is that by linking to an embedded module, processing overhead is eliminated from the host CPU or DSP. Additionally, by using this option, GSM and Bluetooth software can be developed separately, thus speeding software time. Next, in certain handset architectures, this may be viewed as a potentially lower risk development.
The potential drawbacks with the embedded solution are that the module will require a more powerful baseband processor with more of its own RAM and ROM. Also, it is less flexible since not all modules or chipsets are available with the upper stack and profiles. It will also require proprietary application level interface software to be developed on both the module and the host processor.
Another option is to house some of the Bluetooth protocol stack and profiles in the embedded host processor. Specifically, an embedded Bluetooth module will be tasked with handling the lower layer protocol stacks while the mobile phone's embedded processor will handle the upper layer stacks and profiles. Note: This integration point occurs at the host communications interface (HCI).
Figure 3 highlights the split software approach described above. In this figure, the major Bluetooth software components are split between the host processor and the Bluetooth module.
Figure 3: In some situations designers GSM designers may want the Bluetooth module to handle lower layer Bluetooth stack operation while the mobiles host processor handles upper layer stack tasks.
Interfacing at HCI level has the potential to offer the following advantages over the embedded solution:
- Future flexibility: HCI interface will allow operation with many different module and chipset suppliers, since not all modules, or IC's, are available with the upper stack embedded;
- Future reuse: The profiles and upper stack that have been ported onto the host processor can be reused on future products;
- Future upgrades: New profiles can be added to the host processor in the same manner as the handset manufacturer updates their existing software. An embedded solution would require proprietary software to be developed in order to support this;
- The proprietary Bluetooth API interface software is only required on the host processor;
- There is a well-defined physical interface.
Before embarking on the HCI level interface option, one key issue must be addressed. This approach will clearly place more overhead on the host CPU. Therefore, before embarking on this method, phone designers must ensure that the host CPU can support the required MIPS, ROM and RAM for running the upper stack and profiles.
A potential drawback with the HCI level solution is that the upper stack and profiles will have to be integrated with the host processor software. This could be seen as introducing an avoidable risk to the completion of the handset.
Another option is to implement the entire Bluetooth protocol stacks and profiles in the host processor. This approach, however, has strong pros and cons.
On the positive side, this method allows designers to eliminate a baseband component and, thus, integrate Bluetooth functionality by simply adding another RF IC. And, by requiring only a single IC, designers can implement added functionality without huge penalties on size and space.
There are, however, some negatives. First, and most important, developing a qualified Bluetooth protocol stack represents many man-years of development. Designers, of course can source the stack from third part companies. But, could provide some tough integration challenges at the baseband level.
And, let's not forget processing overhead. In the near future, mobile phone basebands will be tasked with supporting W-CDMA, GSM, MPEG-4, and a host of other options, forcing the host CPU to support Bluetooth functionality as well, could create some huge processing headaches.
The Embedded Challenge
Handset manufacturers often find it harder to predict the production volumes of accessories than actual handsets. Consequently, a solution that allows the manufacturer to configure a handset as either Bluetooth enabled or not is most appealing. This need for flexibility precludes adopting a fully integrated solution in the short term, making a SIM style or battery pack module particularly attractive for manufactures.
As Bluetooth become more of a de-facto function, however, designers will be forced more often to integrate Bluetooth functionality within the handset architecture. And when this happens, the RF and software integration issues described above will take center stage.
Bill Murray is a chartered engineer at Tality. He received his engineering degree in applied science at Queens College, St Andrews. He then spent twenty years working on analog and advanced digital modulation systems in the BBC. Bill can be reached at billmur@tality.com.
Paul Buggs is a principal engineer with Tality. Paul has a MSC in microelectronics system design from Brunel University, London, UK. Paul can be reached at pbuggs@tality.com.
