This page provides a brief overview of the Bluetooth
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
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
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
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
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
(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
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
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
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
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