The Bluetooth Protocol

Bluetooth connects devices wirelessly in ranges of 1 to 100 meters, depending on power. There are several versions of Bluetooth: 1.0, 1.1, 1.2, and 2.0. (The Java API for accessing a Bluetooth device is the same regardless of version.) Bluetooth 1.0, 1.1, and 1.2 devices can reach speeds of 723 kilobits per second. Version 2.0 accelerates this to 2.1 megabits per second. In other words, Bluetooth is fast enough for network devices, but not fast enough for disk drives and monitors.

Because Bluetooth is wireless, it is less secure than wired alternatives such as USB connections (which themselves aren as secure as is often thought). With the right equipment, its possible to sniff Bluetooth communications one isn meant to access. To prevent this, pairs of devices may require a shared secret passkey and may encrypt data passed back and forth between them. However, many devices don bother to do this.

Each Bluetooth controller can talk to up to seven different Bluetooth devices in a "master/slave" configuration. Among the eight devices, each device takes a turn at being the master while the other seven are slaves, in rotating order. The master is responsible for picking frequencies on which to communicate and deciding when to change them. The group of devices, one master and up to seven slaves, is called a piconet . In the future, it may be possible for piconets to be joined in larger scatternets . However, this is not yet possible.

Each Bluetooth device has a fixed 6-byte address, such as 00-13-c2-00-0d-23 or 00-0a-95-09-5a-59. Theoretically this address is unique, but conflicting addresses have shipped in real products. Each device also has a more human-friendly name, such as "elharos mouse" or "WACOM pen tablet." Users and manufacturers can change the names, and name conflicts are possible.

Every device also has a 3-byte class identifier that is divided into four parts, as shown in Figure 25-2:

• The first two bits are always 0.
• The next six bits are a little-endian int for the minor device class.
• The next five bits are a little-endian int for the major device class.
• The final 11 bits are flags identifying the type of the device. For instance, if bit 22 is 1, its a telephony device. If its 0, it isn .

The currently defined major device class codes are shown in Table 25-1. Note that the numbers given are as Java reports them. Bits 812 define the major class. However, rather than interpreting this as a 5-bit number, Java represents it as a 13-bit number in which the low-order eight bits are always 0. (If you prefer, you can think of this as a 32-bit number in which all bits except 812 are 0.)

Minor device class codes depend on the major code. For example, the peripherals class has the 10 minor device classes shown in Table 25-2. Although the minor device class code is logically a 6-bit number, Java represents it as a 1-byte number, the first two bits of which are always 0.

While each device has exactly one major class and exactly one minor class, a device may support multiple services. For instance, a combination cell phone/PDA might be both a telephony device and an object transfer device. Table 25-3 lists the service classes and their associated bit fields. Each service a device supports is indicated a by a single bit in the class identifier. Java reports this as a 24-bit number in which the first 13 bits are always 0.

For example, a GPS-enabled cell phone would have the major class 0x0200 and the minor class 0x04 and would support the positioning (0x10000) and telephony (0x400000) services. Therefore, its class ID would be 0x0200 | 0x04 | 0x10000 | 0x400000, or 0x410204.

Many devices support one or more standard profiles that offer particular types of services. These include the Serial Port Profile for streaming connections, the Basic Printing, Video Conferencing, File Transfer, Cordless Telephony, Fax, and Personal Area Network Profiles, and several dozen more.

Each profile communicates using a specified protocol. The lowest-level protocol is a packet-based protocol called the Logical Link Control and Adaptation Protocol (L2CAP). This is analogous to IP in the TCP stack. That is, other higher-level protocols are built on top of L2CAP and provide additional services. For instance, the RFCOMM protocol assembles L2CAP packets into input and output streams. If L2CAP is like IP, RFCOMM is like TCP. The Object Exchange (OBEX) protocol is a still higher-level protocol for exchanging binary data over RFCOMM. Stretching the analogy to the breaking point, if L2CAP is IP and RFCOMM is TCP, OBEX is HTTP. Different profiles and devices can plug into this stack wherever they find convenient, as shown in Figure 25-3. The Java Bluetooth API supports all three. There are also several additional protocols the Java Bluetooth API does not support, such as Bluetooth Network Encapsulation (BNEP) and the A/V Control Protocol.