Bluetooth
Architecture
Bluetooth
is both a hardware-based radio system and a software stack that specifies the
linkages between layers. This supports flexibility in implementation across
different devices and platforms. It also provides robust guidelines for maximum
interoperability and compatibility.
In
this section, you’ll learn about:
·
The Bluetooth protocol stack.
The protocol stack is the core of the Bluetooth specification that defines how
the technology works.
·
The Bluetooth profiles.
The profiles define how to use Bluetooth technology to accomplish specific
tasks.
The Bluetooth Protocol
Stack:
The heart of the Bluetooth
specification is the Bluetooth protocol stack. By providing well-defined layers
of functionality, the Bluetooth specification ensures interoperability of
Bluetooth devices and encourages adoption of Bluetooth technology. As you can
see in Figure 1-1, these layers range from the low-level radio link to the
profiles.
Figure
1-1 The Bluetooth protocol
stack
Lower
Layers:
At
the base of the Bluetooth protocol stack is the radio layer. The
radio module in a Bluetooth device is responsible for the modulation and
demodulation of data into RF signals for transmission in the air. The radio
layer describes the physical characteristics a Bluetooth device’s
receiver-transmitter component must have. These include modulation
characteristics, radio frequency tolerance, and sensitivity level.
Above
the radio layer is the baseband and link controller
layer. The Bluetooth specification doesn’t establish a clear distinction
between the responsibilities of the baseband and those of the link controller.
The best way to think about it is that the baseband portion of the layer is
responsible for properly formatting data for transmission to and from the radio
layer. In addition, it handles the synchronization of links. The link
controller portion of this layer is responsible for carrying out the link manager’s
commands and establishing and maintaining the link stipulated by the link
manager.
The link
manager itself translates the host controller interface (HCI) commands
it receives into baseband-level operations. It is responsible for establishing
and configuring links and managing power-change requests, among other tasks. You’ve
noticed links mentioned numerous times in the preceding paragraphs. The
Bluetooth specification defines two types of links between Bluetooth devices:
·
Synchronous,
Connection-Oriented (SCO), for
isochronous and voice communication using, for example, headsets
·
Asynchronous,
Connectionless (ACL), for data communication, such as
the exchange of vCards
Each
link type is associated with a specific packet type. A SCO link provides reserved
channel bandwidth for communication between a master and a slave, and supports
regular, periodic exchange of data with no retransmission of SCO packets.
An
ACL link exists between a master and a slave the moment a connection is
established. The data packets Bluetooth uses for ACL links all have 142 bits of
encoding information in addition to a payload that can be as large as 2712
bits. The extra amount of data encoding heightens transmission security. It
also helps to maintain a robust communication link in an environment filled
with other devices and common noise.
The HCI
(host controller interface) layer acts as a boundary between the lower
layers of the Bluetooth protocol stack and the upper layers. The Bluetooth
specification defines a standard HCI to support Bluetooth systems that are
implemented across two separate processors. For example, a Bluetooth system on
a computer might use a Bluetooth module‘s processor to implement the lower
layers of the stack (radio, baseband, link controller, and link manager). It
might then use its own processor to implement the upper layers (L2CAP, RFCOMM,
OBEX, and selected profiles). In this scheme, the lower portion is known as
the Bluetooth module and the upper portion as the Bluetooth
host.
Of
course, it’s not required to partition the Bluetooth stack in this way.
Bluetooth headsets, for example, combine the module and host portions of the
stack on one processor because they need to be small and self-contained. In
such devices, the HCI may not be implemented at all unless device testing is
required.
Because
the Bluetooth HCI is well defined, you can write drivers that handle different
Bluetooth modules from different manufacturers. Apple provides an HCI
controller object that supports a USB implementation of the HCI layer.
Upper
Layers:
Above
the HCI layer are the upper layers of the protocol stack. The first of these is
the L2CAP (logical link control and adaptation protocol) layer. The
L2CAP is primarily responsible for:
·
Establishing connections across
existing ACL links or requesting an ACL link if one does not already exist
·
Multiplexing between different
higher layer protocols, such as RFCOMM and SDP, to allow many different
applications to use a single ACL link
·
Repackaging the data packets it
receives from the higher layers into the form expected by the lower layers
The
L2CAP employs the concept of channels to keep track of where data packets come
from and where they should go. You can think of a channel as a logical
representation of the data flow between the L2CAP layers in remote devices.
Because it plays such a central role in the communication between the upper and
lower layers of the Bluetooth protocol stack, the L2CAP layer is a required
part of every Bluetooth system.
Above
the L2CAP layer, the remaining layers of the Bluetooth protocol stack aren’t
quite so linearly ordered. However, it makes sense to discuss the service
discovery protocol next, because it exists independently of other higher-level
protocol layers. In addition, it is common to every Bluetooth device.
The SDP (service discovery
protocol) defines actions for both servers and clients of Bluetooth
services. The specification defines a service as any feature that is usable by
another (remote) Bluetooth device. A single Bluetooth device can be both a
server and a client of services. An example of this is the Macintosh computer
itself. Using the file transfer profile (described in “The Bluetooth
Profiles—A Hierarchy of Groups”)
a Macintosh computer can browse the files on another device and allow other
devices to browse its files.
An
SDP client communicates with an SDP server using a reserved channel on an L2CAP
link to find out what services are available. When the client finds the desired
service, it requests a separate connection to use the service. The reserved
channel is dedicated to SDP communication so that a device always knows how to
connect to the SDP service on any other device. An SDP server maintains its own
SDP database, which is a set of service records that describe the services the
server offers. Along with information describing how a client can connect to
the service, the service record contains the service’s UUID,
or universally unique identifier.
Also above the L2CAP layer in Figure 1-1 is the RFCOMM layer. The RFCOMM protocol
emulates the serial cable line settings and status of an RS-232 serial port.
RFCOMM connects to the lower layers of the Bluetooth protocol stack through the
L2CAP layer.
By providing serial-port emulation,
RFCOMM supports legacy serial-port applications. It also supports the OBEX
protocol (discussed next) and several of the Bluetooth profiles (discussed
in “The Bluetooth
Profiles—A Hierarchy of Groups”).
OBEX
(object exchange) is a transfer protocol that
defines data objects and a communication protocol two devices can use to easily
exchange those objects. Bluetooth adopted OBEX from the IrDA IrOBEX
specification because the lower layers of the IrOBEX protocol are very similar to
the lower layers of the Bluetooth protocol stack. In addition, the IrOBEX
protocol is already widely accepted and therefore a good choice for the
Bluetooth SIG, which strives to promote adoption by using existing
technologies.
A
Bluetooth device wanting to set up an OBEX communication session with another
device is considered to be the client device.
1.
The client first sends SDP requests
to make sure the other device can act as a server of OBEX services.
2.
If the server device can provide
OBEX services, it responds with its OBEX service record. This record contains
the RFCOMM channel number the client should use to establish an RFCOMM channel.
3.
Further communication between the
two devices is conveyed in packets, which contain requests and responses, and
data. The format of the packet is defined by the OBEX session protocol.
Although
OBEX can be supported over TCP/IP, this document does not discuss this option
(nor is it described in the Bluetooth specification).
