Page 3 of 9

SUPPLYING THE MECHANISMS

Bluetooth wireless technology will not enable the above usage models by itself. It is simply one piece in the puzzle. In this section we describe the basic mechanisms supported by the technology.

Low Power
Designed for use in handheld battery-powered devices, Bluetooth radios have relatively low-power consumption in an active state and even lower consumption in a standby state. The Bluetooth specification does not specify power requirements, but manufacturers are advertising solutions with standby currents of less than 0.3 mA and active data currents no higher than 30 mA at voltages between 3 and 5 V for a maximum power drain of 0.15 W. A typical notebook Li-Ion battery packs 40 W hours of power. If the battery only had to power the radio, this converts into a notebook battery lifetime of 100+ hours of active radio use and months of standby time before the battery is exhausted. Therefore, the Bluetooth radio will not be a significant drain on notebook battery life compared to the rest of the system.

Discovery Mechanism
Bluetooth wireless technology uses an inquiry procedure to discover the addresses of all the devices in the vicinity. To be discovered, each device needs to enter an Inquiry Scan mode. To discover devices, a device must enter a probing state called Inquiry mode. In this mode, the device collects the remote clock, address, and Class of Device (COD) information from all units responding to the inquiry message. It can then, if desired, make a connection to any one of them by means of a paging procedure described in the next section.

In the Inquiry state, an inquiry access code message is broadcast by the source. The inquiring device alternatively transmits this message and listens for responses over a 10.24 second period. During this time, it can do little else besides probe the environment and listen for responses. The device listening for inquiry messages has a much simpler task: it listens for only 10.625 ms every 2.56 seconds. In addition to having different scanning times, each responding device uses a random delay before sending the response in order to avoid collisions with responses from other devices. A device typically sends multiple responses (due to receiving multiple messages) during the discovery process, usually on different frequencies, thus yielding a robust discovery mechanism.

The inquiry access code does not contain any information about the source, but does indicate the devices that should respond. There are 64 reserved inquiry access codes and only two are currently defined in the Bluetooth Specification [1]. The first, Generic Inquiry Access Code (GIAC), requires that all discoverable devices must respond . In a dense environment like a conference, airport terminal, or classroom there may be many devices that are discoverable. The Limited Inquiry Access Code (LIAC) was created to support the limited discovery mode. The objective of the limited discovery mode is to create a user-initiated situation that limits the number of devices discovered. Devices operating in this mode must respond to messages containing the LIAC. By definition, devices must not enter limited discovery mode for more than a minute before they are forced to leave it. Devices in discoverable mode must not respond to LIAC messages. For more details on the Inquiry process consult [1,2].

Connection Mechanism
The connection mechanism is referred to as "paging." The device initiating a connection enters the Page mode. The initiator needs only the 48-bit Bluetooth device address of the target to set up a connection. During paging, the initiator alternatively transmits the target's Device Access Code (DAC) and listens for responses over one set (out of a possible two) of hop frequencies. If no response is detected within 1.28 seconds, the second set of hop frequencies is used. A good estimate of the target's internal clock will accelerate the paging procedure by selecting the correct set of initial frequencies to use. Paging is a very active process, and the initiating radio has little time for anything else while operating in this mode.

To hear paging messages, a device must enter a Page Scan mode. In this mode, the device listens to a single hop frequency band for 11.25 ms every 1.28-second interval, switching to another frequency in a pre-defined sequence during the next interval. Outside this 11.25 ms scan window, the radio may communicate with other radios or enter a power-saving standby state.

For the paging process, several paging schemes can be applied. This section only describes the mandatory paging scheme that has to be supported by each Bluetooth device. For further information on this and alternative paging schemes, consult the Bluetooth Specification [1].

Authentication Mechanism
While untethered access is one of the strengths of wireless technology, it is also a weakness: connectivity to the notebook is no longer restricted to physical access. This becomes a problem when supporting proximity-based computing because battery power is limited. While the notebook operating system may provide protection mechanisms, the involvement of the operating system in proximity-based computing consumes a significant amount of power. This is because the majority of the system, barring the LCD display, needs to migrate to an S0 state (full on). Moreover, involving the operating system in security checks may expose the computer to power drain attacks. If the radio module itself were to filter out undesirable connection requests, then this could be a solution to these power drains.

The Bluetooth Link Manager Protocol (LMP) supports both one-way and two-way authentication by using a challenge-response scheme based on shared secret keys. One-way authentication means that one device authenticates the other by sending a random number and receiving the proper response. Two-way authentication means that both devices authenticate each other. In order to filter wake-up events, it is important for the Bluetooth device to support authentication; not all Bluetooth devices are required to support this feature.

The secret keys are established through a process called "pairing." Pairing starts when there is an assumption of a known shared secret, such as an agreed upon Personal Identification Number (PIN). During the pairing process, devices may prompt users to enter a PIN. If the PIN entered on both devices match, a shared secret key, called a link key, is created for those two devices.

Using the Host Controller Interface described later, incoming connections may automatically trigger link authentication before they are accepted. This allows the radio module to prevent unauthenticated connections requests from waking a "sleeping" computer as described in a later section.

Privacy Mechanism
In addition to the need for authentication, wireless communication also raises concerns about privacy. The communication between the devices should be protected from casual eavesdropping in the same way that a cable provides physical security. To protect the privacy of the communication medium, the Baseband protocol implements a stream cipher using an encryption algorithm called E0.

Bluetooth privacy mechanisms are targeted at protecting privacy but are limited by global encryption regulations. For corporate confidential communication, an application-based end-to-end security mechanism should be used.

Wakeup
Because battery life is so important, the PC industry has defined a variety of low-power modes in the Advanced Configuration and Power-management Interface (ACPI) specification [3]. Table 1 describes the ACPI sleeping states. To enable proximity-based, unconscious application-level activity while preserving battery life, the PC must migrate from "sleeping" states to a "working" state, and back again to a sleeping state.

The PC may be woken up through an interrupt, and ACPI uses the System Control Interrupt (SCI). Any Bluetooth radio module connecting to the PC uses an SCI to wake the PC from a sleeping state.

Table 1: ACPI states

To allow intelligent "wake-up" policies, the Bluetooth Host Controller Interface (HCI) allows the host PC to define various "filters". Part of the Bluetooth Specification, the HCI, defines a set of commands that must be supported across all radio devices that claim conformance to the HCI. The HCI Set_Event_Mask command may be used to define which events wake up the host. Table 2 provides some sample events. See the HCI chapter within the Bluetooth Specification for a complete list of events available for this command.

Table 2: Sample HCI events

The HCI Set_Event_Filter command may be used to further refine the events allowed to wake up the host. For the Inquiry Result event, filters may be used to specifically allow only responses from certain classes of devices, e.g., data access points, to wake up the host, while ignoring all other responses.