Traffic from data applications is first routed through the logical link control and adaptation protocol (L2CAP) layer. The L2CAP layer shields higher-layer protocols and applications from the details of the lower-layer transport protocols. Thus, higher layers need not be aware of the frequency hops occurring at the radio and baseband level nor the specific packet formats used for transmission over the Bluetooth air-interface. L2CAP supports protocol multiplexing, allowing multiple protocols and applications to share the air-interface. It also enables segmentation of large packets used by higher layers into smaller packets for baseband transmission and the corresponding reassembly of those packets by the receiving device. Furthermore, the L2CAP layers in two peer devices facilitate the maintenance of the desired grade of service by negotiating an acceptable level of service. Based on the requested level of service, an L2CAP layer implementation may then exercise admission control for new incoming traffic and coordinate with lower layers to maintain the desired level of service. The L2CAP layer and its over-the-air protocol are described in more detail in Chapter 7.

Link managers in each device negotiate the properties of the Bluetooth air-interface between them using the link manager protocol (LMP). These properties include bandwidth allocation to support a desired grade of service for data (L2CAP) traffic and periodic bandwidth reservation to support audio traffic. Bluetooth link managers in communicating devices use a challenge-response approach for authenticating the devices. They supervise device pairing (creation of a trust relationship between the devices by generating and storing an authentication key for future device authentication) and encryption of the data flowing over the air-interface between the devices whenever needed. If authentication fails, the link managers may sever the link between the devices, thus prohibiting any communication between the devices. Link managers also support power control by negotiating low activity baseband modes of operation (introduced in Chapter 2 and detailed in Chapter 6) through the exchange of information about parameters such as the duration of the low-activity baseband mode. Link managers may request adjustments to the transmission power level for further power conservation as described in Chapters 2 and 6. The link manager layer and its over-the-air protocol are described in more detail in Chapter 6.

The baseband layer determines and instantiates the Bluetooth air-interface.^[2] It defines the process by which devices search for other devices and how they connect to them. The baseband layer defines the master and slave roles (described in Chapter 2) for devices—the device that initiates a connection process becomes the master of the link, while the other device becomes a slave. The baseband also defines how the frequency hopping sequences used by communicating devices are formed. It defines the rules for sharing the air-interface among several devices; these rules are based upon a time division duplex (TDD), packet-based polling scheme. It further defines how synchronous and asynchronous traffic can share the air-interface. For example, in synchronous transmissions, the master transmits to and/or polls a slave device periodically. The baseband defines the various packet types supported for synchronous and asynchronous traffic, as well as various packet processing procedures including error detection and correction, signal whitening,^[3] encryption, packet transmission and retransmissions. The baseband layer and its over-the-air protocol are described in more detail in Chapter 6.

Note that the concept of master and slave devices does not propagate higher than the link manager. At the L2CAP layer and above, communication is based upon a peer-to-peer model and no special provisions are made for different actions in a master device or in a slave device.

Over-the-air packet transmissions are meaningless unless properly matched radio transmitters and receivers, or transceivers, are employed. The Bluetooth radio design includes several parameters designed to make it optimal for use with the Bluetooth protocol stack in short range wireless communications. The radio section of Chapter 6 gives details of the Bluetooth radio.

The radio, baseband and link manager may be packaged together into a Bluetooth module. The module then attaches to a host device, enabling that device with Bluetooth wireless communication. In this configuration, the host contains the L2CAP layer and any appropriate portions of the higher layers of the stack. The module attaches to the host via some physical interface, called the host transport, such as Universal Serial Bus (USB), an RS-232 port or a UART. To enable the development of interoperable Bluetooth modules by different vendors, the specification defines a common interface for accessing the lower layers of the stack that reside in the module, independently of the particular physical interface that connects the host to the module. The host controller interface (HCI) allows higher layers of the stack, including applications, to access the baseband, link manager and other hardware registers through a single standard interface. Through HCI commands the module may enter certain modes of operation in which, say, an authentication operation or a device paging state may be performed. Through HCI events, higher layers of the stack can be informed of the results of a device inquiry operation, read the settings for the audio codec residing in the baseband, read the signal strength of incoming transmissions, and so on. Of course traffic, both synchronous and asynchronous, passes through the HCI as it is transmitted or received by the host, as well.

While the HCI layer typically resides below the L2CAP layer, it is not a required part of the specification. It has been developed for the sole purpose of enabling interoperability among host devices and Bluetooth modules, either of which could come from a variety of developers. Product implementations need not comply with the HCI specification to support a fully compliant Bluetooth air-interface. For example, in a tightly integrated, embedded system, an HCI may not exist at all or it may exist at a different point of the stack, perhaps above L2CAP, and it might have a form other than the one described in the specification. The HCI and the various host transport protocols are presented in more detail in Chapter 7.

The control path shown in Figure 5.2 is used to communicate control information between layers. For example, the L2CAP layer might notify the link manager of its quality of service expectations, or an application could communicate an end user's request for a lower power consumption mode. Typically, although not exclusively, the controls that are exposed to the higher layers (including to an end user) are for setting a mode of operation for the device that persists until that mode is again explicitly altered through an action that originates at a higher layer. For example, one may manually enable or disable authentication or encryption for a given device. A high-layer entity, like an application or a user, could place a device in a reduced power consumption mode, which would be translated to a control signal that a link manager understands and supports so it can act accordingly. Similarly, a device could also be placed in a discoverable mode, where the device responds to inquiries sent by other devices, or the device could be set to a private mode, in which the device responds only to connection requests from specific known devices, which also must be authenticated.

The control path is not explicitly described in the specification, but it is interwoven among the various protocols in the stack. Nevertheless, the HCI specification includes the bulk of the information that the control path carries. We honor this same approach, discussing the control signals carried through the control path via the HCI and the various protocols and modes of operation that these signals affect.

Serial ports are one of the most common communications interfaces used with computing and communications devices today. Most serial communication involves a cable for transferring data across serial ports. Since Bluetooth wireless communication is aimed at replacing cables, support for serial communications and related applications is an important feature for the initial set of cable-replacement usage models. Peer-to-peer file and object transfer, data synchronization and dial-up networking are some applications that commonly use serial communications (and associated cables).

To facilitate the use of serial communications over Bluetooth wireless links, the protocol stack defines a serial port abstraction called RFCOMM. RFCOMM presents a virtual serial port to applications; this facilitates the easy migration of applications modeled for cabled serial communications to the realm of wireless serial communications. An application can use RFCOMM very much like a standard wired serial port to accomplish scenarios such as synchronization, dial-up networking and others without significant changes (if any) to the application. Thus the intent of the RFCOMM protocol is to enable legacy, serial port-based applications to use Bluetooth transports.

RFCOMM is modeled on the European Telecommunications Standards Institute (ETSI) TS 07.10 standard. This standard defines multiplexed serial communications over a single serial link. The Bluetooth specification adopts a subset of the ETSI 07.10 standard and also defines some adaptations designed specifically for Bluetooth communication.

Because serial communications are so prevalent in digital devices, the serial port capabilities that RFCOMM provides to applications make it an important part of the protocol stack, especially for enabling legacy applications based upon version 1.0 of the specification. Details of the RFCOMM layer can be found in Chapter 8.

In some respects, instantiating any of the Bluetooth usage models might be viewed as making use of some set of services. A primary motivation for forming networks of devices is to allow those devices to communicate with each other and thus avail themselves of each other's services. In traditional networks such as Ethernet LANs, services such as file serving, print serving, name serving, bridges and gateways are provided by some set of devices (usually considered "servers") in the network so that other devices (usually considered "clients") can use them. In many cases the clients locate these network services through some static configuration; this configuration is often established and maintained by a system administrator who configures the client devices (or gives the necessary configuration information to the users of those devices, who in turn configure them).

For dynamic ad hoc networks such as those that could be enabled by Bluetooth wireless communications, though, this sort of static configuration is insufficient. Any two or more devices might begin communicating over Bluetooth links on the spur of the moment, and if these devices are to be able to make use of each other's services they require a more dynamic means of locating those services. Once a communication channel has been established, a next logical step in device communications might be to find out about services that are available to the device. This is what the Bluetooth service discovery protocol (SDP) addresses. SDP defines a standard method for Bluetooth devices to discover and learn about the services offered by other devices; symmetrically, it defines a way for devices to describe those services offered to other devices.

Service discovery is a key component in enabling end-user value in dynamic networks. The Bluetooth service discovery protocol is designed specifically to enable this function in an efficient and optimized manner within environments that exploit Bluetooth wireless communication. SDP is described in detail in Chapter 8.

Chapter 2 described infrared wireless communication and its resemblance in some respects to Bluetooth wireless communication. The Infrared Data Association (IrDA) has defined protocols for exchanging and synchronizing data in wireless environments. The SIG has chosen to adopt several of the IrDA protocols and data models because IrDA and Bluetooth wireless communication share some important attributes, usage scenarios and applications.

A fundamental requirement for exchanging data among devices is to define the format, both syntax and semantics, of that data. The infrared object exchange (IrOBEX or often, just OBEX) protocol developed by the IrDA is a session protocol for peer-to-peer communication. Among the applications in which OBEX can be used is the exchange of well-defined objects. Data objects such as electronic business cards (vCard format), e-mail or other messages (vMessage format), calendar entries (vCal format) and others can all be exchanged using the OBEX protocol. OBEX is the fundamental building block upon which the usage models of file transfer (object exchange) and object push are built. Additionally, infrared mobile communications (IrMC), another IrDA-defined protocol, enables the synchronization of these same objects.

The IrDA interoperability layers of the protocol stack are intended to promote interoperability at the application layer. They are described more fully in Chapter 9.

Bluetooth wireless communication uses a peer-to-peer network topology rather than a LAN style topology. Nevertheless, the technology does make allowances for networking, in particular connecting to larger networks through a dial-up connection or via a network access point. The specification also discusses interoperability with the Wireless Application Protocol (WAP), a specification for wireless networking used by devices such as mobile telephones.

Dial-up networking uses the AT command layer of the middleware protocol stack, which is discussed below, to establish a connection to a network. In many cases, the network being accessed is one that uses the Internet Protocol, referred to as an IP network. Once a dial-up connection to an IP network is established, standard Internet protocols (such as TCP, UDP, HTTP and so on) can be used by the device (perhaps a notebook or handheld computer) that initiated the network connection to interact with the network.

A device might also connect to an IP network via a network access point as described in the LAN Access Using PPP Profile. In this case, a Bluetooth link connects the device to a network access point; the network access point is in turn connected to the larger (most likely, but not necessarily wired) network. The Internet point-to-point protocol (PPP) is used over the Bluetooth link to connect to the access point. As with dial-up networking, once the PPP connection is established, standard Internet protocols can be used to interact with the network. Access to a WAP network using a WAP gateway works similarly; the same sort of PPP connection is established to an IP network access point over which standard WAP protocols can be used to interact with the network.

It is worth noting that release 1.0 of the specification does not define a profile or an instance of the protocol stack that supports the use of Internet protocols such as TCP/IP directly over Bluetooth links. The only means of IP network access defined in version 1.0 of the specification is through the use of PPP as described above. While it certainly should be possible to directly operate an IP protocol stack using Bluetooth wireless communication as the bearer, the SIG has not defined an interoperable manner (that is, a profile) for such operation. In all likelihood, future revisions to the specification will address the direct use of Internet protocols with Bluetooth wireless communication.

As previously noted, one key advantage of Bluetooth wireless communications is its ability to carry voice traffic as well as data. While the protocol layers discussed to this point exist primarily for use with data traffic, the Bluetooth telephony control specification (TCS) layer is designed to support telephony functions, including call control and group management. These operations are often associated with voice calls in which TCS is used to set up the call parameters; once a call is established, a Bluetooth audio channel can carry the call's voice content. TCS might also be used to set up data calls, such as would be used with the dial-up networking profile; in this case, the call content is then carried as standard data packets over L2CAP.

The TCS protocols are compatible with the International Telecommunications Union - Telecommunication (ITU-T) Q.931 specification. Because they use a binary encoding, these protocols are referred to in the specification as TCS-BIN. During development of the specification, the SIG also considered a second TCS protocol called TCS-AT. TCS-AT defined a modem control protocol (often called AT commands) that flowed through the RFCOMM layer. While AT commands over RFCOMM are indeed used for some applications, the specification does not define a separate protocol for TCS-AT. TCS-BIN is appropriate for some of the release 1.0 telephony-based profiles; applications that need to use AT commands over the RFCOMM serial interface are free to do so (as shown in Figure 5.3), but the specification does not define these AT commands as a separate protocol. Several of the version 1.0 profiles, including headset, fax, and dial-up networking, all use AT commands over RFCOMM rather than the TCS-BIN protocol.

The TCS-BIN protocol includes call control functions, group management functions and a method for devices to exchange call signaling information without actually placing a call or having a call connection established. Each of these facets of TCS is detailed in Chapter 10.

Audio, especially voice audio, is treated uniquely in Bluetooth communication. Because audio traffic is isochronous, meaning that it has a time element associated with it, voice audio traffic typically is routed directly to and from the baseband layer; it does not go through upper layers such as L2CAP.^[4] Special baseband packet structures, called synchronous connection-oriented (or SCO) packets are defined for use with typical audio traffic. Bluetooth communication allows for up to three audio channels at one time (with some bandwidth left over for data traffic).

Bluetooth audio communication takes place at a rate of 64 kilobits per second (Kbps) using one of two data encoding schemes: 8-bit logarithmic pulse code modulation (PCM) or continuous variable slope delta (CVSD) modulation. Compression techniques called A-law and μ-law are applied for PCM audio.

Since voice is a primary application of audio communication (especially in devices such as smart phones that use Bluetooth wireless communication), audio is often equated with voice. Of course, voice is not the only sort of audio traffic that can be carried by the Bluetooth baseband. So long as the audio stream can be sufficiently rendered at 64 Kbps, it can be transmitted and received over Bluetooth links. Thus, in addition to voice, Bluetooth audio channels could carry other forms of audio, such as some music^[5] or short audio clips.

Because voice is an integral part and key attribute of Bluetooth wireless communication, it may be somewhat surprising that only a few pages of the specification deal directly with audio. This is not because audio is unimportant; rather it is mostly because audio traffic is carried directly over the baseband in packets designed for that purpose. Thus it is not necessary to include lengthy explanations of audio traffic - the format of the audio data is specified using existing standards - and that, for the most part, is that. It is, however, quite important to understand the baseband SCO packet structure and usage to achieve a fuller understanding of Bluetooth audio communication. Thus, while audio is explained in more detail in Chapter 10, it is also indirectly detailed in the baseband discussion of Chapter 6.