- Interoperability Through Bluetooth<SUP>TM</SUP> Profiles
- The Bluetooth Version 1.0 Profiles
- Interoperability
- Summary
The Bluetooth Version 1.0 Profiles
The Bluetooth version 1.0 profile specification (Part 2 of the specification) is more than 400 pages long and includes 13 different profiles. Bluetooth Revealed, the book that I co-authored with Chatschik Bisdikian, discusses the version 1.0 profiles in detail, devoting five chapters to this topic. Here we briefly review the profiles, looking specifically at a couple of examples.
The profiles are of two types: those that provide fundamental "building block" definitions, often used in turn by other profiles; and those that specifically address concrete usage cases. There are four profiles of the former type: generic access, service discovery application, serial port, and generic object exchange. The remaining nine profiles (cordless telephony, intercom, headset, fax, dial-up networking, LAN access, object push, synchronization, and file transfer) are based on one or more of the fundamental four profiles. The specification includes some information on how the profiles relate to each other; in our book, Bisdikian and I discuss the relationship among the various profiles and suggest ways that the profiles might be classified, defining four functionally related groups.
Although this article does not discuss each of the profiles in detail, two are reviewed as examples of ways that the profiles specify information that can help to achieve interoperable implementations of the specification.
The Headset Profile
This profile covers the usage case (called the "Ultimate Headset," in the specification) associated with a Bluetooth wireless audio headset used in conjunction with a Bluetooth mobile telephone or with a Bluetooth portable computer. Basic operation for such a wireless headset is like that of its wired equivalents used commonly today: The headset, with a microphone and a speaker, serves as the audio source and sink for voice traffic that is carried over the cellular link of the mobile phone or for audio traffic associated with the computer.
The headset profile is a relatively simple one. It defines four procedures for four operations:
-
Incoming call (audio connection)
-
Outgoing call (audio connection)
-
Call (audio) transfer
-
Volume control
Of these, volume control is optional. The remaining three define how audio is routed between the headset and the other device, as well as how the audio traffic is generated, transferred, and received.
Like all profiles, the headset profile includes information about the protocol stack used to accomplish the associated usage case, how particular layers of the protocol stack are to be configured and used, and which of the other profiles are relevant to this one.
As for the protocol stack, the headset profile uses (directly or indirectly) the baseband, link manager, logical link control and adaptation (L2CAP), RFCOMM, and service discovery (SDP) layers of the protocol stack. The headset profile also relies upon AT commands transferred over the RFCOMM layer (the specification illustrates this as a "headset control" layer, although it is not an explicitly defined Bluetooth protocol).
The headset profile defines specific requirements for link control and service discovery in terms of functions and operations defined in the core specification (Part 1, the protocol stack specification) for these layers' associated protocols. Although it may not be directly evident, the headset profile also defines requirements for the L2CAP and RFCOMM layers because it requires support for the serial port profile; the serial port profile, in turn, defines specific requirements for L2CAP and RFCOMM.
In addition to its reliance on the serial port profile, the headset profile builds upon the generic access profile (GAP) and at least indirectly uses concepts from the service discovery application profile (SDAP). The GAP is the fundamental profile with which all Bluetooth devices must comply, so all other profiles inherit from it. All the "concrete" usage case profiles also include an element of service discovery, and the SDAP provides guidance for application developers using the service discovery information contained in these profiles.
The File Transfer Profile
Transferring files wirelessly is not unique to Bluetooth technology. The Infrared Data Association (IrDAâ) technology, for example, is another method of wireless file transfer. In fact, the SIG has adopted protocols defined by the IrDA for the Bluetooth protocol stack. The file transfer profile describes how to use these and other Bluetooth protocols for interoperable folder and file transfer. This usage model can apply to several types of Bluetooth devices with object or file storage systems, including portable computers and mobile telephones. The usage scenario is rather straightforward: After a connection is made, the two devices can push and pull folders and files between them. Optionally, creating and deleting files and folders may be supported.
The protocol stack used for the file transfer profile includes an additional layer, as compared to that used for the headset profile. In addition to the baseband, link manager, L2CAP, SDP, and RFCOMM layers of the headset profile, the file transfer profile also uses the IrOBEX (or just OBEX, for object exchange) protocol adopted from the IrDA. Within OBEX, several different types of objects can be exchanged; the object formats of most interest for this profile are folder and file objects.
The file transfer profile focuses on object transfer using the OBEX layers, defining client and server roles and mapping OBEX operations to the Bluetooth protocol stack. Much of this profile describes how to push, pull, create, and delete objects using OBEX. Like other profiles, the file transfer profile also describes the use of SDP, including a service record to be used by devices that offer the file transfer profile services. Usage of the other relevant layers of the stack (baseband, link manager, L2CAP, and RFCOMM) is described in other profiles from which the file transfer profile inherits.
The file transfer profile depends upon the generic object exchange profile, which in turn relies upon the serial port profile. The generic object exchange profile defines many fundamental OBEX operations that are used not only in the file transfer profile, but also in the related synchronization and object push profiles. The file transfer profile, then, needs only to describe the specific OBEX operations needed to exchange files and folders. In all of the object exchange profiles, OBEX operates over the RFCOMM layer. Generic RFCOMM usage is described in the serial port profile. Because the file transfer profile inherits from the serial port profile, the usage of the remaining layers of the protocol stack used for file and object transfer (baseband, link manager, L2CAP, and RFCOMM itself) are defined in the serial port profile and thus are not detailed in the file transfer profile.