---

The Mac OS X Bluetooth Protocol Stack

The foundation of Mac OS X Bluetooth support is Apple’s implementation of the Bluetooth protocol stack. For reference, the Bluetooth protocol stack, as defined by the Bluetooth SIG, is described in “The Bluetooth Protocol Stack.” Figure 2-1 shows the Bluetooth protocol stack that’s built into Mac OS X version 10.2 and later.

The Mac OS X implementation of the Bluetooth protocol stack includes both in-kernel and user-level portions. Figure 2-1 shows the layers of the stack that exist in the kernel and the corresponding user-level layers an application can access.

The Bluetooth module at the bottom of the stack is the hardware component that implements the Bluetooth radio, baseband, and link manager protocols. Neither an application nor even the host has access to this layer of the stack.

As described in “The Bluetooth Protocol Stack,” the HCI layer transmits data and commands from the layers above to the Bluetooth module below. Conversely, the HCI layer receives events from the Bluetooth module and transmits them to the upper layers.

To implement the functions of the HCI layer in the kernel, Apple defines the abstract class IOBluetoothHCIController. IOBluetoothHCIController is the superclass of another in-kernel object, AppleBluetoothUSBHCIController, which provides support for Bluetooth over USB. Therefore, any hardware that supports the USB HCI specification should work with the Bluetooth implementation on Mac OS X version 10.2 and later. It is possible, although certainly not trivial, to subclass the IOBluetoothHCIController object to provide vendor-specific functionality or to support Bluetooth over a transport other than USB. If you need to do this, you should contact Apple’s Developer Technical Support (at http://developer.apple.com/technicalsupport) for assistance.

Apple implements the L2CAP and RFCOMM layers in the kernel. Applications can use objects in the user-level L2CAP and RFCOMM layers to access the corresponding in-kernel objects, although many applications will not need to do so directly.

Recall that the L2CAP (logical link control adaptation protocol) provides:

• Multiplexing of data channels

• Segmentation and reassembly of data packets to conform to a device’s maximum packet size

• Support for different channel types and channel IDs, such as RFCOMM

The in-kernel L2CAP layer provides the transport for the higher-level protocols and profiles. As the primary communication gateway between two Bluetooth-enabled devices, the Mac OS X L2CAP layer implements the ability to register as a client of an L2CAP channel and write data to the channel. Using the L2CAP layer’s multiplexing feature, it is possible to send and receive data to and from the RFCOMM layer and the SDP layer at the same time.

Above the in-kernel L2CAP layer in Figure 2-1 is the RFCOMM protocol layer. The in-kernel RFCOMM protocol layer is a serial-port emulation protocol. Its primary mission is to make a data channel appear as a serial port. It also implements the ability to create and destroy RFCOMM channels and to control the speed of the channel as if it were a physical serial-port cable.

The portion of the stack shown above the user-kernel boundary in Figure 2-1 is accessible to applications. The L2CAP and RFCOMM layers in user space are not duplicates of the in-kernel L2CAP and RFCOMM layers. Instead, they represent the user-level APIs an application uses to communicate with the corresponding in-kernel layers.

The SDP (service discovery protocol) layer is more of a service than a protocol, but it is part of the built-in Mac OS X Bluetooth protocol stack. It is shown connected to the user-level L2CAP layer because it uses an L2CAP channel to communicate with remote Bluetooth devices to discover their available services. Apple provides an SDP API you can use to discover what services a device supports.

Above the user-level RFCOMM layer is the OBEX (object exchange) protocol layer. The OBEX protocol is an HTTP-like protocol that supports the transfer of simple objects, like files, between devices. The OBEX protocol uses an RFCOMM channel for transport because of the similarities between IrDA (which defines the OBEX protocol) and serial-port communication.

In versions of Mac OS X prior to 10.4, the OBEX API provides primitive commands, such as CONNECT, PUT, and GET. Beginning in Mac OS X version 10.4, Apple introduced API that simplifies common OBEX operations found in the object push and file transfer profiles, such as getting and putting file objects on remote devices. This API makes it easy for a developer to create an application that adheres to the requirements of these profiles. Note that if you want to use OBEX for other profiles, however, you probably will still need to rely on the primitive commands provided by the OBEX API. For more information on the new API, see “OBEXFileTransferServices Class” and “Objects in OBEX Connections.”

---