There is an overwhelming desire to clear up the clutter of too many wires at work and at home. Bluetooth is the technology that will enable this type of wireless communication. Before this wireless utopia can be achieved, many issues, including interoperability, must be addressed.
By BurkGehring and Stelios Koutroubinas
Bluetooth is an open global standard intended to replace all kinds of cables using short-range radio technology. Originally conceived by Ericsson, IBM, Intel, Nokia, and Toshiba to develop an open specification for short-range wireless connectivity between laptop computers and cellular telephones, the Bluetooth Special Interest Group (SIG) has expanded to over 1,000 members. Since the market for Bluetooth devices is estimated to be as large as $3 billion by 2005, many designers will be incorporating Bluetooth connectivity into their designs. 1
Bluetooth devices will replace RS-232, parallel, Universal Serial Bus (USB), and other types of cables with a single, standard wireless connection. Thus, any Bluetooth-certified device will be able to communicate with any other Bluetooth-certified device. For example, a Bluetooth-certified personal digital assistant (PDA) or cellular phone will work with any personal computer equipped with a Bluetooth-certified card.
The earliest applications are expected to include cable replacement for laptops, PDAs, mobile phones, and digital cameras, to name a few. Bluetooth supports voice as well as data transmission, so headsets used in the office or home could also become wireless.
Because Bluetooth is a global standard that uses a universally-available unlicensed portion of the radio frequency spectrum, Bluetooth-certified devices will interact in the same way in any part of the world.
How does it work?
--------------------------------------------------------------------------------
Any Bluetooth system has four basic parts: a radio (RF section) that receives and transmits data and voice; a baseband or link control unit that processes the transmitted or received data; link management software that manages the transmission; and supporting application software.
Bluetooth radio. The Bluetooth radio is a short-distance, low-power radio that operates in the unlicensed spectrum of 2.4 GHz, using a nominal antenna power of 0 dBm. At 0 dBm, the range is 10 meters, meaning equipment must be within 10 meters of each other (about 33 feet) to communicate using the Bluetooth standard. Optionally, a range of 100 meters (about 328 feet) may be achieved by using an antenna power of 20 dBm. Data is transmitted at a maximum gross rate of up to 1 Mbps. Communication protocol overhead limits the practical data rate to a little over 721 kbps. Interference or being out of range may increase the bit error rate (BER) and require packets to be re-sent, further decreasing the achievable data rate.
The 2.4-GHz frequency is shared by other types of equipment: microwave ovens; LANs; and industrial, security, and medical applications. As a result, interference with Bluetooth devices seems inevitable. The Bluetooth specification addresses this issue by employing frequency-hopping spread-spectrum techniques. Bluetooth uses seventy-nine hop frequencies spaced 1 MHz apart in the frequency range of 2.402 to 2.480 GHz. The hop rate is 1,600 hops per second (625-�s dwell time, at each frequency). If the transmission encounters interference, it waits for the next frequency hop and re-transmits on a new frequency.
Baseband . In wireless communications, the baseband is the hardware that turns received radio signals into a digital form, which can be processed by the host application. It also converts digital or voice data into a form that can be transmitted using a radio signal.
Each packet contains information about where it is coming from, what frequency it is using, and where it is going. Packets also contain information on how the data was compressed, the order in which the packets were transmitted, and information used to verify the effectiveness of the transmission. When the data is received it is checked for accuracy, extracted from the packet, reassembled, decompressed, and possibly filtered.
The baseband processor handles all the tasks just described. It takes care of converting data from one form to another (such as from voice to digital data), compressing it, putting it into packets, taking it out of packets, assigning identifiers and error correction information, and then reversing the entire process for data that is received. In Bluetooth, the baseband function is called the link controller.
Links. The Bluetooth link is the method of data transmission to be used. The Bluetooth standard supports two link types – synchronous connection-oriented (SCO) links, used primarily for voice communications, and asynchronous connectionless (ACL) links for packet data. Each link type supports sixteen different packet types that are used, depending on the application. Any two devices in a Bluetooth system may use either link type and may change link types during a transmission.
Link management. The link manager software runs on a microprocessor and manages the communication between Bluetooth devices. Each Bluetooth device has its own link manager, which discovers other remote link managers, and communicates with them to handle link setup, negotiate features, authenticate QoS, and to encrypt and adjust data rate on link, dynamically.
Link controller. The link controller is a supervisory function that handles all of the Bluetooth baseband functions and supports the link manager. It sends and receives data, identifies the sending device, performs authentication and ciphering functions, determines what type of frame to use on a slot-by-slot basis, directs how devices will listen for transmissions from other devices, or puts devices into various power-save modes according to Bluetooth-specified procedures. Each packet uses a single 625-�s timeslot, but can be extended to cover up to five slots. Bluetooth supports an asynchronous data channel, three synchronous voice channels at 64 kbps, or simultaneous asynchronous data and synchronous voice channels. The asynchronous channel can support an asymmetric link of 721 kbps in either direction and 57.6 kbps in the return direction, or a 432.6-kbps symmetric link.
Application software. The application software is embedded in the device that operates an application over the Bluetooth protocol stack. This software allows the PDA, mobile phone, or keyboard to do its job. All Bluetooth devices must have compatible sections in their Bluetooth stack, so that all Bluetooth devices will be able to interoperate with each other.
All Bluetooth-certified devices must have the components described above, to be in accordance with the Bluetooth standard. The standard and certification procedures guarantee global interoperability between devices.
Designing Bluetooth applications
--------------------------------------------------------------------------------
All Bluetooth designs require a transceiver and a baseband controller that meet the Bluetooth specification. An antenna and a microcontroller (MCU) to run the link control, link manager, and host controller interface (HCI) and/or logical link control and adaptation protocol (L2CAP) firmware are also needed. Alternatively, developers can choose to implement protocols up to, and including, HCI on the microcontroller, and to implement a counterpart of HCI (the HCI driver) and L2CAP on a machine that hosts the Bluetooth chip-set (such as a PC or a second microcontroller on the same or attached printed circuit board).
Quite a few choices for the Bluetooth hardware are available. Several vendors plan to offer Bluetooth baseband ICs, transceiver ICs, or both. Others are offering integrated solutions that include the baseband, radio, microcontroller, and memory. The Bluetooth SIG has a target for a fully-integrated Bluetooth solution priced at $5 or less by the year 2001. In this type of solution, developing the firmware and meeting timing constraints will be a major challenge.
Processor selection
--------------------------------------------------------------------------------
The Bluetooth baseband has rigorous timing requirements, so the chosen processor must be able to deliver sufficient throughput, consume minimal power, and be cost effective. One of the key design issues is whether to use dedicated hardware for the link controller or to implement link control in the chipset's microcontroller. The Bluetooth spec follows little endian convention, so the microcontroller should also support little endian operation. Since the microcontroller should be able to handle multibyte vectors, a 32-bit device is preferable. This is particularly true if security features are to be implemented. The MCU compiler will have to provide dense and highly-optimized object code because program space and/or timing requirements are critical.
Baseband timing constraints
--------------------------------------------------------------------------------
The granularity of the processing in the baseband layer will need to be one-half of a Bluetooth slot (312.5 �s) because some access procedures produce two packets per slot and because FHSS inquiry response packets may start at a half-slot boundary.
The transceiver is heavily restricted by Tvco and Tpower_up. Although there are procedures that the firmware can execute during Tvco and Tpower_up, it is vital that the firmware has decided what should be done with the next slot in the time duration 321.5 �s minus all the previously-described time periods (Tvco+Tpower_up+ Tuncertainty_window+Taccess_code). Thus, the link control functionality should be implemented as a finite-state machine that runs in interrupt mode, and the execution of the link control code should be synchronized with the slot boundaries.
Hardware/software partitioning
--------------------------------------------------------------------------------
Due to the rigid timing constraints on the Bluetooth baseband, designers should consider replacing some of the Bluetooth firmware blocks with dedicated hardware. This is particularly true for time-consuming and/or time-critical procedures such as LSFRs (header error correction, forward error correction [FEC], cyclical redundancy check, data whitening, and testing the bit sequence). Each packet type and each packet field requires different bit transformations (such as FEC or data whitening). By implementing these functions in the hardware, the packet type and current field can be traced during receive/transmit to quickly decide which transformations should be enabled or disabled.
Additional baseband functions which can be implemented in the hardware include low-level security functions such as cipher stream generation and authentication SAFER algorithms. Implementing these tasks in the hardware relieves the MCU of having to perform them, thereby speeding up firmware execution. It also reduces the required amount of system SRAM and Flash memory. Using an off-the-shelf RTOS that supports the multithreading and scheduling requirements of the Bluetooth specification is another option. The RTOS should be able to implement context switching and service interrupts quickly, in order to meet the Tfirmware constraints, and should also have an acceptable memory footprint – especially for a fully-integrated Bluetooth solution.
Bluetooth Radio
--------------------------------------------------------------------------------
Several members of the Bluetooth SIG are developing single-chip Bluetooth radios. The Bluetooth standard requires a receive sensitivity of -70 dBm, so any Bluetooth certified radio will have been tested to meet this standard. However, increasing the receive sensitivity gives the designer the freedom to implement designs that have a longer range than the 10 meters in the Bluetooth specification. At -80 dBm, the Bluetooth application could have a range of 100 meters, an advantage that could be extremely useful in some applications. Since the BER is largely dependent on the maximum distance between the two Bluetooth devices, a transceiver IC with a higher rating will also have a smaller BER, which allows the Bluetooth device to achieve a higher data rate.
GSM phones have a maximum output power in the range of 1 to 3W, and receive and transmit frequencies ranging from 890 to 1,990 MHz, while Bluetooth transceivers are designed to work with signals as low as 10pW. Noise from the phone's transmitter may interfere with the Bluetooth signal. A trap can be placed at the output of the transmitter to attenuate any energy radiated in the 2.4 GHz band.
In most RF systems the transmit data modulates the VCO by switching the charge pump in tri-state while the phase-locked loop (PLL) is in open-loop mode. This causes frequency drift that can result in transmission errors. Frequency drift can be controlled by using I&Q modulation in which I&Q signals are transmitted by the baseband to the RF section during the mixer stage to stabilize the frequency. This requires additional firmware in the baseband, as well as off-chip passive filters. Another approach is to use a modulation compensation circuit (MCC) that keeps the VCO frequency stable while the PLL is in closed-loop mode. This latter approach to demodulation eliminates the need for any external filters. It also allows the collocation of several time slots, increasing the effective data rate. Since closed-loop modulation is insensitive to tolerances and noise influences, it results in better performance.
All superheterodyne radios tend to receive two frequencies – the signal frequency and the image frequency. An unwanted signal at the image frequency must be suppressed to avoid interference with the desired signal. One means of doing this is to use an off-chip passive filter. The external filter will increase system size and add cost, which are drawbacks in portable applications. Another approach is to include the image rejection as part of the mixer on the transceiver. The image rejection mixer converts the frequency down to 111 MHz, a frequency that conserves power and for which many low-cost filters are available.
Power consumption
--------------------------------------------------------------------------------
Virtually all Bluetooth applications will be battery operated, making power consumption a significant consideration. Implementing some of the baseband functions in hardware allows the MCU clock to be slowed, reducing power drain. Gating the clock to the MCU and the other hardware blocks also helps to minimize power consumption. Processing power varies with time, so it is preferable to drive the MCU with a relatively high-speed clock and to gate the MCU clock when the Bluetooth subsystem is in sleep mode. Using the image rejection mixer to convert the frequency down to 111 MHz, as previously described, also conserves power.
Firmware considerations – HCI
--------------------------------------------------------------------------------
The HCI protocol structure is described quite clearly in the Bluetooth specification. However, from an implementation point of view, the boundaries between HCI, link manager (LM), and link controller (LC) are not clear from the beginning. So, these layers should be designed carefully and, if possible, developed in parallel in order to integrate the system data structures as much as possible and to avoid data and code redundancy.
The HCI packet structures (Command, Event, ACL, and SCO packets) must be wrapped with additional information relating to the transport layer above HCI that runs on top of the physical link between the Bluetooth device and its host. The dataflow infrastructure must be carefully developed because individual HCI commands do not require the same amount of processing, nor do they remain in the system memory for the same duration. For example, processing the command Read_Local_Version_Information is straightforward when compared to processing the command Create_Connection.
Firmware considerations – L2CAP
--------------------------------------------------------------------------------
L2CAP is used for protocol multiplexing above the basic Bluetooth layers, for packet segmentation and reassembly, and to convey QoS information. The system designer must first decide whether to embed L2CAP with the rest of the layers or have it running as part of the host OS. Making this decision depends on the usage model and the device that will contain the Bluetooth design. A mobile phone will have to maintain L2CAP in an embedded nonvolatile memory, while a laptop computer will not.
If L2CAP is to be embedded, the designer must take into account the amount of information the Bluetooth subsystem can hold in its receive buffers on the host side before it can fragment them into smaller chunks according to Bluetooth packet sizes. The maximum packet size that L2CAP accepts from a protocol running on top of it is 64 kbytes.
Although the Bluetooth standard specifies which transport layers a Bluetooth device can use to communicate with the host to exchange HCI packets over various physical links (UART, USB), it does not specify any of them for an embedded L2CAP over the same links. Designers will have to consider how this interface is to be realized. If L2CAP is built on the host side, there is always a problem of integrating this layer into the host's OS in a way that ensures protocol multiplexing can take place above it with minimal alterations to the host's driver stack. A host-side L2CAP also poses the problem of interfacing the lower part of the L2CAP with a host-side HCI driver or with another proprietary driver. In the first case, the stack may run slower. In the second case, more programming effort will be needed to achieve interoperability requirements.
---------------------------------------------------------------------------
Stelios Koutroubinas is managing director, vice president, and CEO of the board of directors of Atmel Hellas S.A. He holds an engineering degree and a PhD in electrical engineering from the University of Patras, Patras, Greece. He can be reached at steliosk@atmel.gr .
Burkhard Gehring is the technical project leader for Temic Semiconductor's Bluetooth radio IC group. He received the Diplom Ingenieur degree from the Technical University of Dresden, Germany. He can be reached at burkhard.gehring@temic_semi.com
Designing Cableless Devices with the Bluetooth Specification
