Bluetooth Components

Any Bluetooth solution consists of four major components: antenna/RF component, Bluetooth hardware and firmware (baseband and Link Controller), Bluetooth software protocol stack, and the application itself. Each of these components is a product in itself, and companies exist that have entire business models based around solving only one of these four areas.

Antenna/RF

The antenna and RF design portion is interesting in that it requires a unique solution for each device. When purchasing a Bluetooth module for Ericsson, for instance, the antenna is not provided. Bluetooth silicon manufacturers cannot effectively provide an antenna with the hardware. Even single chip solutions require specialized antenna design, depending on the device. Antenna design requires specialized skills to ensure that the Bluetooth radio will operate within its specification.

Bluetooth Radio and Baseband

The Bluetooth radio is the hardware transceiver unit that implements the Bluetooth radio specification. The purpose of the specification is to provide compatibility between Bluetooth devices that operate in the 2.4 GHz ISM band, and to define the quality of the system. Further information on the Bluetooth radio specifications may be found in the Bluetooth core specification document.

 

The Bluetooth baseband consists mainly of a Link Controller (LC) that carries out baseband protocols and low-layer link routines. Protocols defined within the scope of the baseband specification include (among others) physical channels and links, data packet definitions, error correction and detection, logical channels, channel control, and hop selection. For more information about the Bluetooth baseband specification, see the Bluetooth core specification document.

 

An example implementation of the Bluetooth radio and baseband is the Ericsson Bluetooth Module. In addition to the hardware, this module contains the firmware that implements the baseband specifications. As you'd expect, there are a number of other manufacturers developing Bluetooth modules too.

Bluetooth Software Protocol Stack

The Bluetooth software protocol stack can be thought of as driver code. This code allows the application software to send and receive information from the Bluetooth module. Several implementations of this currently exist, and vary from GNU licensed code to commercial products targeted at various operating systems.

 

Major components of the protocol stack are the Link Manager (LM), the Logical Link Control and Adaptation Protocol (L2CAP), the Host Control Interface (HCI), the Service Discovery Protocol (SDP), Audio/Telephony Control, RFCOMM, Human Interface Device (HID), TCP/IP, and other high level protocols. These are all described in the subsequent sections.

 

Link Manager (LM)

The LM manages link setup, link configuration, and link packet control and transfer. The LM also manages link security during the initialization of the connection and throughout its existence (where applicable). The LM handles synchronous and asynchronous packet communication within the piconet, as well as the timing parameters used during communication. The LM also handles master/slave role switching between devices. Sniff, hold, and park mode behavior is controlled by the LM too.

 

'Sniff', 'hold', and 'park' are power saving modes in which a Bluetooth device may operate. They allow for varying levels of participation and communication within a piconet. The use of each of these modes is broadly determined by the type of device, its function, and overall need for immediate service.

Logical Link Control and Adaptation Protocol (L2CAP)

The services provided by L2CAP include protocol multiplexing, segmentation and reassembly, and quality of service. The L2CAP protocol architecture is connection-oriented, with connections labeled by a channel identifier. Each channel is assumed to be a full-duplex connection, with a Quality-of-Service (QoS) flow specification being applied to each channel direction.

 

Protocol multiplexing enables an application to use several higher-layer protocols simultaneously - RFCOMM, TCP/IP, etc. This service also passes packets used by the higher layer protocols to the appropriate handlers. Protocol identifiers have a one-to-many mapping with channel identifiers. For example, a master device may provide a TCP/IP service and have more than one slave unit using that service.

 

Segmentation and reassembly is a service by which packets from higher layer protocols are segmented into appropriate-sized Bluetooth packets and reassembled again after transmission. This service is transparent to the higher layer protocols.

 

The L2CAP also negotiates and enforces Quality Of Service (QoS) contracts, which are based on the type of service provided, with a 'best effort' contract used by default. QoS regulates the token size (bytes), the rate and peak bandwidth (bytes/sec), and other key elements to ensure a robust connection.

Host Control Interface (HCI)

The HCI provides a standard interface to the Bluetooth module and link manager services that is independent from the host hardware implementation. This layer provides transparency between the host controller and the Bluetooth hardware. There is an addendum to the HCI specification for each physical bus (USB, PCI, RS232, etc.) that further defines the interface functions based on which physical bus is used.

Service Discovery Protocol (SDP)

The SDP is the layer that exposes high-level services such as LAN access or printer services to users and other applications. This layer also provides information to implement a plug-and-play solution, such as a laptop computer using a printer. This layer could be implemented using a higher SDP such as Java JINI.

Audio and Telephony Control

These two protocols are linked, because in the Bluetooth specification, telephony Control contains Call Control and Audio Control. This protocol defines the interface needed to connect and disconnect a call, including signaling the devices desired to participate in the connection. Telephony audio links are established with synchronous links, and therefore do not go through the same L2CAP-to-LM path that asynchronous links go through. Audio links may be thought of as direct baseband to baseband links.

RFCOMM

RFCOMM provides a protocol to emulate cables with Bluetooth, enabling compatibility with a large base of applications that currently use the serial port as their main communication bus. RFCOMM conveys all of the RS232 control signals, and supports remote port configuration. RFCOMM borrows from the IrComm in the IrDA protocol stack.

Human Interface Device (HID)

HID is a protocol that enables the concept of a cordless computer. HID describes keyboards, mice and joysticks. This layer would enable plug and play support for such devices when used with a PC.

TCP/IP

TCP/IP over Bluetooth presents a powerful way to link devices. TCP/IP is a network and transport layer that's widely supported by applications and APIs across almost every operating system. The problems with using TCP/IP over Bluetooth include, among others, handling ad hoc networking, DNS name resolution, and broadcasting. Better profiles for networking with Bluetooth are currently being developed by the SIG.

Other Protocols

Other protocols include things such as WAP, object exchange, still image, IR, etc. These protocols would be used by an application that sends its native packets through Bluetooth, just as it would use any other transport layer. All of these possibilities exist within the scope of Bluetooth. All that is missing is the development of the applications.