Machine Design

Dissecting Bluetooth

Advanced instrumentation lets developers quickly get to the bottom of knotty wireless problems.

By Keven Boyett
Tektronix Inc.
Beaverton, Oreg.

It's hard to pick up a magazine or trade journal today and not read about Bluetooth. Bluetooth wireless networking technology is expected to change the way people work, interact, and exchange information. It provides a simple, reliable means of interconnecting groups of devices such as PDAs, printers, and computers. Demand for Bluetooth products is also expected to grow dramatically in automotive, industrial, and medical areas.

Consequently, Bluetooth development is on the fast track. Design teams have the formidable challenge of implementing and qualifying both products and applications using the Bluetooth standard. A class of instruments known as Bluetooth protocol analyzers has emerged to aid in this task. Protocol analyzers monitor, capture, and interpret traffic between connected digital devices communicating over a network.

Protocol analyzers have a hardware and a software component. The hardware portion contains a Bluetooth-approved radio and baseband controller. The controller runs the Bluetooth protocol stack elements. This "air probe" interface can transmit, receive, and independently intercept Bluetooth packets sent between other Bluetooth devices.

The air probe passes packets via USB to a PC equipped with a Bluetooth protocol analysis application. This application decodes and displays the information in a variety of userselected formats.

Bluetooth protocol analyzers are themselves Bluetooth devices. One function they provide is to monitor traffic in a piconet (the term for a wireless network formed by at least two Bluetooth devices) without influencing it in any way. In this regard, analyzers can act as neutral third parties, capturing protocol failures and clearly identifying the device in the net operating incorrectly.

A designer normally has complete control over the Bluetooth device under development. Control is through various means including lowlevel commands or by modifying the software and firmware controlling the Bluetooth device.

To verify operation of a Bluetooth product being developed, it is essential to have a "known good" Bluetooth reference device to connect with. Protocol analyzers can provide this capability with Piconet-mode operation. Tools such as these are really the only way to see inside other Bluetooth devices during interoperability testing. They let designers independently monitor the interactions between the developer's device and an "unknown" third-party device.

The Bluetooth protocol stack, like all digital communications protocols, is made up of layers. The uppermost layer is the Application group that contains specific Bluetooth applications (for example, a networking application). The Application group sits atop the entire stack and is not itself a protocol, though it is often considered a part of the stack. The remaining layers of the Bluetooth protocol can be viewed as two distinct functional groups.

The Transport Protocol group includes the Radio, Baseband, LMP (Link Manager), HCI, and L2CAP (Logical Link Control and Adaptation Protocol) layers. The Middleware Protocol group includes the Bluetooth specific RFCOMM, OBEX (Object Exchange), TCS (Telephony Control protocol), and SDP (Service Discovery protocol) layers and a number of industry-standard subprotocols such as TCP/IP, PPP, and AT commands.

The Host Control Interface, or HCI, is an optional interface via RS-232, USB, or UART. It connects the Bluetooth device to a host such as a PC, implementing the Middleware protocol group. HCI can be valuable in Bluetooth development work because it permits a simple, direct dialogue with the Bluetooth device via hexadecimal messages. This is the most rudimentary form of interaction with the Transport portion of the Bluetooth stack. Bluetooth development kits typically come with an HCI terminal application.

It is possible to do basic Bluetooth interoperability testing and functional verification with just an HCI terminal. The PC that hosts the application connects to the Bluetooth device through a serial port on the development board. But this method has several limitations. First, the manual process of entering, sending, receiving, and interpreting hexadecimal messages is slow, tedious, and errorprone. Second, HCI provides no direct visibility of what is going on in the layers above and below it — denying developers exactly the information they need.

A more practical and thorough approach to interacting with the stack is to enter through the RF (Bluetooth Radio) Transport layer. This is the same path that all Bluetooth traffic will follow when the product is complete.

Bluetooth Radio and Baseband layers reflect every detail of device activity, from paging and inquiry scans to all higher-level packets exchanged between devices. Therefore the Radio Interface is a rich source of information about the real-world behavior of any Bluetooth device. An RF-based Bluetooth protocol analyzer with appropriate analysis and control applications can acquire, store, format, and display information about activities in every layer of the stack.

One way to understand the importance of a full-featured Bluetooth protocol analyzer is to examine how it's used in each phase of product development. Analyzer features are best explained in the context of four key engineering steps: hardware development, software development, integration, and quality assurance.

A trend has emerged with specialist vendors offering hardware modules to implement the lower Bluetooth elements. Other vendors design, package, and sell upper-layer software elements. Those designing Bluetooth products then concentrate on software applications that will make their product appealing, easy to use, and reliable.

A capable Bluetooth analyzer offers two ways to monitor piconet transactions: as a member of a piconet (Piconet Mode) as mentioned earlier, and independent of a monitored piconet (Independent Mode).

One of the most important features in a Bluetooth analyzer is the Independent Mode. Here, the analyzer is outside the piconet but can observe everything that goes on within it. This passive acquisition ensures that interactions with the analyzer don't affect piconet traffic. It is ideal for monitoring the exchange of data, both protocol and payload, between a newly developed Bluetooth device and other piconet participants.

To set up independent-mode operation, the analyzer must briefly talk with the piconet through one of the devices already on the net. This step lets the analyzer get an FHS (Frequency Hop Synchronization) packet from the piconet and thereby synchronize to the net's hopping sequence.

There are currently three different ways for a full-blown analyzer such as the Tektronix BPA Series to get the information needed for independent mode synchronization. Synchronization may be via Master Inquiry, Slave Inquiry, or a special feature known as Fake Connection Response (FCR).

In Piconet Mode, the Bluetooth protocol analyzer is a full and equal participant in the piconet being monitored. The instrument connects in the same way as other devices, and most full-featured analyzers can function as either master or slave. Because the analyzer itself is a Bluetooth-certified reference device, its reactions to piconet traffic quickly reveal any problems in the evolving application software. Logging captured Bluetooth traffic to an external hard disk (a feature available on some analyzers) permits detailed post-analysis of every stack layer.


Much of the troubleshooting and interoperability work in a Bluetooth project happens during hardware/software integration. It is here that protocol analyzer features such as baseband acquisition, data triggering, decryption, and packet analysis are indispensable. The stack hierarchy display speeds interpretation of acquired data.

As already explained, over-the-air acquisition provides comprehensive information about Bluetooth transactions between devices, from basic protocol interchanges to payload content. To begin a data collection session, developers specify several parameters and modes as part of acquisition setup. These parameters typically include hopping patterns, time limits for synchronization, data logging method, and so forth. During acquisition, the analyzer may store logged information in a hard disk file and may produce a live display that scrolls as new packets are captured. It is also possible to filter certain packets such as ID, NULL, POLL, and access errors before they reach the log file.

Typical display modes let the operator show the packet type, the associated index, the hop frequency, and many more parameters on the baseband page. This simplifies interpretation by eliminating (hiding) unwanted details about the packets. The packet analyzer can also display the data in all of the common radices: decimal, hexadecimal, or binary.

During software/hardware integration, it is often desirable to set a "trigger" that initiates logging only when specified conditions are met. (Of course, triggering also has plenty of uses in software development and quality assurance). Triggering can reduce the amount of information that must be analyzed to locate a problem. In addition, the occurrence of a trigger proves that a defined event has happened.

Two types of triggers are available: lowlevel and high-level. The former looks for baseband and transport layer-related events such as FHS packets, ID packets, CMP_name_req, etc. The high-level trigger monitors events in the middleware protocol group, specifically the RFCOMM and SDP (Service Discovery Protocol) layers. As a new Bluetooth product design emerges, the hardware designer must determine as early as possible that it can be "discovered" and connected. As the design progresses, it is necessary to verify its ability to receive and transmit data, and test its reaction to bad data. Typically the hardware designer's Bluetooth verification work begins with the HCI terminal.

The HCI terminal application, as supplied with a full-featured Bluetooth protocol analyzer, resides on the same PC used to send and receive data through the air interface. The HCI terminal can be used to verify and exercise various protocol layers as they are developed.

Though an HCI terminal doesn't eliminate the need for a proper Bluetooth protocol analyzer, it can be a means of talking with a Bluetooth device without employing a fully functioning protocol stack. Typical functions include providing an ability to enter commands one-at-a-time in mnemonic (text) form or as hexadecimal data.

Other HCI terminal features speed up the process of creating and sending data packets to the Bluetooth device. Tools in a Data Wizard define data package sizes and content. The wizard can create packages of fixed or random sizes, fill the packages with random or sequential data, set up a single-packet transmission or a continuous loop, and more.

Some HCI terminal applications include a feature known as "HCI Scripting." The feature uses simple text files as a means of storing and executing multiple HCI commands. With HCI Scripts, a single file can contain all necessary setup and transmission functions, carried out according to a set of basic flow-control commands such as jumps and conditional jumps.

HCI scripting lets developers run the same instruction series repeatedly. With an HCI script it is possible, for example, to create a short loop that connects and sends some data to the Bluetooth device. If a problem is detected, you can repeat the test to determine whether there is an intermittency or a possible design flaw.

One of the most effective ways to exercise a system is to feed it a series of known errors. How does the device react? Does it correct the errors and go on with its job? Or does it lock up and refuse to respond? Do different errors have different consequences?

Some Bluetooth protocol analyzers include error generation tools that can offer an array of challenges for the device-under-test. Some potential uses of these tools include cross-checking error correcting algorithms such as FEC, HEC, and CRC; generating errors for baseband packets such as DM1, DM3, POLL, etc.; and introducing individual bit errors into the header, payload, or a custom-defined bit position.

In quality assurance (QA) work, the challenge is to unmask any remaining design problems that might affect the Bluetooth device's prospects for certification. QA tasks use almost every feature of the Bluetooth protocol analyzer.

The most basic assumption when using a Bluetooth protocol analyzer for QA is that the analyzer itself is fully Bluetooth-certified and complies with the latest Bluetooth SIG specifications and recommendations.

The Bluetooth qualification process involves a hierarchy of administrative and technical entities. These include the Bluetooth Qualification Review Board, which sets the policies published in the Program Reference Document; the Bluetooth Qualification Administrator, which administers the program for the above organization; the Bluetooth Qualification Body, individuals authorized to list qualified products; and the Bluetooth Qualification Test Facility, which meets published technical requirements to conduct Category "A" test cases (basically RF testing).

Eventually, most new Bluetooth product designs will have to go through qualification at the Test Facility. Alternatively, the designs may be tested in-house and the resulting documentation sent to a Qualification Body for verification.

The goal during QA is to make sure the device will get through the certification steps successfully on the first try.

Bluetooth protocol analysis solutions vary in their approach to acquiring, storing, and displaying piconet data. Some self-contained analyzers can store captured traffic only up to the limited capacity of their on-board memory. In terms of real-world clock time, this equates to less than an hour's worth of information. Often this is adequate, but intermittent errors have a way of showing up unpredictably, occurring once in several hours or even days.

An ability to log directly to disk solves this problem. Some Bluetooth analyzers, already resident as applications in a PC, can use the PCs hard disk to store Bluetooth traffic as it accumulates. Logging to the hard disk dramatically extends the amount of time that can be acquired. With local hard disk storage reaching 40 Gbytes, 60 Gbytes, and more, the system can capture hours or days of transactions.

Even more time can be stored if the logging process uses data filtering. In particular, preacquisition filtering on the Baseband Access Error, ID, NULL, and POLL packets greatly reduces the amount of data that gets stored on the disk.

Not all Bluetooth devices use encrypted transmissions, but those that do will require complementary decryption capabilities in the protocol analyzer. Here again, the protocol analyzer should provide easy-to-use setup tools that guide the user through the necessary steps.

In the more advanced Bluetooth protocol analyzers available today, the application's packet analyzer can display acquired traffic in either encrypted or decrypted form. Logged files are made up of both types. The packet analyzer can actually decrypt and display Bluetooth transactions in real time.

Modern Bluetooth protocol analyzers such as the Tektronix BPA 100 access the Bluetooth protocol stack via an RF interface device as depicted here. The RF interface lets the instrument interact with a Bluetooth network as a master or slave device and monitor traffic to detect errors. It can also insert errors to test devices on the net for robustness. Alternatively, basic Bluetooth interoperability testing and verification can take place with an HCI terminal application. The PC hosting the protocol analyzer connects to the Bluetooth device through a serial port on the development board. Full-featured devices such as the BPA 100 can also log data directly to disk to capture long periods of traffic to more easily detect transient problems. Captured packets from the log file are displayed in a spreadsheet-style representation with each stack layer having its own display page.

All Bluetooth devices must go through a qualification process similar to that depicted here. Developers work from documents provided by a Bluetooth Qualification Administrator. Category A devices (basically, those employing RF transceivers) must be tested and certified for acceptable operation by a Bluetooth Qualification Test Facility. Developers can do their own testing for Category B and C equipment (such as Bluetooth development gear or Bluetooth components not involved in RF transmission) and submit documentation for review by a Bluetooth Qualification Body. Approved Bluetooth products then get put on the Qualified product list.


Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.