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
|