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.
The Bluetooth Special Interest Group
(SIG)
The Bluetooth Special Interest Group (SIG), comprised of leaders
in the computing, telecommunications and network industries, has
specified Bluetooth's protocols and application profiles. The Group
is driving the development of the technology and bringing it to
market. The Bluetooth SIG includes promoter companies 3Com,
Ericsson, IBM, Intel, Lucent, Microsoft, Motorola, Nokia, and
Toshiba, along with over 2000 Adopter/Associate member
companies.
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.
Bluetooth Radio and Link Controller
A radio-hopping sequence is used to combat interference and
fading. The piconet master determines the hopping sequence and the
timing is determined by the master unit's system clock. As part of
the connection process, a slave will receive timing information
from the master, including its current clock and hopping sequence.
This procedure ensures that all Bluetooth devices in a piconet are
synchronized.
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.
The Link Controller
The Link controller is the hardware controller for the radio and
host to the Baseband protocol functions. This controller is
responsible for determining what data to transmit and when, what
data to wait for and when, and which carrier frequency to transmit
and what power to use. Baseband functions include piconet and
device control functions, modes of operation, and medium access
functions. Control functions include connection creation,
frequency-hopping sequence selection, and timing. Power control and
secure operation are examples of operation modes. Medium access
functions include functions such as polling, packet types, packet
processing, and link types such as Asynchronous Connectionless and
Synchronous Connection-Oriented (ACL and SCO). These processes,
along with others, execute the Baseband protocol. All higher level
packets are broken down into Baseband Packet Data Units for
efficient transmission. The channel timing of Bluetooth is not
sufficient to allow the long packet lengths such as those allowed
by some of the higher level protocols.
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.
The Host Controller Interface (HCI)
Over 300 pages in the Bluetooth core specification are devoted
to the HCI, with three serial transport protocols specified:
- Universal Serial Bus (USB)
- Standard serial link RS-232
- 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.
The Logical Link Control and Adaptation
Protocol (L2CAP)
L2CAP provides for higher-level protocol multiplexing, packet
Segmentation and Re-assembly (SAR), and conveys Quality of Service
(QoS) information between applications. L2CAP also creates channels
between applications in two different devices with identified
addresses or endpoints, called Channel IDentifiers (CIDs). Note
that the Link Manager is responsible for setting up and maintaining
physical links between devices and the L2CAP layer creates the
channel connection between applications using the Asynchronous
ConnectionLess (ACL) link. While the Baseband defines two link
types, ACL and SCO, L2CAP is defined for ACL only. Two types of
CIDs are defined as:
- Connection Oriented (device-to-device)
- 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).
Serial Interfaces
Serial interfaces are ubiquitous in computing and
telecommunications where devices such as notebook computers, PDAs,
digital cameras, and infrared communications systems normally have
or make use of serial communication ports. These devices are seen
as typical embedded Bluetooth applications. RFCOMM, the standard
RS-232-C serial protocol, provides a common protocol format to
consolidate these many serial communication formats into one single
format before passing onto L2CAP. Most of the wired serial
protocols require a specially configured cable, such as an RS-232-C
lead, connected to a serial communication COMM port. Since RFCOMM
is specifically for serial links, it is often referred to as the
Cable Replacement Protocol. One of the key benefits of RFCOMM is
that software developers can make use of the many legacy software
applications that make calls to serial ports with little or no
modifications. The RFCOMM layer provides a virtual COM port to
these serial applications with framing, multiplexing, and the
normal serial characteristics such as:
- 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.
Service Discovery
The emergence of information appliances and the requirement for
self-discovery of available services without user intervention has
led to the development of this crucial protocol. This contrasts
with wired services, such as a local area network, where a network
administrator manages the network resources and services that are
available to the users. Service discovery is a process that allows
Bluetooth clients to locate, gather information about, and make use
of services on other Bluetooth enabled servers (devices) in a
piconet.
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.
The Bluetooth Telephony Control Protocol
Specification (TCS)
The Bluetooth Telephony Control protocol Specification (TCS)
defines how telephone calls should be sent across a Bluetooth link.
It gives guidelines for the signaling needed to set up both
point-to-point, and point-to-multipoint calls. It also provides a
way to send DTMF tones across a Bluetooth link. TCS is adapted from
ITU-T Recommendation Q.931. Note that the acronym used for
telephony control does not fit in with the convention used in the
rest of the Bluetooth stack. By following the rest of the stack
naming conventions, this should be called TCP; however it was
decided that this would conflict with the Internet Transport
Control Protocol (TCP).
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. |
){kind=link}
){kind=link}