Implementing Bluetooth in an Embedded Environment

Bluetooth is essentially a detailed specification for short-range wireless communications using the unlicensed industry, scientific, and medical (ISM) 2.4 GHz radio band. Although Bluetooth technology is fundamentally a cable replacement system it provides a universal bridge to existing data networks and an ad hoc connection mechanism for a variety of devices in various configurations. The Bluetooth specifications have been devised with the understanding that removing the restraint of a cable and implementing a wireless link is only beneficial if the wireless technology is as economic and robust as the cable it replaces, or that the wireless link offers additional advantages. This article presents an outline of the Bluetooth protocols and testing procedures.

Figure 1:  Bluetooth topology showing how a piconet is created

Bluetooth devices that are within range of each other—a primary 0 dB link gives 10m range and 20 dB link gives 30m range—can establish connections on an ad-hoc basis and can form, disconnect, and re-form without user intervention. Two or more Bluetooth devices that establish a connection, and share a channel, form a small wireless network known as a piconet (Figure 1).

The raw data rate is 1 Mbit/s with voice channels supporting 64 kbit/s and an asymmetric link of 721 kbit/s in either direction, while permitting 57.6 kbit/s in the return direction or a 432.6 kbit/s symmetric link. In a piconet, one Bluetooth device acts as a master, controlling all traffic in the piconet, while all other devices act as slaves. The master is defined as the device that initiates the connection procedure to establish a piconet. Only one master exists per piconet. The smallest piconet consists of just two devices (point-to-point)—one master and one slave. Up to seven slaves can be active in a piconet. Devices can be placed in a Park mode and a master can support up to 255 such devices (point-to-multipoint). A new device can use the User Service Discovery to determine what network services are available from the various connected devices.

Figure 2:  A Bluetooth scatternet comprises a group of piconets that have overlapping coverage

A group of piconets with overlapping areas of coverage is called a scatternet (Figure 2). Each piconet is identified by a different frequency-hopping sequence. A Bluetooth device may participate in different piconets provided it is only active in one piconet at a time. A device can act as a slave in different piconets, but as a master in only a single piconet. For inter-piconet communication, a device selects the proper master identity and clock offset in order to synchronize with the channel of the desired piconet.

The radio deals with sending and receiving data over the air. The Bluetooth radio design was driven primarily by low manufacturing complexity, associated low-cost, and fast time to market. With a $5 end-user target goal for a combined radio/baseband chip, the design had to be kept simple. Since neither new data-exchange protocols nor data-processing algorithms were developed for the Bluetooth radio, this was the first part of the specification completed. The original Bluetooth specification did not specify a standard set of interfaces for the data and control information to and from the radio, in the belief that developers would want the freedom to integrate the radio component in the most cost-effective and power-efficient manner possible. There is now a growing movement towards developing a standard interface.

In the implementation of a Bluetooth module, hardware implements the radio and link controller, whereas firmware contains the link manager. The radio and the link controller along with the baseband functions were the first parts of the Bluetooth specification to mature. At present, the radio is generally a separate chip from the Link Controller/Link Manager, although the goal of most manufacturers is to provide a single-chip, low-cost solution, for space- and power-conscious designs. Other approaches make use of the host processor and firmware to implement the baseband, keeping the radio separate. Regardless of the hardware implementation, the Bluetooth protocol stack and hierarchy Figure 3 are maintained.

When a link manager in a device initiates a Link Management Protocol - Protocol Data Unit (LMP_PDU) transaction with the link manager in another device, the receiving link manager will respond with the next LMP_PDU in the transaction sequence. Alternately, the receiving link manager responds with a LMP_accepted or LMP_not_accepted PDU. If a LMP_not_accepted PDU is sent, the reason for not accepting the transaction is provided.

1. Universal Serial Bus (USB)
2. Standard serial link RS-232
3. Universal Asynchronous Receiver/Transmitter (UART).

The specification defines over 100 command, event, and data Host Controller Interface Protocol Data Units (HCI_PDUs). HCI is used for design implementations where the host is connected to a separate Bluetooth module. Examples are Bluetooth backpacks for Personal Digital Assistants (PDAs) or cell phones. Manufacturers who wish to tightly integrate Bluetooth directly into their designs may eliminate the HCI. However, manufacturers must still provide a Test Control Interface (TCI) for compliance testing. Current development kits use HCI as a command and control interface, and execute HCI commands from a PC.

1. Connection Oriented (device-to-device)
2. Connectionless (broadcast).

L2CAP must support protocol multiplexing, since the Baseband does not support a type field to identify the higher layer protocol being multiplexed above it. L2CAP must be able to route received packets to the appropriate protocol above it—RFCOMM, SDP, and TCS. L2CAP permits higher level protocols to transmit and receive data packets up to 64 Kbytes without any knowledge of the lower layers. Bluetooth Baseband packets are limited in size to a Maximum Transmission Unit (MTU) of 341 bytes. Large L2CAP packets must be segmented into multiple smaller baseband packets prior to transmission.

A connectionless data packet is sent to all members of a group "in best effort". Since there is no QoS, the transmission is inherently unreliable. Because there is no channel connection set-up, the packet must carry protocol information in the Protocol Service Multiplexer (PSM) field. The PSM has two bytes—one is an opcode that indicates the protocol based on SIG assignments while the other is dynamically assigned and is used in conjunction with Service Discovery Protocol (SDP).

• Modem status—RTS/CTS, DSR/DTR, DCD, ring
• Remote line status—Break, overrun, parity check
• Remote port settings—Baud rate, parity, number of data bits, and others
• Parameter negotiation—Frame size.

A server can be any Bluetooth device offering a service that can be used by another Bluetooth device, and a client can be any device wanting to use a service. Each Service Discovery Protocol (SDP) server maintains a database of information that a client needs to access a service. To use SDP, an L2CAP channel must be established between the SDP client and server. The services provided by Bluetooth have Universally Unique Identifiers (UUIDs) assigned by the standard. Developers can create their own UUIDs and a methodology exists to ensure no UUID duplication.

Figure 4:  A detailed qualification process ensures that Bluetooth products comply with the Bluetooth specification

The qualification process ensures that Bluetooth products comply with the Bluetooth Specification, thereby enabling interoperability between devices (Figure 4). Bluetooth qualification is a necessary precondition of the intellectual property license for Bluetooth wireless technology. Qualification is also necessary to apply a Bluetooth trademark to a product (subject to a separate trademark agreement). Qualification is not type approval—manufacturers of Bluetooth products must also go through the normal procedures of regulatory-type approval in each country or region where they want to sell the product.

Figure 5:  A group of Bluetooth qualification bodies oversees proper test and validation of Bluetooth products

Several cooperative qualification bodies oversee Bluetooth test and validation (Figure 5):

• Bluetooth Qualification Review Board (BQRB)—consists of delegates from each Bluetooth promoter whose main task is making policy
  
  
• Bluetooth Qualification Administrator (BQA)—responsible for administering the Bluetooth Qualification Program on behalf of the BQRB
  
  
• Bluetooth Qualification Test Facility (BQTF)—any test facility accredited by the BQRB to test Bluetooth products
  
  
• Bluetooth Qualification Body (BQB)—a person authorized by the BQRB to provide services to an adopter seeking Bluetooth product qualification. The BOB is responsible for checking declarations and documents against requirements, reviewing product test reports, and listing products to the official database of Bluetooth qualified products
  
  
• Bluetooth Technical Advisory Board (BTAB)—a forum consisting of all BQBs and BQTFs, responsible for advising the BQRB on technical matters relating to test requirements, test cases, test specifications, and test equipment.

The Bluetooth Qualification Review Board has identified four test categories, A to D:

• Category A Bluetooth products can only be tested on validated and commercially available qualification test equipment by a BQTF
  
  
• The Member or a Bluetooth Qualification Test Facility can test category B and C Bluetooth products using standard test equipment
  
  
• Category D is a preliminary test case with no official qualification value. The purpose of this status is to inform any manufacturer about an upcoming test case. Until validated protocol-conformance test systems become available, Blue Units are used to establish confidence in the lower layer protocols.

Figure 6:  Mandatory Bluetooth testing comprises a rigid set of testing, documentation, and qualification tasks

Figure 6 shows the procedural flow involved with qualifying a Bluetooth product. The Bluetooth protocol tester and instruments, such as spectrum analyzers, are complex tools typically used by Bluetooth Qualification Test Facilities. However, the Bluetooth protocol analyzers are on the order of a tenth of the cost of a Bluetooth protocol tester. A protocol analyzer is usually used for device development, debug, and pre-qualification testing. A particular facility of a Bluetooth protocol analyzer is in the debug of hardware/software integration where some tools specifically generate predetermined errors for the evaluation and debug of the higher level protocols (Figure 7).

Replacing a cable with a Bluetooth wireless link brings its own unique challenges. In particular Bluetooth systems have demanding debug and test requirements. A significant part of the development process is in the implementation of the Bluetooth protocol stack, where the integration of hardware and software requires careful debug and test. Moreover, the end device must be thoroughly tested for correct operation within a wide range of piconet/scatternet configurations and interoperability with other devices. Finally the system must be tested to ensure that it meets the local regulatory radio tests for the countries in which the product will be sold.

For further information, two good books on Bluetooth are:

• Bluetooth Revealed
  Brent A. Miller & Chatschik Bisdikian
  Prentice Hall, ISBN 0-13-090294-2
  
  
• Bluetooth—Connect without Wires
  Jennifer Bray & Charles F. Sturman
  Prentice Hall, ISBN 0-13-0895-40-6

About the Author Dr. Geoff Lawday is a principal lecturer in computing at Buckinghamshire Chilterns University College, England. He has worked as an electronic engineer and in-circuit emulator applications engineer. He currently holds the Tektronix Readership in Measurement at BCUC and teaches embedded systems and computer networks. Lawday has a BSc in physics and an MSc in computer engineering from Surrey University. He also holds a PhD in time-frequency signal analysis from Brunel University. He can be reached at geoff.lawday@bcuc.ac.uk. A version of this paper was presented at the European Embedded Systems Conference in October of 2001.