12.4 Bluetooth Protocol

The Bluetooth protocol architecture is shown along with the OSI model in Figure 12-3. The radio and baseband functions are mapped to the physical layer on the OSI model. The data link layer of OSI translates to several layers on a Bluetooth stack due to varied capabilities and applications it can support. From an IP stack point of view, the TCP/IP layer in the Bluetooth protocol provides the network, transport, and session layer functions. The following sections describe the functionality of each of those layers .

Figure 12-3. Bluetooth system protocol stack.

12.4.1 Bluetooth Radio

The physical layer of the protocol stack defines the radio characteristics of the Bluetooth wireless technology. The Bluetooth radio uses FHSS (frequency hopping spread spectrum), which divides the frequency spectrum into equal number of 1 MHz channels (2.402-2.480 GHz, yielding 79 channels). The radio transceivers hop from one channel to another channel at a rate of 1600 per second in a pseudorandom fashion as determined by a master device. The FHSS technique offers robust communications with less interference and higher security against eavesdropping.

The modulation technique is a binary Gaussian frequency shift keying (GFSK) at a symbol rate of 1 Mbps. Three different power classes are defined depending on the transmit power. Class 1 radios have transmitting power of 20 dBm (100 mW); class 2 radios have transmitting power of 4 dBm (2.5 mW); class 3 radios have transmitting power of less than 1 dBm (1 mW).

12.4.2 Baseband

Each Bluetooth device has two parameters that are involved in practically all aspects of Bluetooth communications. The first one is a unique IEEE 802-type 48-bit address assigned to each Bluetooth device at manufacture time, much like the MAC address for Ethernet devices. The second parameter is a free-running 28-bit clock that ticks once every 312.5 m s, which corresponds to half the residence time on a frequency hop at a nominal rate of 1600 hops per second.

12.4.3 Piconet and Scatternet

A piconet is a collection of devices connected with Bluetooth radio in an ad hoc manner. One of the participating Bluetooth devices that initiates the connection acts as a master, and the other devices in the formation act as slaves for the duration of the piconet connection. Each master can actively communicate with up to 7 simultaneous slaves or over 200 inactive or parked slaves in a piconet. The parked slaves are registered with the master but not currently active in communication, but can become active as necessary. For this reason, the span of piconet is limited to the distance reachable by the master device. Devices within the range of the master that are not part of any piconet are in the stand-by mode.

The standard does not specify how the master is determined. Devices in communications can determine who is the master by inquiry/paging messaging. Usually, the master is a paging device in a centralized system like a PC or a laptop. The master controls the communications in the piconet by deciding who transmits and when. Each node can participate in more than one piconet with different behavior, master or slave, in each piconet. The roles of master and slave can be exchanged at any time within a piconet while the piconet is active. Figure 12-4 shows two piconets and the different roles of the Bluetooth devices.

Figure 12-4. Piconet and scatternets.

12.4.4 Physical Channels and Links

The channel is represented by a pseudo-random hopping sequence hopping through one of the 79 radio channels. In a piconet, the master device always sets the clock and the hop pattern or a sequence. Each piconet has a unique hopping sequence. The phase in the hopping sequence is determined by the clock of the master. The channel is divided into time slots, where each slot corresponds to an RF hop frequency. Consecutive hops correspond to different RF hop frequencies. All Bluetooth devices in a piconet are time- and hopsynchronized to the channel.

Each time slot in the channel is of 625 m s in length. The slots are numbered as per the clock of the master ranging from 0 to 2 ²⁷ -1 and is cyclic. In the time slots, the master and slaves can transmit packets. The master shall start transmission in the even-numbered packets only, while the slaves shall transmit in odd-numbered slots only. The packets can be extended up to five time slots.

The master and slave(s) establish one of the SCO or the ACL links between them. SCO links are used for point-to-point connections between master and single slave in a piconet, while the ACL link is used as point-to-multipoint link between master and all the slaves in the piconet. Piconets can form scatternets. A scatternet is the linking of multiple co-located piconets through the sharing of common slave or master devices.

12.4.5 Addressing

The Bluetooth device address (BD_ADDR) is engraved and cannot be modified. It is divided into three fields as shown in Figure 12-5.

Figure 12-5. Bluetooth device address.

• LAP field: Lower address part consisting of 24 bits

• UAP field: Upper address part consisting of 8 bits

• NAP field: Nonsignificant address part consisting of 16 bits

The total address space obtained is 2 ³² corresponding to the LAP and UAP fields.

Bluetooth devices can communicate with each other by acquiring each other's addresses and clocks.

12.4.6 Packet Format

The bit ordering when defining the packets and messages over the Bluetooth air interface follows the Little-Endian format. Each packet consists of three entities ”the access code, the header, and the payload. Except for the payload, the other two parts are of fixed sizes, 72 and 54 bits, respectively (Figure 12-6).

Figure 12-6. Standard packet format.

The access code identifies all packets exchanged within a piconet. The access code is also used in paging and inquiry procedures, in which case the header and payload are not required in the message. Accordingly , three different kinds of access codes are defined.

• Channel access code (CAC) ” identifies the piconet

• Device access code (DAC) ” for paging requests and responses

• Inquiry access code (IAC) ” to discover Bluetooth units in range

The packet header contains link control information with six fields that includes member address, type code, flow control, acknowledge indication, sequence number, and header error check.

The total header, including the header error check field, consists of 18 bits and is encoded with a rate 1/3 forward error correction (FEC) resulting in a 54-bit header. The payload formats are distinguished as the (synchronous) voice field and the (asynchronous) data field. The ACL packets only have data fields, while the SCO packets have only the voice field.

12.4.7 Packet Types

Twelve different packet types, indicated by a 4-bit TYPE code, are defined for the two types of links: the SCO link and the ACL link. They are subgrouped into four segments. The first segment is reserved for four control packets and will be common to both the link types, and the TYPE code for these control packets is unique irrespective of the link type. The second segment is reserved for packets occupying the single time slot. The third segment is reserved for packets occupying three time slots, and the fourth segment represents packets that occupy five time slots.

12.4.8 Error Correction

Bluetooth defined three different error correction schemes.

• 1/3 rate FEC : bit-repeat code (repeated 3 times)

• 2/3 rate FEC : shortened Hamming code, corrects double bit errors and can correct single bit errors

• ARQ scheme : 1-bit fast ACK/NACK scheme using a 1-bit sequence number with header piggybacking

The packet headers contain valuable link information and should be able to sustain more bit errors; therefore, they are protected by the 1/3 FEC. However, in a reasonably error-free environment, FEC is optional as it adds unnecessary overhead, reducing throughput.

12.4.9 Logical Channels

Five logical channels are defined in the Bluetooth system:

• LC control channel

• LM control channel

• UA user channel

• UI user channel

• US user channel

The control channels LC and LM are used at the link control level and link manager level, respectively. The user channels UA, UI, and US are used to carry asynchronous, isochronous, and synchronous user information, respectively. Except for LC channels, which are carried in the packet headers, all other types are indicated in a header field and carried in the payload. The US channel is carried by SCO link only; and the UA and UI channels are normally carried by the ACL link with the exception of the DV packet, which can be carried on the SCO link. The LM channel can be carried by either of the link types.

12.4.10 Link Controller State Machine

Figure 12-7 shows the state diagram of the link controller. There are two major states STANDBY and CONNECTION. The other states are sub-states that define device link status whenever a new slave is added to the piconet. State transitions are triggered either due to link manager commands or due to internal event signals.

Figure 12-7. Bluetooth link controller state machine.

STANDBY state is the low-power default state in the device. The device initiates or responds to other devices' page and inquiry requests. It can transition to the CONNECTION mode if a suitable link is determined. The device acts as a master when it initiates a page scan request to other devices.

12.4.11 Link Manager Protocol

Link Manager Protocol (LMP) messages are exchanged at the link manager level and used for link setup between Bluetooth devices. They provide control and negotiation of packet size when transmitting data. LMP also provides power control and management, addressing, connection mode handling, and master-slave switching of link configuration and link states in a piconet. It also offers security functions, including exchange of encryption keys between devices for authentication and encryption. The LMP messages have higher priority than the user data. The link controller in the baseband offers a reliable link and, therefore, the LMP protocol can work without explicit acknowledgments.

12.4.12 Host Control Interface

The host control interface (HCI) is not part of the protocol stack, but it provides a uniform interface method of accessing the Bluetooth hardware capabilities. The HCI firmware implements the HCI commands for the Bluetooth hardware by accessing Baseband commands, link manager commands, hardware status registers, control registers, and event registers.

12.4.13 Logical Link Control and Adaptation Protocol

The logical link control and adaptation protocol, L2CAP, is one of the two link-level protocols layered over the baseband protocol. It provides connection-oriented and connectionless data services to the upper protocol layers with protocol multiplexing capability, segmentation, and reassembly operation, conveying quality of service information and group abstractions.

Defining channels where one or more channels are bound to a single protocol in a many-to-one fashion supports protocol multiplexing. But one channel cannot be bound to multiple protocols. The channel number is used to identify the appropriate higher-level protocol and all L2CAP packets are delivered accordingly. L2CAP supports large packets up to 64 kB by the use of segmentation and reassembly operations. This function reduces overhead and improves efficiency by supporting MTU sizes larger than the largest baseband packet.

Group abstraction management allows efficient management between groups and members of the Bluetooth piconet. L2CAP exchanges QoS information across channels and performs some admission control to prevent additional channels from violating the existing QoS contracts.

12.4.14 Service Discovery Protocol

The Service Discovery Protocol (SDP) is a client/server protocol that addresses service discovery specifically for the Bluetooth environment. It provides a means for client applications to discover the available server services and also the characteristics of those services within the Bluetooth range. Each Bluetooth device can at most run one SDP server to manage services information and handle client requests. An SDP entity can act as both a server and a client. The characteristics or the attributes of the service are stored as a service record for each service that includes the service name , description, class of service or identifier, and protocol information to utilize the service. The service records are populated based on a standardized hierarchy for easy browsing.

The availability of the services is dependent on the RF proximity of the devices offering the services. For client devices seeking specific services, SDP provides search and browse functions based on some desired characteristics of the services. The protocol is designed to have a simple flow control by limiting not more than one unacknowledged request at any time.

12.4.15 RFCOMM

RFCOMM is a simple transport protocol that provides emulation of COM ports to support RS232 serial communications over the L2CAP protocol. The RFCOMM protocol is mostly based on the ETSI standard TS 07.10, but the Bluetooth SIG further specified some adaptations and specific extensions. Some of these adaptations include media adaptations, multiplexer start-up and close-down procedures, multiplexer control commands and system parameters, and flow control. RFCOMM supports up to 60 simultaneous connections between two Bluetooth devices. It is intended to cover applications that make use of serial ports of the devices in which they reside.

12.4.16 Telephony Control Protocol Specification

The Bluetooth Telephony Control protocol Specification (TCS) is based on ITU-T Recommendation Q.931. The TCS contains the following functionality:

• Call control (CC) ” signaling for the establishment and release of speech and data calls between Bluetooth devices

• Group management ” signaling to ease the handling of groups of Bluetooth devices

• Connectionless TCS (CL) ” provisions to exchange signaling information not related to an ongoing call

TCS may use either point-to-point signaling or point-to-multipoint signaling. Point-to-point signaling is mapped toward a connection-oriented L2CAP channel, whereas point-to-multipoint signaling is mapped toward the connectionless L2CAP channel, which in turn is sent as broadcast information on the piconet broadcast channel.

In addition to the aforementioned basic functionality, TCS also provides support for supplementary services like calling line identity, DTMF tones (if carried by the external network), and register recall.

12.4.17 OBEX

OBEX is an optional application-layer protocol designed to enable devices to exchange data and commands in a resource-sensitive standardized fashion. OBEX uses the client/server model and user RFCOMM as the main transport layer.