The Bluetooth Profiles—A Hierarchy of Groups
The
Bluetooth specification defines a wide range of profiles, describing many
different types of tasks, some of which have not yet been implemented by any
device or system. By following the profiles’s procedures, developers can be
sure that the applications they create will work with any device that conforms
to the Bluetooth specification.This section focuses on those profiles that OS X
supports. For information on other profiles, including those still in
development, see the Bluetooth specification.
At
a minimum, each profile specification contains information on the following
topics:
·
Dependencies
on other profiles. Every profile depends on the
base profile, called the generic access profile, and some also depend on
intermediate profiles.
·
Suggested
user interface formats. Each
profile describes how a user should view the profile so that a consistent user
experience is maintained.
·
Specific
parts of the Bluetooth protocol stack used by the profile. To perform its task, each profile uses particular
options and parameters at each layer of the stack. This may include an outline
of the required service record, if appropriate.
The Bluetooth profiles are organized
into a hierarchy of groups, with each group depending upon the features
provided by its predecessor. Figure 1-2 illustrates the dependencies of the Bluetooth profiles.
The Base Profile:
At
the base of the profile hierarchy is the generic access profile (GAP), which
defines a consistent means to establish a baseband link between Bluetooth
devices. In addition to this, the GAP defines:
·
Which features must be implemented
in all Bluetooth devices
·
Generic procedures for discovering
and linking to devices
·
Basic user-interface terminology
All
other profiles are based on the GAP. This allows each profile to take advantage
of the features the GAP provides and ensures a high degree of interoperability
between applications and devices. It also makes it easier for developers to
define new profiles by leveraging existing definitions.
The service discovery
application profile describes how an application should use the SDP
(described in “The Bluetooth
Protocol Stack”) to
discover services on a remote device. As required by the GAP, any Bluetooth
device should be able to connect to any other Bluetooth device. Based on this,
the service discovery application profile requires that any application be able
to find out what services are available on any Bluetooth device it connects to.
The human interface device
(HID) profile describes how to communicate with a HID class device
using a Bluetooth link. It describes how to use the USB HID protocol to
discover a HID class device’s feature set and how a Bluetooth device can
support HID services using the L2CAP layer. For more information about the USB
HID protocol, see http://www.usb.org.
As
its name suggests, the serial port profile defines RS-232
serial-cable emulation for Bluetooth devices. As such, the profile allows
legacy applications to use Bluetooth as if it were a serial-port link, without
requiring any modification. The serial port profile uses the RFCOMM protocol to
provide the serial-port emulation.
The dial-up
networking (DUN) profile is built on the serial port profile and
describes how a data-terminal device, such as a laptop computer, can use a
gateway device, such as a mobile phone or a modem, to access a telephone-based
network. Like other profiles built on top of the serial port profile, the
virtual serial link created by the lower layers of the Bluetooth protocol stack
is transparent to applications using the DUN profile. Thus, the modem driver on
the data-terminal device is unaware that it is communicating over Bluetooth.
The application on the data-terminal device is similarly unaware that it is not
connected to the gateway device by a cable.
The headset
profile describes how a Bluetooth enabled headset should communicate
with a computer or other Bluetooth device (such as a mobile phone). When
connected and configured, the headset can act as the remote device’s audio
input and output interface.
The hardcopy
cable replacement profile describes how to send rendered data over a
Bluetooth link to a device, such as a printer. Although other profiles can be
used for printing, the HCRP is specially designed to support hardcopy
applications.
The generic
object exchange profile provides a generic blueprint for other
profiles using the OBEX protocol and defines the client and server roles for
devices. As with all OBEX transactions, the generic object exchange profile
stipulates that the client initiate all transactions. The profile does not, however,
describe how applications should define the objects to exchange or exactly how
the applications should implement the exchange. These details are left to the
profiles that depend on the generic object exchange profile, namely the object
push, file transfer, and synchronization profiles.
The object
push profile defines the roles of push server and push client. These
roles are analogous to and must interoperate with the server and client device
roles the generic object exchange profile defines. The object push profile
focuses on a narrow range of object formats for maximum interoperability. The
most common of the acceptable formats is the vCard format. If an application
needs to exchange data in other formats, it should use another profile, such as
the file transfer profile.
The file
transfer profile is also dependent on the generic object exchange
profile. It provides guidelines for applications that need to exchange objects
such as files and folders, instead of the more limited objects supported by the
object push profile. The file transfer profile also defines client and server
device roles and describes the range of their responsibilities in various
scenarios. For example, if a client wishes to browse the available objects on
the server, it is required to support the ability to pull from the server a
folder-listing object. Likewise, the server is required to respond to this
request by providing the folder-listing object.
The synchronization
profile is another dependent of the generic object exchange profile.
It describes how applications can perform data synchronization, such as between
a personal data assistant (PDA) and a computer. Not surprisingly, the
synchronization profile, too, defines client and server device roles. The
synchronization profile focuses on the exchange of personal information
management (PIM) data, such as a to-do list, between Bluetooth enabled devices.
A typical usage of this profile would be an application that synchronizes your
computer’s and your PDA’s versions of your PIM data. The profile also describes
how an application can support the automatic synchronization of data—in other
words, synchronization that occurs when devices discover each other, rather
than at a user’s command.
