Page 2 of 13

INTRODUCTION

Imagine a person with a PDA walking into an office and automatically waking up the notebook computer as a reaction. Further imagine that the notebook computer automatically synchronizes with the PDA for any calendar and task information entered overnight. When reminded of a meeting, the notebook computer is taken to a nearby conference room for a presentation while maintaining Intranet connectivity using a LAN access point. In the conference room business cards are exchanged electronically amongst the participants using notebook computers, PDAs, and cellular phones. All of this can be achieved with Bluetooth software support in the notebook computers. Bluetooth technology promotes the Always On, Always Connected and Anything, Anywhere, Anytime vision of seamless mobile computing for mobile personal computers (PCs) [1].

Goals of the Paper
This paper presents an overview of the architecture for Intel's Bluetooth software stack on a PC¹. It attempts to provide answers to the following questions:

• What does the Intel stack do?
• How do third-party Bluetooth application developers write applications specific to Bluetooth technology?
• How can third-party Bluetooth hardware or device developers develop custom drivers for their hardware that work with the Intel stack?
• What is expected from a Bluetooth device so that it interoperates with the Intel stack?

Bluetooth Usage Models and Architecture Goals
The Bluetooth Specification [4, 5] addresses a variety of usage models for Bluetooth devices. Intel's implementation of the Bluetooth stack either directly enables or provides the infrastructure for supporting the following Bluetooth SIG 1.0 usage models in its 1.0 release:

• Object transfer. This is an ability to transfer an object from one device to another. Objects include files and directories.
• Data access points. Access points enable access to the Internet, e-mail, and fax for these types of wireless connections for a notebook computer with Bluetooth: a) to a PSTN plug, b) to a cellular phone, and c) to a LAN access point.
• Synchronization. This involves synchronization of business cards, calendars, and task information between Bluetooth devices.
• Ultimate Headset. A Bluetooth headset can be wirelessly connected to a PC and appear as an audio playback or recording device.

• Support for legacy PC applications. There are a variety of legacy comm port applications for file transfer in the market today such as ProComm Plus* and Intellisync*. Supporting these legacy applications for achieving wireless file transfer between PCs enabled with Bluetooth technology would be convenient for end users.
• Support for applications native to the OS. This is part of Intel's goal of seamless integration into the OS. When a Bluetooth device comes in range of a notebook computer, this support enables the applications that are already in the OS (such as dial-up networking and direct cable connect) to be able to work with the new device.
• Support for APIs native to the OS. This is the other goal of proper integration into the OS: enabling APIs native to the OS wherever possible to access Bluetooth devices. One example is the support for Win32 Comm* API for accessing Bluetooth serial ports.
• Support for third-party development. Part of the goal of industry standard implementation is to enable third parties to add value to the software stack without re-implementing the entire stack. To accomplish this goal, Intel plans to publish a user-mode API interface for functionality specific to Bluetooth, which is not already covered in APIs native to the OS, and a new kernel-mode API. The user-mode API is for development of user-mode applications for Bluetooth technology, while the kernel-mode API is for custom drivers for Bluetooth devices.

At the start of any connection, the unit initiating the connection is assigned temporarily as a master. This assignment is valid only during this connection. The master may have active connections to up to seven other units, known as slaves. The configuration of a master unit connected to one or more slave units is called a piconet. Link management mechanisms allow radio units to time-division-multiplex between master and slave, allowing them to act as bridges between piconets, forming a scatternet. Mechanisms also exist to allow both masters and slaves to request new connections and accept new connections. The goal of the radio specification is to enable multiple virtual cables rather than a single cable-replacement capability.

Spread spectrum technology is used to operate in noisy environments and to allow multiple piconets to co-exist without a noticeable loss in throughput. A frequency-hopping scheme, with a rate of up to 1600 hops per second over 79 one MHz channels, is used to spread the signal over the entire available ISM spectrum.

Various error correction schemes are available to support reliable channels. Packets may be protected using 1/3 and 2/3 rate Forward Error Correction (FEC) schemes to help correct bit errors caused by weak signals near the range limit. An Automatic Repeat Request (ARQ) scheme helps to reliably transmit link-level frames.

The radio's link-level protocol supports both authentication and privacy, allowing users to develop a domain of trust between their personal devices. Connections may require a one-way, two-way, or no authentication. Authentication is based on a challenge-response algorithm. Encryption is used to protect the privacy of the connection. A stream cipher well suited to a silicon implementation is used with secret key lengths of up to 128 bits (selectable via 8-bit granularity). The authentication and privacy support are appropriate for the short-range nature of the radio, and applications requiring stalwart protection are encouraged to implement stronger security mechanisms.

Bluetooth Protocol Overview
Bluetooth specifications include protocols [4] and profiles [5]. Protocols specify the workings of an individual component (RFCOMM or L2CAP, for example), while the profiles specify how a set of protocols can be used for implementing a particular usage model. Profiles are important to have a common understanding of the protocol stack in order to promote interoperability of usage model implementations.

The Link Management Protocol (LMP), baseband, and radio are typically implemented in the Bluetooth hardware modules. These modules can interface to the host using different interfaces. However, all Bluetooth controllers should implement the Bluetooth Host Controller Interface (HCI).

The Logical Link Control and Adaptation Protocol (L2CAP) implements a second link-layer protocol to address protocol multiplexing, segmentation, and re-assembly. L2CAP hosts a set of client protocols. A couple of such protocols are the Service Discovery Protocol (SDP) and a serial cable emulation protocol called RFCOMM. Figure 1 summarizes the Bluetooth protocol stack.

Figure 1: Summary of Bluetooth protocol stack

The L2CAP is a core component of the stack that contributes to the overall throughput that can be achieved.

Figure 2: L2CAP and Baseband packet formats

The L2CAP supports both connection-oriented and connectionless packet formats as shown in Figure 2. The L2CAP packet becomes part of the baseband packet payload as indicated. The L2CAP supports segmentation and re-assembly, protocol multiplexing, group abstraction, and quality of service.

A more complete description of the protocols and profiles can be found in the Bluetooth specifications.

A Note on Implementation Target
The target operating systems are WDM operating systems. For Release 1.0 implementation of the architecture described here, we are targeting Windows* 98, Windows98SE and Windows2000. The primary hardware target is notebook computers with embedded Bluetooth USB [2] modules, although appropriate hardware could enable the software stack on desktops also.