Bluetooth Protocol StackDavid Mackie

Version 110 May 2004

Bluetooth Protocol Stack

David Mackie

10 May 2004

Introduction

This paper sets out to discuss Bluetooth’s Protocol stack and architecture, how the different layers communicate with each other, what type of messages are passed and what type of API hocks there are for an outside user.

Bluetooth is a specification for a low-cost, low-power, short-range wireless communication technology that provides wireless connectivity between mobile devices such as cellphones, personal digital assistants (PDA) and portable computers. Not only can it be used as a cable replacement on point-to-point bases but can also form ad hoc networks in a master-slave formation called Piconets, allowing users to create Personal Area Networks (PAN) between devices.

Bluetooth Special Interest Group (SIG)

The Bluetooth SIG is a trade association of over 2000 different companies comprised of the leaders in the telecommunication, networking and computing industries that are driving the development of Bluetooth. Founded by as Ericsson, IBM, Intel, Nokia and Toshiba in February 1998 and later joined by Microsoft, Lucent, Motorola and 3Com in December 1999, they are now called SIG Promoters and are responsible for the SIG administration such as legal, marketing and qualification process. Right in the beginning Bluetooth was envisioned as a worldwide communication system and this has some bearing on the large amount of detail there is in the specification documents (now over 1200 pages for just core architecture) and how not only the bottom layers of the stack (physical and Data Link) where exactly defined but higher levels where also defined in much detail as to prevent inconsistencies when taken to market.

Bluetooth Protocol Stack

The Bluetooth core system as described in specification version 1.2 consists of the four lowest layers and associated protocols, the Service Discovery Protocol (SDP) and the overall profile requirement specified in the Genetic Access Profile (GAP). The lowest three are normally grouped into a subsystem called the Bluetooth controller, but more commonly known as a Bluetooth module or dongle. Communication between the module and the host computer is done through the Host Controller Interface (HCI) which is usually done across a wired-bus such as USB or PCMCIA (PC card). The HCI is not a layer but forms the hardware abstraction layer between firmware on modules and software on host computer and exposes the services of the module to the higher layers.

A simplified version of the Bluetooth protocol stack is shown in Figure 1 and is broken down in the next section.

Overview of the Protocol Stack

The lowest layer is of course the Radio which provides the transmitter and receiver for two-way communication within the 2.4 GHz RF band. Packets are assembled and fed to the radio by the Baseband, which is a simple state machine. More complex operations are provided by the Link Controller. TheLink Manager is responsible for the creating and managing logical links between Bluetooth devices. This is done by communicating with remote Bluetooth devices using the Link Management Protocol (LMP). The Logical Link Control and Adaptation Protocol (L2CAP) takes application data and breaks it into Bluetooth sized chunks. It manages the virtual channels between hosts and keeps track of simultaneous communications.

Figure 1: The Bluetooth Protocol Stack

The other protocols depicted in Figure 1 are not part of the core specification but are used by various profiles and programs to offer their services. Radio Frequency Communications (RFCOMM) is a serial port emulator and is used to fool higher protocols into thinking that a wired serial port exists between two devices and can be used with PPP to offerIP services. Service Discovery Protocol (SDP) and Object Exchange (OBEX) protocol are also higher protocols.

Voice and Control communication is handled differently then the above data communications. To prevent unacceptable delays digitised voice data is passed directly from application to the Baseband and bypass the rest of the stack. Control of the module also bypasses the stack and communicates directly with the Link Manager. These two types of communication could prove problematic for the project at hand and will be discussed later.

Radio

I am not going into much detail on how the information is placed onto the radio RF carrier except for the areas where there issues with the project.

Bluetooth operates in the 2.4GHz ISM[1] RF band. Since this band is shared with other Wireless devices such as other Bluetooth devices & WLAN, cordless phones there is a high probability of interferences from numerous devices, even microwave ovens can cause interference. Rather then pick a particular channel for Bluetooth devices to communicate with each other, Frequency Hop Spread Spectrum (FHSS) as an interference avoiding technique. Instead of only using a single carrier frequency the synthesizer uses a “hop code generator” that changes the carrier frequency at a rate of 1600Hz. One Bluetooth packets is sent per hop usually.

The hop pattern is pseudo randomly generated but is duplicated on both sending and receiving devices. Thus the transmitter and the receiver hop together in sync and if they come across a channel with destructive interference, they will both hop onto the next one as it was pre-planned. This hop sequence is dependent on who initiates the communication first, called the Master device.

Baseband

Bluetooth sends information in packet format, but unlike IP[2] where packets are routed from node to node from source to destination, Bluetooth packets are sent directly from their source to their destination. Each packet is transmitted in a new hop frequency.

The Baseband layer performs a number of low level tasks such as:

  • Packet transmission
  • Assembling data packets from higher layers for radio to transmit
  • Decoding received packets from radio and passing them up to higher layers
  • Error control
  • Basic Piconet management
  • Piconet Timing
  • Frequency hop selection

Baseband packets have the format of access code, header, and payload as shown in Figure 2. The access code (72 bits) has initial synchronisation data and Piconet identity or recipients address depending on context. The header (54 bits) includes destination address, type of payload to follow and some error control information. Finally the payload (0 – 2745 bits) is a variable length field that contains the information. Little Endian transmission order is used so the least significant bit (LSB) is always sent first.

Figure 2: Bluetooth Baseband Packet Structure

Time Division Duplexing (TDD)

One of the most important decisions that need to be made in a two-way communication system is when and how each device is going to talk to each other since no two devices can both transmit at the same time on the same frequency without interfering with each other. To offer full-duplex transmission and receiving must happen on different frequencies and is called frequency division duplexing (FDD). FDD increases costs and complexity because of the need for independently operated aerials and frequency synthesizers.

TDD is a much cheaper half-duplex solution. Disjoin slots of time are assigned to each transmitter such that devices take turns sending data to each other. A nominal switching rate of 1600 packets per second is used. The Master always transmits in even-numbers time slots. A slave that was addressed in that time slot can reply in the next (odd-numbered) time slot.

[More information and diagrams on how packets are transmitted and received can be given here. Morrow has lovely diagramsdemonstrating this. (p141-143)]

Physical Links

Two different types of links can be established between Bluetooth devices: Asynchronous Connectionless (ACL) links which are used for data communication where high data integrity is needed; And Synchronous Connection-Orientated (SCO) links which are used for real-time voice and low latency is primary.

Link Controller (LC)

There are a number of issues that have to be addressed for two Bluetooth devices are able to start communicating with each other. First of all, how do devices find other devices in the vicinity and secondly how do they align their hopping sequence so to continue communicating.The way that devices locate each other is done through a process of inquiry and pageand is performed before a Piconet can be formed. A prospective master will first try to find out what devices are within range (inquire) and then will initiate communication with a particular device (page). An abbreviated 32-hop sequence is used for the transmission of the request and a corresponding 32-hop sequence is used for the response.

[I have left out specific details on how these page and inquiries are done as I feel that I will need to be working at a higher layer – well I hope I will as all the fast hop-jumping would make it difficult to manage manually]

Link Manager (LM) Layer

The LM acts as a contact between the application and the LC and also communicates with the LM on the remote device using the Link Manager Protocol (LMP). Though LM on different devices are communicating with each other their messages are of course passed though the Baseband and RF. They start communicate once a page is successfully completed and exchange massages between each other without any host intervention probing for communication characteristics of the other LM’s. The host is then notified that a connection is being attempted and if accepted the LM’s then set up the connection configuration such as encryption. Once this is done they then open up the link to allows user data. The LM still listen LPM messages and act on them when intercepted.

Logical Link Control and Adaptation Protocol (L2CAP)

[This area needs much more investigation, my initial thoughts for the project was that I would be developing in a lower layers but readings now on the Baseband layer have shown me that there is to much of timing nightmare to be ‘messing’ about there.]

Bibliography

Morrow, R. (2002)Bluetooth Operation and Use

Gratton, D. (2003)Bluetooth Profiles: The Definitive Guide

Bluetooth SIG (2003)Specification of the Bluetooth System Version 1.2 & 1.1

[Thinks that I have come across and need to sort out

  • Voice by passes the whole stack, and I doubt such things would be handled by the latency of IP network, maybe limit to just PAN and such Profiles and leave out Handsets profiles
  • Baseband expectsback an ACK’s in the next time slot, this is way to short to transport it across IP network and get ACK from the other side. Repeaters would need to accept a packet on behalf of other device, but it can’t guarantee delivery (device disappearing on far side)

]

1

[1]Industrial, Science, Medical

[2] Internet Protocol