The Bluetooth Protocol

Table of contents:

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 .

Figure 25-2. Bluetooth class identifier layout, in big-endian form as seen by Java

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.)

Other Bluetooth APIs in other languages can and do provide different representations of the bit patterns in the class identifier shown in Figure 25-2. For instance, the Apple System Profiler presents major device classes as numbers from 0 to 31 (5-bit unsigned ints) instead of numbers from 0 to 7936. The following tables are valid for the Java Bluetooth API. They may not be valid in other environments.

Table 25-1. Bluetooth major device classes
Decimal	Hexadecimal	Device type
0	0x0000	Miscellaneous devices
256	0x0100	Computers and PDAs
512	0x0200	Phones, including modems and faxes
768	0x0300	LAN adapters, routers, and network access points
1024	0x0400	Audio/video devices (headsets, speakers, televisions, DVRs, etc.)
1280	0x0500	Input peripherals (mice, joysticks, keyboards, graphics tablets, etc.)
1536	0x0600	Imaging devices (printers, scanners, cameras, monitors, etc.)
1792	0x0700	Wearable devices
2048	0x0800	Toys
7936	0x1F00	Uncategorized: anything for which the Bluetooth Special Interest Group (SIG) has not yet defined a standardized code (e.g., GPS locators or laboratory probes)

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.

Table 25-2. Bluetooth peripheral minor device classes
Decimal	Hexadecimal	Type
0	0x00	Uncategorized
4	0x04	Joystick
8	0x08	Gamepad
12	0x0C	Remote control
16	0x10	Sensing device
20	0x14	Digitizer tablet
24	0x18	Card reader
64	0x40	Keyboard
128	0x80	Pointing device (mouse, trackball, etc.)
192	0xC0	Keyboard/mouse combination (0x80 \| 0x40)

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.

Table 25-3. Bluetooth service classes
Bit	Decimal	Hexadecimal	Service class
13	8192	0x2000	Reserved
14	16384	0x4000	Reserved
15	32768	0x8000	Reserved
16	65536	0x10000	Positioning
17	131072	0x20000	Networking
18	262144	0x40000	Rendering
19	524288	0x80000	Capturing
20	1048576	0x100000	Object Transfer
21	2097152	0x200000	Audio
22	4194304	0x400000	Telephony
23	8388608	0x800000	Information

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.