Architectural Overview of Intel's Bluetooth* Software Stack (continued)


Previous Next     Page 4 of 13

IMPLEMENTING THE BLUETOOTH PROTOCOL STACK

RFBD is at the core of Intel's Bluetooth software stack as shown in Figure 3. It co-exists with an HCI driver in the same binary. The HCI driver is responsible for all interactions with the Bluetooth Host Controller present on the Bluetooth module interfacing to the PC. It also serves to abstract the Bluetooth hardware interface in terms of a private interface exposed by it.

Figure 3: Architecture of Intel's Bluetooth stack

An HCI transport driver is typically layered under the HCI driver. It has the responsibility of handling the interface used to connect the Bluetooth* hardware module to the PC. Figure 3 shows two such HCI transport drivers for the purposes of exposition: the USB driver stack and the PC Card driver. It is important to note that only one HCI transport driver is to be active at any given time in the stack1.

In the case of the USB transport, the Bluetooth module interfaces with the PC using USB as shown in Figure 4 below.

Figure 4: USB interfaces to access HCI and data

The HCI commands are transported using the USB control pipe, HCI events are transported on the USB interrupt pipe, asynchronous data are transported as USB bulk data, and synchronous data are transported over USB isochronous pipes as specified in the HCI USB specification. The Bluetooth USB minidriver on the operating systems' USB stack is responsible for abstracting the HCI transport specifics and presenting the data, events, and commands to the HCI driver in a transport-independent manner. An IRP-based [6] interface is defined under the HCI driver for this purpose, and all HCI transport drivers use this interface to talk to the HCI driver. Having such a common interface enables support for different HCI transport drivers.

The Bluetooth drivers loaded by the RFBD (referred to henceforth as the client drivers) talk to the RFBD using a kernel-mode interface called the RF Bus Driver Interface (RFBDI). The RFBDI is similar to other bus driver interfaces published by Microsoft such as the USBDI* or the 1394BDI* [6].

Client drivers typically implement minidriver or port driver functionality for some class driver in the OS. This is important to ensure seamless integration into the OS. The class drivers expose interfaces to these drivers as domain-specific APIs in the user mode.

There is one key module in the user mode and it is called the Bluetooth Executive (BTEXEC). Among other tasks, the BTEXEC is responsible for exposing a user-mode interface that all user-mode applications can use to access Bluetooth functionality. This interface is called the Bluetooth API (BTAPI).

All Bluetooth UI components developed by Intel use BTAPI to interface with the driver stack. The idea is that the BTAPI should contain all the information typically needed from the kernel stack by third-party application developers.

There could be transport-specific, platform-specific, or vendor-specific drivers not covered here.

Kernel-Mode Client Drivers
Two client drivers that are needed for supporting the usage models mentioned in this paper are the RFCOMM driver and the audio driver, as shown in Figure 5 below.

Figure 5: RFCOMM driver emulates serial ports

The RFCOMM driver is responsible for implementing multiple virtual comm ports over RFCOMM connections with each device supporting the protocol. These virtual comm ports are used to support both legacy comm port and IrOBEX-based applications for Bluetooth technology. The latter category includes file transfer and synchronization. RFCOMM is implemented as several drivers that together implement the RFCOMM protocol, comm port emulation functionality, and the interfaces to either VCOMM or serial.sys, depending on the OS.

In addition, PPP over L2CAP is the basis for dial-up networking and PPP-based LAN access points. These can also be supported by the RFCOMM driver set mentioned above.

The audio driver is responsible for exposing the headset as a playback and recording device to the system. It is also responsible for processing the audio stream coming over the air interface and piping it into the streaming class driver.

Programming Interfaces
RFBDI is an IRP-based kernel mode interface similar to USBDI or 1394 BDI interfaces published in the DDKs for Windows 2000. It supports access to the following features:

  • audio data stream
  • connection-oriented data stream
  • connectionless L2CAP interface
  • connection-oriented event handling (examples of these events include those from L2CAP, SDP, and security)
  • kernel-mode service discovery functions
  • Bluetooth TCI
  • L2CAP QoS
BTAPI provides access to features specific to Bluetooth technology in the kernel stack that typically cannot already be accessed through existing Windows APIs. BTAPI provides access to the following:
  • Information relating to Bluetooth device discovery. This includes access to local and remote device information and properties, and an ability to initiate device discovery.
  • Radio configuration and status. This includes an ability to change duration and length of page and inquiry scans, access to RSSI, and an estimation of link quality.
  • Service discovery information. This includes access to device services and attributes, and an ability to add or remove services on the local host.
  • Security information. The user can set Bluetooth security modes for the local device, authorize use of a device in an ad-hoc manner, and communicate trust status with the stack.
  • Power management. The user can set radio power states using BTAPI and control wake-up states in the software.
Applications use the Win32* Comm API for performing open, close, read, write, and flow control functions on the virtual comm ports exposed by the RFCOMM driver. In the case of the server, the application creates an SDP record for its service, which results in the creation of a comm port, opens the port, and "listens" on this port for incoming connections. On the client side, the PC inquires and searches for devices exporting this functionality using SDP, loads drivers to handle the service (this results in a comm port being created), opens the port, and connects to the server.

Usage of virtual comm ports for Bluetooth technology is characterized by the following features:

  • Applications need to close and re-open the ports after each session.
  • Link loss is indicated by dropping all communication signals low (this includes CD, CTS, DTR, DSR and RTS). The applications need to close the port on a link loss.
  • Any reads and writes to the port will fail when the devices are not connected.
  • BTAPI functions are needed for addition and deletion of SDP records, inquiry, and service discovery.
  • There is no support for baud rate pacing; 5-, 6-, and 7-bit word lengths; parity and stop bits; and xon / xoff flow control.



Previous Next     Page 4 of 13

 * Bluetooth is a trademark owned by its proprietor and used by Intel under license.
1  While multiple Bluetooth radios can physically be present in the same notebook computer, multiple such radios within a meter of each other are limited by RF physics on how well they work together.