Bluetooth Specification

Bluetooth Technology Overview 

This page provides a brief overview of the Bluetooth wireless specification, 
introducing some terms and pointers to more detailed information.

Other relevant pages:
What is Bluetooth ?  An introduction to its origins
Bluetooth White Papers - available from a variety of companies active in the field
Bluetooth Glossary - a page of strange acronyms and technical terms
Books - books describing the detailed technology  

For a more detailed description of the technology, please take a look at this excellent article on the Bluetooth Architecture by Jim Kardach of Intel, a senior member of the Bluetooth SIG.  Pdf version.   

Bluetooth Specification
The Bluetooth wireless specification includes radio frequency,  link layer and application layer definitions for product developers for data, voice and content-centric applications. The specification documentation contains the information necessary to ensure that diverse devices supporting the Bluetooth wireless technology can communicate with each other worldwide. 

The document is divided into two sections: 
i)  Core Specification (Volume I) - which defines the base technology - and 
ii) Profile Definitions (Volume II) - which defines specific usage of the base technology to support specific applications whilst ensuring interoperability between products developed by different manufacturers. 

Full copies of the specifications may be downloaded from the Bluetooth SIG website 

Physical Layer Details
Radio frequency - Bluetooth uses the unlicensed ISM (Industrial, Scientific and Medical) band, 2400 - 2483.5 MHz, thereby maximising communication compatibility worldwide.  This requirement for global usage was the key driver for this choice of spectrum.

Modulation -  uses Gaussian frequency shift keying, GFSK, with modulation index (bandwidth-time product, BT) limited to 0.28-0.35 (corresponding to a max frequency deviation of 140-175 kHz).  

Frequency Hopping Spread Spectrum - Bluetooth adopts the use of FHSS to hop at up to 1600 hops/sec, amongst 79 channels, spaced at 1 MHz separation.

Transmission Power - Three power classes are supported by the standard.  In practice almost all Bluetooth devices developed to date support only one of these options, most being the low power, short range, option.
Class 3    -    1 mW         (0dBm)         with a 'typical range' of 10m
Class 2    -    2.5 mW      (4dBm)         with a 'typical range' of 20m
Class 1    -    100 mW    (20dBm)        with a 'typical range' of 100m

Link data rate -  a maximum link baseband data rate of 723.2 kb/s is supported, with options for  1/3 bit repetition and 2/3 Hamming FEC (Forward Error Correction).

Speech coding - CVSD - 64kb/s Continuously Variable Slope Delta Modulation.  CVSD supports acceptable speech quality even with 1-3% bit error rate, BER. 

Protocol Specifications
The Bluetooth protocol stack, in common with all such standards, is specified as several separate layers.  By their very nature, communication protocols do not lend themselves to brief summaries, so here we will simply explain the structure of the protocol stack and its basic functionality - each part is described in detail in the relevant chapter of the core specification.

The lowest level of the protocol stack is the physical layer, summarised above, which serves to implement the physical communications interface, including RF aspects such as the modulation.  Much of this may be typically implemented in a single RF integrated circuit, such as may be found here.

Above the physical layer sits the baseband layer, again typically implemented as a single integrated circuit, see here for example devices.  The baseband layer essentially implements the timing, sequence and order of transmission of physical bits across the wireless bit-pipe from one Bluetooth device to another, including channel coding.  Some manufacturers have now implemented true single-chip Bluetooth devices, which implement both RF and baseband functionaility into a single package.

The Link Manager (LM or LMP) is the next layer, which manages the behaviour of the wireless link on a realtime basis, controlling the baseband device and serving to allow service discovery and thereby to establish communication between two Bluetooth devices as they come in communication range of each other.  

The upper part of the Link Manager, together with the next layer, the the HCI, or Host Controller Interface, is responsible for the data transport mechanisms, once the link is established, multiplexing the data as required by the relevant application.  The Link Manager and HCI Layers are essentially written as software, but often embodied as embedded firmware, to secure a lower power and simpler implementation.

L2CAP, the Logical Link Control and Adaptation Protocol, sits above the HCI layer and provides data flow control and management.

Above L2CAP the stack splits, with the link to the Applications Layer going via the SDP (Service Discovery Protocol ) or TCS (Telephony Control protocol  Specification) blocks, or via RFCOMM and then via OBEX  (Generalised Multi-Transport Object Exchange Protocol) , WAP (Wireless Application Protocol) or simple AT Commands.

Protocol stack software is available from multiple vendors to implement the various layers of the Bluetooth protocol stack.
In addition, a variety of additional application layer software, security software and other such functionality is also becoming increasingly available - see our Software Index Page.

Voice and Data Transmission Capabilities
Bluetooth multiplexes different link or packet types designed to be optimum for either voice or data using two types of link protocol - ACL and SCO.

ACL  - The Asynchronous Connectionless Link allows bits to be transmitted on a per available slot basis

SCO  - the Synchronous Connection Oriented link provides guaranteed time- bounded communoication for time-sensitive services such as voice.

Intercommunicating Devices - Piconets & Scatternets
A Bluetooth enabled device, by virtue of the complexity of the communication protocols, needs to operate either as a slave or as a master if it is to communicate with other such devices.  This enables the slave to acquire time and frequency synchronisation from the master device.   Multiple Bluetooth devices may intercommunicate within a given geographic location (forming a so-called 'piconet'), with their timeslots controlled on a a time division multiplexing basis by the master device and all following the frequency hopping pattern of the master.  The resource allocation is determined by the master, but may dynamically reflect the data transfer requirements requested by the individual devices.  In a piconet communication links only exist between a slave and the master - no direct links exist between slaves.  The specification limits the number of slaves in a piconet to seven.

Because of the time-division nature of the resource sharing it is possible for a Bluetooth device to simultaneously participate in multiple piconets.  Such a device may be a master of one piconet and slave in another, or a slave in both; it cannot be a master in both, or by definition the two piconets would be a single piconet.  Such interaction of multiple piconets is referred to as a scatternet.  Clearly in scatternet scenarios, since two or more masters exist, a degree of mutual interference between the piconets can occur.

Interoperability - Profiles 
The second volume of the specification essentially comprises a collection of so-called 'profiles', which detail how the base (core) specification should be used to construct specific applications.  The purpose of this is to avoid different manufacturers interpreting and using the core specifications in different ways to implement the same task.  If this were to happen devices from different manufacturers would fail to interwork, giving Bluetooth a bad name with the end user.  (The concept of profiles is familiar within the DECT community, where the advent of the Generic Access Profile, for example, allows different manufacturers' phones to work with others' basestations).

Interoperability - Specification Versions - v1.0, 1.0b and 1.1
By July 1999, version 1.0 of the Bluetooth specification had been completed and published with the goal of providing a worldwide standard for the use of Bluetooth technology, enabling full interoperability between Bluetooth enabled devices.  However, as with any complex technical specification, as manufacturers began to implement the technology certain parts of the specification were interpreted by some in a "slightly different" manner to others.  These areas of ambiguity which had been inherent in the specification began to emerge at the early UnPlug Fests, events organised by the Bluetooth SIG to ensure interoperability.  

By December 2000 these areas of uncertainty had been collated and resolved in the version 1.0b specification, which also incorporated optional states or modes to allow selective functionality to be scaled down or turned off in order to save power when not needed.   After allowing time for such changes to bed down and any final wrinkles to emerge and be resolved, the Bluetooth version 1.1 specification emerged formally and finally .22nd February 2001  

To its credit the industry bit the bullet and chose the path of prioritising interoperability over time to market.  Whilst this resulted in some pundits complaining over the delays and questioning whether Bluretooth would ever arrive it had meant that interoperability has not been sacrificed - something which could have been fatal for consumer acceptance. 

Where Next ?
If you've reached this far and are keen on reading more technical detail, then maybe it's time to read a book rather than a webpage !  You can check out the latest books on Bluetooth, which to date are mainly technical ones, on our Bluetooth Books Page or check out the other pages listed back at the top of this page