Bluetooth wireless local networking is a phenomenon waiting to happen. The arrival of a new generation of Bluetooth-capable test instruments removes one of the big barriers to Bluetooth’s emergence and will play a part in opening the floodgates of demand for exciting, new wireless products. Some market-watchers foresee a trend line that will put more than 1 billion Bluetooth-enabled devices in the hands of users within just a few years.
An exacting certification or qualification process, administered by the Bluetooth Special Interest Group (SIG), is emerging. Ultimately, every new Bluetooth product must be qualified before it can come to market. The process is designed to ensure interoperability among the many upcoming Bluetooth-enabled products.
Qualification is a blessing because it provides consistent specifications and guidelines to design and test to. But it also is a challenge because the qualification process requires extra administration and planning. Fortunately, the playing field is fairly level—every Bluetooth product developer must live by these same rules.
Do qualification needs affect your test-equipment choices? Yes, and so do price and performance. But because Bluetooth is standing on the threshold of massive acceptance and growth, it is a technology that will give the richest rewards to those who arrive earliest to market.
Perhaps the biggest issue for a Bluetooth development tool is not whether it can do the job—many can—but whether it can speed your new products through design, verification, and qualification to a waiting market. With this concern in mind, let’s take a look at the two major hurdles that confront every Bluetooth design project:
- Making the design work. Common sense, you say? Perhaps, but in Bluetooth development, issues such as interoperability and compliance ride on top of the usual questions of signal management, interconnection, and code efficiency. Every design change and workaround must be evaluated for its potential effect on multiple protocol stack layers.
- Achieving qualification. While it ensures consistent performance and benefits for Bluetooth vendors and consumers alike, Bluetooth qualification is made up of rigorous tests, and the process takes time.
Many tests must be performed by a recognized Bluetooth Qualification Test Facility (BQTF). Getting access to a BQTF, at least at the beginning, will become a “take a number and wait your turn” regimen. Failure to achieve qualification on the first try costs precious time.
Clearly, these two hurdles have compliance as their common denominator. With compliance as the overarching requirement, many Bluetooth design teams are spending extra time on design verification and compliance checks.
Climbing Onto the Protocol Stack
The Bluetooth protocol analyzer is the solution for many of these verification tests and compliance checks. Itself a rather new technology, the protocol analyzer sends data to and receives it from Bluetooth piconets and provides analysis tools for evaluating the data.
Today’s full-featured Bluetooth protocol analyzers comply with the latest specification definitions; in fact, the analyzer itself must pass rigorous Bluetooth qualification tests. The current Bluetooth SIG specification level is V1.1, which encompasses radio, baseband, and protocol stack standards.
Bluetooth Basics
A connection between two or more Bluetooth-enabled devices creates an ad hoc local network known as a piconet. Devices can establish connections with one another without user intervention; the one that initiates the connection is the master while all other participants (up to seven) are slaves. The master controls all traffic on the piconet. Every piconet is distinguished by a unique frequency-hopping sequence defined by the master.
The Bluetooth protocol stack has many levels, as shown in Figure 1. Below the host control interface (HCI) boundary is the purely Bluetooth functionality, while above it, the middleware protocol group takes advantage of industry-accepted technologies where possible. These include the point-to-point protocol (PPP) and the TCP/IP communications protocol, the object exchange (OBEX) file transfer protocol, and others. Atop the whole stack, the applications layer supplies definitions for Bluetooth implementations in laptop computers, PDAs, and other platforms.
A Closer Look at Protocol Analysis Tools and Techniques
What can the protocol analyzer do to help developers sort out interactions among stack layers, verify functional performance, and keep track of compliance and interoperability issues?
The protocol analyzer is essential for basic Bluetooth design and debug and precompliance testing prior to qualification procedures at a BQTF. The most advanced protocol analyzers are those that split the acquisition/analysis workload along the lines of the stack itself.
A radio/baseband unit interacts with PC-based control software via the USB port. The external transmitter/receiver supplies optimized RF and baseband functionality and acts like a conventional Bluetooth device. The PC provides analysis tools and storage capacity limited only by the size of its hard disk drive.
Until recently, it was necessary to purchase a dedicated development kit to implement low-level Bluetooth commands during a project’s earliest stages. Technically not a test or measurement instrument, the kit’s functions were limited. The current generation of protocol analyzers combines development-kit functions, such as an HCI terminal window, into a full-featured solution that also addresses higher levels on the protocol stack.
There are two approaches to capturing the activity on the many levels of the Bluetooth stack. Some analyzers capture each level individually and evaluate the results. This approach provides results that are isolated into layers just as the stack is. These must be manually collated to see the interactions between the stack layers.
A more efficient tool is the protocol analyzer that acquires and logs Bluetooth traffic at the baseband level. This supports tests over a wide range of piconet configurations without impacting the performance of the system under test.
Using the protocol analyzer, baseband packets can be logged, decoded, and displayed. Some protocol analyzers can derive higher-level protocol layers such as link management protocol (LMP), logical link controller and adaptation protocol (L2CAP), serial cable emulation protocol (RFCOMM), and service discovery protocol (SDP) from the baseband data.
A protocol analyzer that works from the baseband packet level data will eliminate unnecessary repetitions of the test procedure to acquire each stack layer separately and promote a big-picture understanding of stack behavior. Some models allow you to leaf through the stack layers as though they were in a file cabinet. The tabs directly below the toolbar provide easy access to the various stack levels.
Analyzer Can Be a Piconet Participant Or a Bystander
Often it is useful to observe piconet transactions in a completely nonintrusive way. The analyzer’s independent mode allows it to passively collect data from a piconet. While true Bluetooth devices must participate in a piconet as either master or slave, only an analyzer is designed to just listen. Sometimes termed fake connection response, the instrument performs some initial housekeeping steps to synchronize to the piconet without actually becoming a participant, then steps aside to monitor the piconet without introducing any artifacts.
Alternatively, the analyzer can actively join the piconet, participating as a master or a slave. Here, the analyzer acts like a reference device, assuming it is Bluetooth-qualified to current specifications. As such, its response to the transmissions of other piconet participants can be used to evaluate their interoperability. Similarly, the analyzer’s transmissions are a source of known-good data to send over the piconet.
Equally important, the analyzer also can be used to deliver flawed data for stress tests. Errors fall into two categories: header and payload errors. By inserting deliberate and well-understood errors into the data stream, it is possible to gauge the network’s reaction. Does the piconet crash or stumble, or does it tolerate the errant packets? These questions must be answered when bringing up the baseband/radio portion of a new Bluetooth design.
Some analyzers include error-generation tools to help with the task. Under program control, they can insert header or payload errors of various types. To further simplify the engineer’s work, they can force errors only when specific conditions are met. These include hop frequency, header type, payload length, and more. Conditional errors put well-defined limits on the measurement, simplifying the analysis of results.
Many measurement tools rely on conditional triggering to help engineers manage the kind and amount of data they acquire. The Bluetooth protocol analyzer is no exception. By triggering on specific commands, sequences, or even patterns of data, it is easy to localize problems. At the same time, it minimizes the amount of unwanted data that is stored, although this may not be a concern if the analyzer stores its data on a connected PC’s hard disk.
Further conditioning of the acquired data can be accomplished with filtering. This is different from triggering because it decides what information to accept and display after the instrument receives a trigger. Here too, the result is a reduction in the amount of data that has to be evaluated.
For example, the Bluetooth NULL and POLL packets are used to keep the piconet synchronized while it is idle and usually are not of interest when looking for data errors in the main transmission. Filtering makes it possible to ignore the NULL and POLL activity. Figure 2 shows a filtering setup screen with NULL and POLL acquisition disabled. Here too, tabs provide quick access to the stack layers.
Proceeding With the Acquisition
With triggering, filtering, and synchronization properly set up, the analyzer can proceed with its acquisition. It displays packet payload, status information such as access errors, and estimated clock and hop frequencies. It also isolates, decodes, and displays the content of ID, frequency hopping synchronization (FHS), NULL, and many other packet types.
A useful tool is a free-running display in which the instrument display updates continuously as new packets are received and logged. As the display evolves, it is easy to spot changes and track messaging in higher-level protocols. Of course, the acquisition must be stopped to allow detailed scrutiny of the logged data.
Like many design tasks, protocol stack development can be a repetitive process of trial and error as the understanding of stack interactions grows. Some protocol analyzers have productivity-enhancing features such as scripts or macros that can combine groups of low-level commands to simplify repetitive tasks.
Qualification
The Bluetooth protocol analyzer complements the required testing done at a BQTF. The BQTF uses a dedicated Bluetooth test system that runs the full spectrum of RF and protocol testing required by the Bluetooth SIG. The protocol analyzer’s log files, however, often can be used by the device designer as proof of compliance to satisfy remaining Bluetooth qualification test requirements.
The protocol analyzer’s strength is its capability to provide a useful preview of a Bluetooth product’s performance in the final qualification tests. Here, features such as error injection for stress testing, passive mode monitoring for compliance checks, and baseband-level packet capture support a comprehensive understanding of the emerging product’s behavior on a piconet.
Conclusion
Bluetooth technology still is in its infancy. Specifications are evolving; applications and products are emerging. Test, measurement, and monitoring technology is keeping pace in the form of the modern Bluetooth protocol analyzer. This essential tool will enable the development of successful generations of Bluetooth-enabled products.
About the Author
Keven Boyett is marketing manager for the Bus Analyzer Business at Tektronix. He has more than 20 years of experience in engineering, marketing, and executive roles, including network consulting plus eight years of wireless Internet PDA software development and sales. Mr. Boyett received a B.S.E.E. from Purdue University. Tektronix, 13975 SW Karl Braun Dr., M/S 39-116, Beaverton, OR 97077, 503-627-4031, e-mail: [email protected].
Return to EE Home Page
Published by EE-Evaluation Engineering
All contents © 2001 Nelson Publishing Inc.
No reprint, distribution, or reuse in any medium is permitted
without the express written consent of the publisher.
August 2001