Bluetooth1 is an always-on, short-range radio hookup that resides on a microchip.

It was initially developed by Swedish mobile-phone makl r Ericsson in 1994 as a

way to let laptop computers make calls over a mobile ph ne. Since then, several
thousand companies have signed on to make BluetootJ the low-power shortrange
wireless standard for a wide range of devices. The ] luetooth standards are
published by an industry consortium known as the Blueto( th SIG (special interest
group). This chapter provides an overview.
Following the discussion of Bluetooth, the chapter co ers IEEE 802.15, which
is concerned with personal area networks (PANs). PANs are local networks in
which all of the devices are controlled by a single user 0 a family. IEEE 802.15
covers Bluetooth plus two other PAN standards, knowr as IEEE 802.15.3 and
IEEE 802.15.4.
The concept behind Bluetooth is to provide a universal sho t-range wireless capability.
Using the 2.4-GHz band, available globally for unlicer sed low-power uses, two
Bluetooth devices within 10 m of each other can share ur to 720 kbps of capacity.
Bluetooth is intended to support an open-ended list of af lications, including data
(e.g., schedules and telephone numbers), audio, graphics, ane even video. For example,
audio devices can include headsets, cordless and standard I hones, home stereos, and
digital MP3 players. The following are examples of some 0: the capability Bluetooth
can provide consumers:
e Make calls from a wireless headset connected remotl ly to a cell phone.
e Eliminate cables linking computers to printers, keybl ards, and the mouse.
'0 Hook up MP3 players wirelessly to other machines t download music.

'0 Set up home networks so that a couch potato can rel otely monitor air conditioning,

the oven, and childrens' Internet surfing.

e Call home from a remote location to turn appliances on and off, set the alarm,
and monitor activity.
Bluetooth Applications
Bluetooth is designed to operate in an environment of many users. Up to eight
devices can communicate in a small network called a piconet. Ten of these
piconets can coexist in the same coverage range of the Bluetooth radio. To provide
security, each link is encoded and protected ag; inst eavesdropping and
interference.
lThe name comes from King Harald Blaatand (Bluetooth) of Denmarl , who lived in the tenth century
A.D. Unlike his Viking counterparts, King Harald had dark hair (thus he name Bluetooth, meaning a
dark complexion) and is credited with bringing Christianity to Scandia ia along with uniting Denmark
and Norway. The blue logo that identifies Bluetooth-enabled devict s is derived from the runes of
his initials.
5.1 / 0\ ERVIEW 465
Bluetooth provides support for three general application are~s using shortrange
wireless connectivity:
w Data and voice access points: Bluetooth facilitates real-time voice and data
transmissions
by providing effortless wireless connection of portable and stationary
communications devices.
.. Cable replacement: Bluetooth eliminates the need for numerol s, often proprietary,
cable attachments for connection of practically any kind of ~ommunication
device. Connections are instant and are maintained even when ~evices are not
within line of sight. The range of each radio is approximately 1Dm but can be
extended to 100 m with an optional amplifier.
• Ad hoc networking: A device equipped with a Bluetoc~th radio can
establish instant connection to another Bluetooth radio as so~:m as it comes
into range.
Table 15.1 gives some examples of Bluetooth uses.
Table 15.1 Bluetooth User Scenarios [HAAR98]
Three-in-one phone
When you are in the office, your phone
functions as an intercom (no telephony
charge). At home, it functions as a cordless
phone (fixed-line charge). When you are on the
move, it functions as a mobile phone (cellular
charge).
Internet bridge
Use your portable PC to surf the Internet
anywhere, whether you are connected
wirelessly through a mobile phone (cellular) or
through a wired connection (PSTN, ISDN,
LAN,.xDSL).
Interactive conference
In meetirigs and at coriferences, you can share
iriformation iristantly with other participants.
You can also operate a projector remotely
without wire connectors.
The ultimate headset
Connect a headset to your mobile PC or to any
wired connection and free your hands for more
important tasks at the office or in yourcar.
Portable PC speakerphone
Connect cordless headsets to your portable PC,
and use it as a speaker phone regardless of
whether you are in the office, your car, or at
home.
Briefcase e-mail
Access e-mail while your portat Ie PC is still in
the briefcase. When your PC rec~ives an e-mail
message, you are notified by yO! r mobile
phone, You canalso use the phope to browse
incoming e-mail and read messa~es.
Delayed messages
Compose e-mail on your PC wh Ie you are on
an airplane. When you land and are allowed to
switch on your mobile phone, tb~ messages are
sent immediately.
Automatic synchronization
Automatically synchronize your desktop
computer,portablePC, noteboc~,and mobile
phone. As spon asyou enter the office, the
addresslistand calendar in yOUI notebook
autolllaticallyupdates the files ( n your desktop
computer or vice versa.
Instant. digital p()stcard
Connect a cameracordlessly to wour mobile
ph?neor toa.ny.wire-bound cor nection. Add
colllments fromyou mobile phcpe, a notebook,
or portable PGand send them il stantly.
Cordless desktop
Cpnnect your desktop/laptop cc mputer
cordlessly to printers, scanner, k~yboard,
mouse, and the LAN.
466 CHAPTEIt 15 / BLUETOOTH AND IEEE 802.15
Bluetooth Standards
The Bluetooth standards present a formidable bulk-well 0' er 1500 pages, divided
into two groups: core and profile. The core specifications des ribe the details of the
various layers of the Bluetooth protocol architecture, from the radio interface to
link control. Related topics are covered, such as interoperat ility with related
technologies,
testing requirements, and a definition of various Bluetooth timers and
their associated values.
The profile specifications are concerned with the use 0 Bluetooth technology
to support various applications. Each profile specificatiOI discusses the use of
the technology defined in the core specifications to implen ent a particular usage
model. The profile specification includes a description of wI ich aspects of the core
specifications are mandatory, optional, and not applicable. The purpose of a profile
specification is to define a standard of interoperability so that products from
different vendors that claim to support a given usage mo, el will work together.
In general terms, profile specifications fall into one of two c( tegories: cable
replacement
or wireless audio. The cable replacement profiles prov de a convenient means
for logically connecting devices in proximity to one anotl er and for exchanging
data. For example, when two devices first come within ran e of one another, they
can automatically query each other for a common profile. TJ is might then cause the
end users of the device to be alerted, or cause some automat c data exchange to take
place. The wireless audio profiles are concerned with establ shing short-range voice
connections.
Protocol Architecture
Bluetooth is defined as a layered protocol architecture (Figme 15.1) consisting of core
protocols, cable replacement and telephony control protocol, and adopted protocols.
The core protocols form a five-layer stack consisting 0 the following elements:
1II Radio: Specifies details of the air interface, including. requency, the use of frequency

hopping, modulation scheme, and transmit po er.

• Baseband: Concerned with connection establishment' ithin a piconet, addressing,
packet format, timing, and power control.
11l Link manager protocol (LMP): Responsible for Ii k setup between Bluetooth

devices and ongoing link management. This j cludes security aspects

such as authentication and encryption, plus the co trol and negotiation of
baseband packet sizes.
1II Logical link control and adaptation protocol (L2Ci P): Adapts upper-layer

protocols to the baseband layer. L2CAP provides oth connectionless and

connection-oriented services.
.. Service discovery protocol (SDP): Device informati( n, services, and the
characteristics
of the services can be queried to enabl< the establishment of a
connection between two or more Bluetooth devices.
RFCOMM is the cable replacement protocol include in the Bluetooth specification.
RFCOMM presents a virtual serial port that is desi~ ned to make replacement
r,
= Core protocols
~ =Cable replacement protocol
~ =Telephony control protocols
D~ Adopted protocols
vCard/vCal WAE
OBEX WAP
UDPITCP
IP
PPP
Audio Control
Host-controller interface
AT
IP
OBEX
PPP
RFCOMM
~nn

=attention sequence (modem prefix)

=Internet Protocol
=Object Exchange Protocol
=Point-to-Point Protocol
=radio frequency communications
- ~n_..:nn n:nnmm_.. D_nfnnnl
L;> - J
TCS BIN
UDP
vCal
vCard
WAE
UIAD

=telephony control specification-binary

=User Datagram Protocol
=virtual calendar
=virtual card
=wireless application environment
'l'~ ...nl .... C'C' A..".."I;"' .... t;n.~ D ....ntn."...nl
rr

TCP =Transmission Control Protocol

Figure 15.1 Bluetooth Protocol Stack
468 CHAPTER J 5 / BLUETOOTHAND IEEE 802.15
of cable technologies as transparent as possible. Serial port are one of the most
common types of communications interfaces used with corr puting and communications
devices. Hence, RFCOMM enables the replacemen of serial port cables
with the minimum of modification of existing devices. RFCO~ M provides for binary
data transport and emulates EIA-232 control signals ove the Bluetooth baseband
layer. EIA-232 (formerly known as RS-232) is a widel) used serial port interface
standard.
Bluetooth specifies a telephony control protocol.TCS I IN (telephony control
specification-binary) is a bit-oriented protocol that defines the call control signaling
for the establishment of speech and data calls betweer Bluetooth devices. In
addition, it defines mobility management procedures for ha dling groups of Bluetooth
TCS devices.
The adopted protocols are defined in specifications iSSl ed by other standardsmaking
organizations and incorporated into the overall BlUE tooth architecture. The
Bluetooth strategy is to invent only necessary protocols ane use existing standards
whenever possible. The adopted protocols include the follo~ ing:
"" PPP: The point-to-point protocol is an Internet stane ard protocol for transporting
IP datagrams over a point-to-point link.
• TCPfUDPIIP: These are the foundation protocols ef the TCP/IP protocol
suite (described in Chapter 4).
• OBEX: The object exchange protocol is a session-Ieve protocol developed by
the Infrared Data Association (IrDA) for the exchangl of objects. OBEX provides
functionality similar to that of HTTP, but in a simpler fashion. It also
provides a model for representing objects and opera ions. Examples of content
formats transferred by OBEX are vCard and v( alendar, which provide
the format of an electronic business card and persor al calendar entries and
scheduling information, respectively.
• WAEIWAP: Bluetooth incorporates the wireless al plication environment
and the wireless application protocol into its arc itecture (described in
Chapter 12).
Usage Models
A number of usage models are defined in Bluetooth profil documents. In essence,
a usage model is set of protocols that implement a particula Bluetooth-based
application.
Each profile defines the protocols and protocol feat res supporting a particular
usage model. Figure 15.2, taken from [METT99], illust ates the highest-priority
usage models:
\II File transfer: The file transfer usage model supports t] e transfer of directories,

files, documents, images, and streaming media forma s. This usage model also
includes the capability to browse folders on a remote device.
• Internet bridge: With this usage model, a PC is w relessly connected to a
mobile phone or cordless modern to provide dial-up 1 etworking and fax capabilities.
For dial-up networking, AT commands are wed to control the mobile
(a) File transfer
(c) LAN access
(e) Cordless phone and intercom
Hgure 15.2 Bluetooth Usage Models
15.1 / 0' 7ERVIEW 469
(b) Dial-up network ng
(f) Headset
phone or modem, and another protocol stack (e.g., PPP over RFCOMM) is
used for data transfer. For fax transfer, the fax software op rates directly
over RFCOMM.
• LAN access: This usage model enables devices on a piconet to access a LAN.
Once connected, a device functions as if it were directly com ected (wired)
to the LAN.
• Synchronization: This model provides a device-to-device synchronization of
PIM (personal information management) information, such a phone book,
calendar, message, and note information. IrMC (Ir mobile coml unications) is
an IrDA protocol that provides a client/server capability f( r transferring
updated PIM information from one device to another.
• Three-in-one phone: Telephone handsets that implement thi usage model
may act as a cordless phone connecting to a voice base station, s an intercom
device for connecting to other telephones, and as a cellular pho e.
• Headset: The headset can act as a remote device's audio inJ=ut and output
interface.
470 CHAPTER 15 / BLUETOOTH AND IEEE 802.15
Piconets and Scatternets
As was mentioned, the basic unit of networking in Bluetooth 's a piconet, consisting
of a master and from one to seven active slave devices. The I dio designated as the
master makes the determination of the channel (frequency-t opping sequence) and
phase (timing offset, i.e., when to transmit) that shall be usee by all devices on this
piconet. The radio designated as master makes this detern 'nation using its Own
device address as a parameter, while the slave devices must tu e to the same channel
and phase. A slave may only communicate with the master aJ d may only communicate
when granted permission by the master. A device in one piconet may also exist
as part of another piconet and may function as either a slave or master in each
piconet (Figure 15.3). This form of overlapping is called a :;catternet. Figure 15.4,
based on one in [HAAROOa], contrasts the piconet/scatternet architecture with other
forms of wireless networks.
The advantage of the piconet/scatternet scheme i~ that it allows many
devices to share the same physical area and make efficient use of the bandwidth.
A Bluetooth system uses a frequency-hopping scheme wi:h a carrier spacing of
1 MHz. Typically, up to 80 different frequencies are used fClr a total bandwidth of
80 MHz. If frequency hopping were not used, then a singlE channel would correspond
to a single I-MHz band. With frequency hoppin;~ a logical channel is
defined by the frequency-hopping sequence. At any give 1 time, the bandwidth
available is 1 MHz, with a maximum of eight devices sharilg the bandwidth. Different
logical channels (different hopping sequences) car. simultaneously share
the same 80-MHz bandwidth. Collisions will occur when devices in different
Figure 15.3 Master/Slave Relationships
15.2/ fLADIO SPECIfICATION 471

•
•
/ "/

/
I
I
. I

I
I
I
\

\ ,,

'"
"
. ,

,
.....
" .\,
\
\
\
II
I
I
I
I
/

./
_/

/-- .......

I,
I,
'. I ",,

I •• \
1\
\\
\\
\\
1
\I

". !

\ . , "' / ....... _/

(a) Cellular system (squares represent

stationary base stations)
(b) Conventional ad hoc systems
-,

/ ..... (. "
\ ' \\
..-\, ,

I \" \

II "",,-/I
\\
, .'\. \

\\
\\

\ --------""'1"-, \
(. '.') , '1 \
'__ _\-" I
------ \ ,I ./ '-

-- /-, /\

/,,- ''1/ .'

//"I
I•/\I
I/•\I
I /) I
I/I
\III
,III
\ I. / I
"I / /
'-1- __ -/ I
II
II
I/
I/

I/

I,
'./ //
/

(c) Scattemets
Figure 15.4 Wireless Network Configurations
piconets, on different logical channels, happen to use the same hep frequency at
the same time. As the number of piconets in an area increases, the number of collisions
increases, and performance degrades. In summary, the ph:rsical area and
total bandwidth are shared by the scatternet. The logical channel ;md data transfer
are shared by a piconet.
15.2 RADIO SPECIFICATION
The Bluetooth radio specification is a short document that gives the basic details of
radio transmission for Bluetooth devices. Some of the key parametl~rs are summarized
in Table 15.2.
One aspect of the radio specification is a definition of three classes of transmitters
based on output power:
• Class 1: Outputs 100 mW (+20 dBm) for maximum range, with a minimum
of 1 mW (0 dBm). In this class, power control is mandatory, ra:lging from 4 to
20 dBm. This mode provides the greatest distance.
472 CHAPTER 15 / BLUETOOTHAND IEEE 802.15
Table 15.2 Bluetooth Radio and Baseband Parameters
Frequency hop rate
Scatternet a.ccess
O.lW
FH-TDD-TDMA
1600 hops/s
FH-CDMA
• Class 2: Outputs 2.4 roW (+4 dBm) at maximum, with a minimum of 0.25 mW
(-6 dBm). Power control is optional.
• Class 3: Lowest power. Nominal output is 1 mW.
Bluetooth makes use of the 2.4-GHz band within the ISM (industrial, scientific,
and medical) band. In most countries, the bandwid1h is sufficient to define
79 I-MHz physical channels (Table 15.3). Power control is t.sed to keep the devices
from emitting any more RF power than necessary. The power control algorithm is
implemented using the link management protocol bet", een a master and the
slaves in a piconet.
Modulation for Bluetooth is Gaussian FSK, with a binary one represented
by a positive frequency deviation and a binary zero represented by a
negative frequency deviation from the center frequenc:'. The minimum deviation
is 115 kHz.
15.3 BASEBAND SPE<1lE1eJA1JION
One of the most complex of the Bluetooth documents is th~ baseband specification.
In this section we provide an overview of the key elements
Table 15.3 International Bluetooth Frequency Allocations
f= 2.4(2 +n MHz, n= 0, ... ,78
2.471 to 2.497 GHz
2.445 to 2.475 GHz
L
RF·Cbannels
2.4~4+ n MHz, n =0, ... , 22
15.3 I BASEBAND SPEC IFICATION 473
Frequency Hopping
Frequency hopping (FH) in Bluetooth serves two purposes:
1. It provides resistance to interference and multipath effects.
2. It provides a form of multiple access among co-located devices in different
piconets.
The FH scheme works as follows. The total bandwidth is d: vided into 79 (in
almost all countries) physical channels, each of bandwidth 1 MIIz. FH occurs by
jumping from one physical channel to another in a pseudorandcm sequence. The
same hopping sequence is shared by all of the devices on a singl< ~ piconet; we will
refer to this as an FH channel2 The hop rate is 1600 hops per second, so that each
physical channel is occupied for a duration of 0.625 ms. Each 0.625- ms time period is
referred to as a slot, and these are numbered sequentially.
Bluetooth radios communicate using a time division duplex (TDD) discipline.
Recall from Chapter 11 that TDD is a link transmission techniq le in which data
are transmitted in one direction at a time, with transmission altern, ting between the
two directions. Because more than two devices share the piconet m ~dium, the access
technique is TDMA. Thus piconet access can be characterized as FH-TDD-TDMA.
Figure 15.5 illustrates the technique.3 In the figure, k denotes the slot number, and
f(k) is the physical channel selected during slot period k.
Transmission of a packet starts at the beginning of a slot. Pack;;t lengths requiring
1,3, or 5 slots are allowed. For multislot packets, the radio remair s at the same
frequency
until the entire packet has been sent (Figure 15.6). In the r ext slot after the
multislot packet, the radio returns to the frequency required for its h )pping sequence,
so that during transmission, two or four hop frequencies have been: ;kipped.
Using TDD prevents crosstalk between transmit and receive )perations in the
radio transceiver, which is essential if a one-chip implementation is desired. Note
that because transmission and reception take place at different tin Le slots, different
frequencies are used.
f(k) f(k + 1) f(k + 2)
1
III
III

Master i•.r.•·.:. I Ilit; L ~~.-----'----1-: ---+:. ErlL-. -J.

!
II
1 i1 '
Slave :
II
:11-' --71----------'-1 'l!1ij

:""",,1{---625 JLS ----..,.~::

Figure 15.5 Frequency-Hop Time Division Duplex
•t
•t
2The term FH channel is not used in the Bluetooth documents but is introduced her: for clarity.
3The three regions indicated in each packet (dark gray, light gray, white) depict the :hree major subdivisions
of each packet (access code, header, payload), as explained subsequently.
-625fJ-5f(
k) f(k + 1) f(k + 2) f(k + 3) f(k + 4) f(k + 5) f(k + 6)
f(k)
f(k)
f(k + 3) f(k + 4) f(k + 5) f(k + 6)
1I1

0!.~.'.'.!.'.'.
1,1 :. :lI d

-lUL.
------------------i--------rlldL------1---i--------r1 IL----L-i--J)O~ t
11I
I11
f(k + 5) f(k + 6)
II

--
II 1,11%.',l.•,.• ·

1 [IfL-----------------------------------TI.... )00 t
1 1I
Figure 15.6 Examples of Multislot Packets
15.3 / BASEBAND SPEclTFICATION 475
The FH sequence is determined by the master in a piconet ajlld is a function of
the master's Bluetooth address. A rather complex mathematical 0 I>eration involving
permutations and exclusive-OR (XOR) operations is used to generate a pseudorandom
hop sequence. I

Because different piconets in the same area will have diffe !'ent masters, they
will use different hop sequences. Thus, most of the time, tran ~missions on two
devices on different piconets in the same area will be on different physical channels.
Occasionally, two piconets will use the same physical channel dur !ng the same time
slot, causing a collision and lost data. However, because this rill happen infrequently,
it is readily accommodated with forward error correctio i and error detection/
ARQ techniques. Thus, a form of code division multiple a'icess (CDMA) is
achieved between devices on different piconets in the same ~Icatternet; this is
referred to as FH-CDMA. I
I

Physical Links I,
Two types of links can be established between a master and a slav1!~:
• Synchronous connection oriented (SCQ): Allocates a I'ixed bandwidth
between a point-to-point connection involving the master a!nd a single slave.
The master maintains the SCO link by using reserved slots at regular
intervals. The basic unit of reservation is two consecutive slots (one in each
transmission direction). The master can support up to th lee simultaneous
SCO links while a slave can support two or three SCO links.SCO packets are
never retransmitted.
i

• Asynchronous connectionless (ACL): A pOint-to-mUltiPOint]llink between the

master and all the slaves in the piconet. In slots not reserved br SCO links, the
master can exchange packets with any slave on a per-slot I)asis, including a
slave already engaged in an SCO link. Only a single ACL link can exist. For
most ACL packets, packet retransmission is applied. I
I

SCO links are used primarily to exchange time-bounded daJ!l requiring guaranteed
data rate but without guaranteed delivery. One example, us !:d in a number of
Bluetooth profiles, is digitally encoded audio data with built-in tolerance to lost
data. The guaranteed data rate is achieved through the reservati ill of a particular
number of slots. I
ACL links provide a packet-switched style of connection. No bandwidth reservation
is possible and delivery may be guaranteed through err I>r detection and
retransmission. A slave is permitted to return an ACL packet in th !~ slave-to-master
slot if and only if it has been addressed in the preceding master-Io-slave slot. For
ACL links, I-slot, 3-slot, and 5-slot packets have been defined. I)ata can be sent
either unprotected (although ARQ can be used at a higher layer) !Ir protected with
a 2/3 forward error correction code. The maximum data rate that c 1m be achieved is
with a 5-slot unprotected packet with asymmetric capacity allocation, resulting in
721 kbps in the forward direction and 57.6 kbps in the reverse dir iction. Table 15.4
summarizes all of the possibilities.
476 CHAPTER 15 / BLUETC)OTH l\ND IEEE 802.IS
Table 15.4 Achievable Data Rates on the ACL Link
Type
DM1
DR1
DM3
DR3
DM5
DRS
Symmetric (kbps)
108.8
172.8
256.0
384,0
286.7
432.6
Asymmirtric (kbps)
108.8 108.8
172.8· 172.8
384.0 54.4
576.0 86.4
477.8 36.3
721.0 57.6
DMx = x-slot FEe-encoded
DHx = x-slot unprotected
Packets
The packet format for all Bluetooth packets is shown in Filgure 15.7. It consists of
three fields:
.. Access code: Used for timing synchronization, offselt compensation, paging,
and inquiry
• Header: Used to identify packet type and to carry proUocol control information
• Payload: If present, contains user voice or data and, in most cases, a payload
header
Access Code There are three types of access codes:
• Channel access code (CAC): Identifies a piconet (un~que for a piconet)
• Device access code (DAC): Used for paging and its s~lbsequent responses
.. Inquiry access code (lAC): Used for inquiry purpose~~
An access code consists of a preamble, a sync word, a~ld a trailer. The preamble
is used for DC compensation. It consists of the pattern 0]01 if the least significant
(leftmost) bit in the sync word is 0 and the pattern 1010 if lthe least significant bit in
the sync word is 1. Similarly, the trailer is 0101 if the most ~iignificant bit (rightmost)
of the sync word is 1 and 1010 if the most significant bit is O.
The 64-bit sync word consists of three components (IFigure 15.8) and is worth
examining in some detail. Each Bluetooth device is assigned a globally unique 48-bit
address. The 24 least significant bits are referred to as the 10Wier address part (LAP)
and
are used in forming the sync word. For a CAC, the LAP olE the master is used; for a
DAC, the LAP of the paged unit. There are two different lACs. The general lAC
(GIAC) is a general inquiry message used to discover which Bluetooth devices are in
range, and for this a special reserved value of LAP is mi'ailable. A dedicated lAC
(DIAC) is common for a dedicated group of Bluetooth units that share a common
characteristic,
and a previously defined LAP corresponding to that characteristic is used.
Using the appropriate LAP, the sync word is formed as follows:
1. To the 24-bit LAp, append the 6 bits 001101 if the nlOst significant bit (MSB)
of the LAP is 0, and append 110010 if the MSB is LThis forms a 7-bit Barker
bits 72 54 oto 2745
Header Payload
(a) Packet format
4 64 4
(b) Access code format
341118
AM_Addr Type Flow ARQN SEQN Header error control (HEC)
(c) Header format (prior to coding)

I
L,ngth S;nglNlol p>ok,"
94
----------
5
___________L_e_n_gt_h u_n_d_e_fi_n_e_d 1 Mnllislol pad<'"
21

L_CH
21
EI
L_CH B
(d) Data payload header format
Figure 15.7 Bluetooth Baseband Formats
478 CHAPTER 15 I BlUETOOTH AND IEEE 802.15
P34P3S ,,,PS7 IpS8"P631 PN sequence

aoal'" a23 10011011 i fa23 =0

aoal'" a23 11100101 if a23 =1
Lower address Barker code
part (LAP) (including a23)

aoal ••• a23 10011011 if a23 = 0

aoal'" a23 11100101 ifa23 = 1

EB
P34P3s ",PS7 IpS8 "P63!
Psuedonoise
(PN) sequence

-
Xo ",x 23 I X24 •• x29! Data to encode
- Xo'" x23 1;24 ";291
either 1 _
or IL- .I---J.__-J

I
(64,30) block code derived

.
from (63, 30 ) BCH code I
I Co ••• C33 I
EB
I Po ,,·P33 ,
I Co ••• C33 I
I Co ... C33 [
Figure 15.8 Construction of Sync Word
sequence.4 The purpose of including a Barker sequel ce is to further improve
the autocorrelation properties of the sync word.
2. Generate a 64-bit pseudonoise (PN) sequence, Po, Pl' ... ,P63' The sequence is
r
defined by the equation P(X) = 1 + X 2 + X 3 + X 5 + and can be implemented
with a 6-bit linear feedback shift register. 11: e seed value for the PN
sequence is 100000.5
3. Take the bitwise XOR of P34> P35, ... ,P63 and the 30--bit sequence produced in
step 1. This "scrambles" the information, removing unv anted regularities.
4. Generate a 34-bit error-correcting code for the scramb ed information block and
place this at the beginning to form a 64-bit codeword. Thus, we have a (64,30)
code. To generate this code, start with a (63,30) BCH opde.6 Then define the generator
polynomial g(X) = (1 + X)g'(X), where g'(X) is the generator polynomial
for the (63,30) BCH code. This produces the d sired 34-bit code.
5. Take the bitwise XOR of Po, Pa' ... ,P63 and the 64-ipit sequence produced in
step 4. This step descrambles the information part of the codeword so that the
1
original LAP and Barker sequence are transmitted. The step also scrambles
the block code.
4See Section 14.4 for a disc.'lssion of Barker sequences.
5See Section 7.5 for a discussion of PN sequence generation and generating equations [e.g., Equation
(7.9)].
6See Section 8.2 for a discussion of BCH codes.
15.3 / BASEBAND SPECIFICATION 479
The scrambling of the information part of the codeword in step 3 is designed
to strengthen the error-correcting properties of the block code. The subsequent
descrambling enables the receiver to recover the LAP easily. In the words of the
specification, the scrambling of the 34-bit error code removes tb e cyclic properties
of the underlying code. This might give better transmission spectral qualities and
also improve autocorrelation properties.
Packet Header The header format for all Bluetooth packets is shown in Figure 15.7c.
It consists of six fields:
• AM_ADDR: Recall that a piconet includes at most seven active slaves. The
3-bit AM_Addr contains the "active mode" address (temporary address
assigned to this slave in this piconet) of one of the slaves. A transmission from
the master to a slave contains that slave's address; a transmlssion from a slave
contains its address. The 0 value is reserved for a broadcast ::rom the master to
all slaves in the piconet.
• Type: Identifies the type of packet (Table 15.5). Four type codes are reserved
for control packets common to both SCQ and ACL lin:cs. The remaining
packet types are used to convey user information. For SeQ links, the HVl,
HV2, HV3 packets each carry 64-kbps voice. The difference is the amount of
error protection provided, which dictates how frequently a packet must be
sent to maintain the 64-kbps data rate. The DV packet carries both voice and
data. For ACL links, 6 different packets are defined. These, together with the
DMI packet, carry user data with different amounts of error protection and
different data rates (Table 15.4). There is another packet type common to both
physical links; it consists of only the access code, with a fixed length of 68 bits
(does not include trailer). This is referred to as the ID packe: and is used in the
inquiry and access procedures.
• Flow: Provides a I-bit flow control mechanism for ACL tr 3.ffic only. When a
packet with Flow = 0 is received, the station receiving the packet must temporarily
halt the transmission ofACL packets on this link. V\'hen a packet with
Flow = 1 is received, transmission may resume.
• ARQN: Provides a I-bit acknowledgment mechanism for ACL traffic protected
by a CRC (Table 15.5). If the reception was su::cessful, an ACK
(ARQN = 1) is returned; otherwise a NAK (ARQN = 0) is returned. When
no return message regarding acknowledge is received, a NAK is assumed
implicitly. If a NAK is received, the relevant packet is retransmitted.
• SEQN: Provides a I-bit sequential numbering schemes. Transmitted packets
are alternately labeled with a 1 or O. This is required to filt er out retransmissions
at the destination; if a retransmission occurs due to Cl failing ACK, the
destination receives the same packet twice.
• Header error control (HEC): An 8-bit error detection code used to protect the
packet header.
Payload Forlllat For some packet types, the baseband specification defines a
format for the payload field. For voice payloads, no header is defined. For all of the
480 CHAPTER 15 / BLUETOOTH AND IEEE 802.15
Table 15.5 Bluetooth Packet Types
Type Physical · N~"er
Code Link Name of Slots Description
0000 Common NULL 1 Has no payload. Used to return
link information to the source
regarding the success of the
: previous transmission (ARQN), or
the status of the RX buffer
(FLOW). Not acknowledged.
0001 Common POLL 1 Has no payload. Used by master to
poll a slave. Acknowledged.
0010 Common FRS 1 Special control packet for
revealing device address and the
clock of the sender. Used in page
master response, inquiry response,
and frequency hop synchronization.
2/3 FEC encoded.
0011 Common DM1 1 Supports control messages and can
also carry user data. 16-bit CRe.
2/3 FEC encoded.
0101 SCO HV1 1 Carries 10 information bytes;
typically used for 64-kbps voice. 1/3
FEC encoded.
0110 SCO HV2 1 Carries 20 information bytes;
typically used for 64-kbps voice. 2/3
FEC encoded.
0111 SCO HV3 1 Carries 30 information bytes;
typically used for 64-kbps voice.
Not FEC encoded.
1000 SCO DV 1 Combined data (150 bits) and
voice (50 bits) packet. Data field
2/3 FEC encoded.
0100 ACL DH1 1 Carries 28 information bytes plus
16-bit CRe. Not FEC encoded.
Typically used for high-speed data.
1001 ACL AUX1 1 Carries 30 information bytes with
no CRC or FEe. Typically used for
high-speed data.
1010 ACL DM3 3 Carries 123 information bytes plus
16-bit CRe. 2/3 FEC encoded.
1011 ACL DH3 3 Carries 185 information bytes plus
16-bit CRe. Not FEC encoded.
1110 ACL DM5 5 Carries 226 information bytes plus
16-bit CRe. 2/3 FEC encoded.
1111 ACL DRS 5 Carries 341 information bytes plus
16-bit CRe. Not FEC encoded.
15.3 IBASEB/\ND SPECIFICATION 481
ACL packets and for the data portion of the SCQ DV packet, a header is defined.
For data payloads, the payload format consists of three fields:
• Payload header: An 8-bit header is defined for single-slot packets, and a 16-bit
header is defined for multislot packets.
• Payload body: Contains user information.
• CRC: A 16-bit CRC code is used on all data payloads except the AUXI packet.
The payload header, when present, consists of three fields (Figure 15.7d):
• L_CH: Identifies the logical channel (described subsequently). The options
are LMP message (11); an unfragmented L2CAP message or the start of a
fragmented L2CAP message (10); the continuation of a fragmented L2CAP
message (01); or other (00).
• Flow: Used to control flow at the L2CAP level. This is the same on/off mechanism
provided by the Flow field in the packet header for ACL traffic.
• Length: The number of bytes of data in the payload, excluding the payload
header and CRe.
Error Correction
At the baseband level, Bluetooth makes use of three error correction schemes:
• 1/3 rate FEC (forward error correction)
• 2/3 rate FEC
• ARQ (automatic repeat request)
These error correction schemes are designed to satisfy competing requirements.
The error correction scheme must be adequate to cope with the inherently
unreliable wireless link but must also be streamlined and efficient.
The 113 rate FEC is used on the 18-bit packet header and also for the voice
field in an HVI packet. The scheme simply involves sending three copies of each bit.
A majority logic is used: Each received triple of bits is mapped into whichever bit is
in the majority.
The 2/3 rate FEC is used in all DM packets, in the data field of the DV packet,
in the FHS packet, and in the HV2 packet. The encoder is a form of Hamming code
with parameters (15,10). This code can correct all single errors and detect all double
errors in each codeword.
The ARQ scheme is used with DM and DH packets and the data field of DV
packets. The scheme is similar to ARQ schemes used in data link control protocols
(Section 8.4). Recall that ARQ schemes have the following elements:
• Error detection: The destination detects errors and discards packets that are
in error. Error detection is achieved with a CRC error-detecting code supplemented
with the FEC code.
• Positive acknowledgment: The destination returns a positive acknowledgment
to successfully received, error-free packets.
482 CHAPTER 15 / BLUETOOTfI AND IEEE S02.iS
• Retransmission after timeout: The source retransmits a packet that has not
been acknowledged after a predetermined amount of time.
41 Negative acknowledgment and retransmission: The destination returns a negative

acknowledgment to packets in which an error is detected. The source

retransmits such packets.
Bluetooth uses what is referred to as afastARQ scheme, which takes advantage of
the fact that a master and slave communicate in alternate time slots. Figure 15.9
illustrates
the technique. When a station receives a packet, it determines if an error has
occurred using a 16-bit CRe. If so, the ARQN bit in the header set to a (NAK); if no
error is detected, then ARQN is set to 1 (ACK). When a station receives a NAK, it
retransmits the same packet as it sent in the preceding slot, using the same 1-bit SEQN
in the packet header. With this technique, a sender is notified in the next time slot if a
transmission has failed and, if so, can retransmit. The use of 1-bit sequence numbers
and
immediate packet retransmission minimizes overhead and maximizes responsiveness.
Figure 15.10 shows the ARQ mechanism in more detail. On reception of a packet
(Figure 15.10a), the device first checks that the header is valid, using the HEC; if not
the
packet is rejected andARQN is set to NAK in the next time slot.Then the device does an
address match and checks whether this is the type of packet that uses the ARQ
mechanisms.
Having passed these tests, the device next checks whether this is a new sequence
number (SEQN) or the same as the last SEQN. If the SEQNs are the same, then this is a
retransmission, which is ignored. If the SEQN is new, then the device checks the CRe. If
no error is detected, the next outgoing packet has ARQN = ACK, and if an error is
detected, the next outgoing packet has ARQN = NAK.
On the transmit side (Figure 15.10b), the next DM, DH, or DV packet to be
transmitted is determined by the value of the immediately preceding incoming
ARQN. So long as ACKs are received, the device sends out new payload, alternating
SEQN values between a and 1. If a NAK or no acknowledgment at all is
received, the device will retransmit the old payload repeatedly until an ACK is
received or until some threshold is reached, at which time the old payload is flushed
from the transmit buffer and a new payload is transmitted.
Logical Channels
Bluetooth defines five types of logical data channels designated to carry different
types of payload traffic.
• Link control (LC): Used to manage the flow of packets over the link interface.
The LC channel is mapped onto the packet header. This channel carries lowlevel
link control information like ARQ, flow control, and payload characterization.
The LC channel is carried in every packet except in the ID packet,
which has no packet header.
\) Link manager (LM): Transports link management information between participating
stations. This logical channel supports LMP traffic and can be carried
over either an SCO or ACL link.
41 User asynchronous (UA): Carries asynchronous user data. This channel is

normally carried over the ACL link but may be carried in a DV packet on
the SCO link.
f(k + 1) f(k + 2) f(k + 3) f(k + 4) f(k + 5) f(k + 6) f(k + 7) f(k + 8) f(k + 9) J(k + 10) J(k + 11) J(k +
12)
Master t

! ! ~! ~! ~

Failure <Z

~ 1 1 1 ~l
Failure
~ ~
U < U< Z<
Slave 1 t
Slave 2 --+---1------+----+----t----+---+--- ===:L-I----I----+---J!!==d.-f~t
625 f.LS
Figure 15.9 An Example of Retransmission Operation
HECOK?
No No
..---~DMlDHlDV?
No
(b) Retransmit filtering for packets with CRe.
ARQN =NAK
in next
xmission
No
No
ARQN =ACK
1-.__....., in next
xmission
Ignore payload
..---------------<AM_AddrOK?
(a) Receive protocol for determining the ARQN bit.
to Bluetooth ARQ Scheme
15.3 ! BASEBAND SPECIFICATION 485
• User isochronous (UI): Carries isochronous user data.7 This channel is normally
carried over the ACL link but may be carried in a DV packet on the
sca link. At the baseband level, the VI channel is treated the same way as
a VA channel. Timing to provide isochronous properties is provided at a
higher layer.
• User synchronous (US): Carries synchronous user data. This channel is carried
over the sca link.
Channel Control
The operation of a piconet can be understood in terms of the states of operation during
link establishment and maintenance (Figure 15.11). There are two major states:
• Standby: The default state. This is a low-power state in which only the native
clock is running.
• Connection: The device is connected to a piconet as a master or a slave.
Figure 15.11 Bluetooth State Transition Diagram
7The term isochronous refers to blocks of data that recur with known periodic timing.
486 CHAPTER 15 / BLUETOOTH AND IEEE 802.15
In addition, there are seven interim substates that are used to add new slaves
to a piconet. To move from one state to the other, either commands from the Bluetooth
link manager are used or internal signals in the link controller are used. The
substates are as follows:
.. Page: Device has issued a page. Used by the master to activate and connect to
a slave. Master sends page message by transmitting slave's device access code
(DAC) in different hop channels.
.. Page scan: Device is listening for a page with its own DAC.
e Master response: A device acting as a master receives a page response from a
slave. The device can now enter the connection state or return to the page state
to page for other slaves.
.. Slave response: A device acting as a slave responds to a page from a master. If
connection setup succeeds, the device enters the connection state; otherwise it
returns to the page scan state.
• Inquiry: Device has issued an inquiry, to find the identity of the devices
within range.
.. Inquiry scan: Device is listening for an inquiry.
.. Inquiry response: A device that has issued an inquiry receives an inquiry response.
Inquiry Procedure The first step in establishing a piconet is for a potential
master to identify devices in range that wish to participate in the piconet.
A device begins an inquiry procedure for this purpose under the impetus of a user
or application on the device. The inquiry procedure begins when the potential
master transmits an ID packet with an inquiry access code (lAC), which is a code
common to all Bluetooth devices. Recall that the ID packet has no header and
no payload.
Of the 79 radio carriers, 32 are considered wake-up carriers. The master broadcasts
the lAC over each of the 32 wake-up carriers in turn. This occurs in the Inquiry
state (Figure 15.11). Meanwhile, devices in the Standby state periodically enter the
Inquiry Scan state to search for lAC messages on the wake-up carriers. When a
device receives the inquiry, it enters the Inquiry Response state and returns an FHS
packet (Table 15.5) containing its device address and timing information required
by the master to initiate a connection. The master does not respond to the FHS
packet and may remain in the Inquiry state until it is satisfied that all radios have
been found.
Once a device has responded to an Inquiry, it moves to the page scan state
to await a page from the master in order to establish a connection. However, if a
collision occurred in the Inquiry Response phase (two or more devices simultaneously
respond to an inquiry), no page will be received and the device may
need to return to the Inquiry Scan state to attempt another inquiry and
response.8
8The state diagram of Figure 15.12 is taken from the baseband specification and does not show a
transition
from Inquiry Response to Page Scan but does show a transition from Inquiry Response to Inquiry
Scan. However, the accompanying text in the specification corresponds to the explanation we give.
15.3 / BASEBAND SPECIFICATION 487
Page Procedure Once the master has found devices within its range, it is able to
establish a connection to each device, setting up a piconet. For each device to be
paged, the master uses that device's address (BD_ADDR) to calculate a page frequency-
hopping sequence, the aim of which is to contact the device during paging.
The master pages by using an ID packet, this time with a device access code (DAC)
of the specific slave. Recall that the DAC is the lower address part of the slave's
device address. The slave responds by returning the same DAC ID packet to the master
in the same hopping sequence (known as the page-mode-hopping sequence) that
was used by the master. The master responds to this in the next master-to-slave slot
with its own FRS packet, containing its device address and its real-time Bluetooth
clock value. Once again, the slave sends a response DAC ID packet to the master to
confirm the receipt of the master's FRS packet. The slave at this point transitions
from the Slave Response state to the Connection state and begins to use the connection
hopping sequence defined in the master's FRS packet. Meanwhile, the master
may continue to page until it has connected to all the desired slaves; the master then
enters the Connection state.
Connection State For each slave, the Connection state starts with a Poll packet
sent from the master to verify that the slave has switched to the master's timing and
channel frequency hopping. The slave can respond with any type of packet.
Once the slave is in the Connection state, it can be in one of four modes of
operation:
• Active: The slave actively participates in the piconet by listening, transmitting,
and receiving packets. The master periodically transmits to the slaves to maintain
synchronization.
• Sniff: The slave does not listen on every receive slot (every other slot) but only
on specified slots for its messages. The slave can operate in a reduced-power
status the rest of the time. For sniff mode to operate, the master designates a
reduced number of time slots for transmission to a specific slave.
• Hold: The device in this mode does not support ACL packets and goes to
reduced power status. The slave may still participate in SCO exchanges. During
periods of no activity, the slave is free to idle in a reduced power status or
possibly participate in another piconet.
• Park: When a slave does not need to participate on the piconet but still is to
be retained as part of the piconet, it can enter the park mode, which is a
low-power mode with very little activity. The device is given a parking
member address (PM_ADDR) and loses its active member (AM_ADDR)
address. With the use of the park mode, a piconet may have more than
seven slaves.
Bluetooth Audio
The baseband specification indicates that either of two voice encoding schemes can
be used: pulse code modulation (PCM) or continuously variable slope delta
(CYSD) modulation. The choice is made by the link managers of the two
communicating
devices, which negotiate the most appropriate scheme for the application.
488 CHAPTER 15 I BLUETOOTH AND IEEE 802.15
PCM was discussed in Section 6.4. CVSD is a form of delta modulation (DM),
also discussed in Section 6.4. Recall that with delta modulation, an analog input is
approximated bya staircase function that moves up or down by one quantization
level (0) at each sampling interval (Ts )' Thus, the output of the delta modulation
process can be represented as a single binary digit for each sample. In essence, a bit
stream is produced by approximating the derivative of an analog signal rather than
its amplitude: A 1 is generated if the staircase function is to go up during the next
interval; a 0 is generated otherwise.
As was discussed, there are two forms of error in a DM scheme: quantizing
noise, which occurs when the waveform is changing very slowly, and slope overload
noise, when the waveform is changing rapidly (Figure 6.18). CVSD is designed to
minimize both these types of error by using a variable quantization level, one that
is small when the waveform is changing slowly and large when the waveform is
changing rapidly (Figure 15.12; based on one in [HAAR98]). The slope is monitored
by considering the K most recent output bits. The resulting scheme is more
resistant to bit errors than PCM and more resistant to quantizing and slope overload
errors than DM.
Figure 15.13 illustrates the CVSD encoding and decoding (Compare Figure 6.19).
As with DM, a binary output is converted into a staircase function that tracks the
original
waveform as closely as possible. For encoding, the following occurs: The input to the
encoder is 64-kbps PCM. At each sampling time, the PCM input x(k) is compared to
the most recent value of the approximating staircase function, expressed as x(k - 1).
The output of the comparator b(k) is defined as
x(k) - x(k - 1) :> 0
x(k) - x(k -1) < 0
For transmission, these numbers are represented by the sign bit (negative
numbers are mapped to binary 1; positive numbers are mapped to 0). The output
b(k) is used as to produce the magnitude of the next step in the staircase, o(k),
as follows:
8(k) = {mill[8min + 8(k - 1), 8maxl
max[13 x 8(k - 1), 8minl
if at least] of the last K output bits b( .) are the same
otherwise
Table 15.6 shows the default parameter values. The effect of the preceding
definition is that if the waveform is changing rapidly (at least J of the last K steps
have been in the same direction), then the magnitude of the step change, o(k),
increases in a linear fashion by a constant amount 0min' up to some maximum magnitude
0max' On the other hand, if the waveform is not changing rapidly, then the
magnitude of the step change gradually decays by a decay factor {3, down to a minimum
value of 0min' The sign of the step change is determined by the sign of the
output bet).
The step change is then added to the most recent value of the staircase function
to produce Y(k).
y(k) = x(k - 1) + b(k)o(k)
489
490 CHAPTER 15 / BLUETOOTHAND IEEE 802.15
Binary
Digitized
input
x (k) output
b(k)
f(k - 1)

Comparator
Step size
!
control
f(k - 1) + XI
[j(k)
h
y(k)

/I ~Y(k-')
Satuy(
k - 1) Delay of
ration one time
- 1) unit
(a) Encoder
b(k) --------------------~--___,
f(k - 1)
h
/I x(k - 1)

(b) Decoder
Figure 15.13 Continuously Variable Slope Delta Modulation
This value is then delayed one sample time, yielding Y(k - 1). Then a
saturation function is applied, defined as
y(k - 1) = {min~(k - 1), Ymax]
max[jl(k - 1), Ymin]
Y(k - 1) > 0
Y(k - 1) < 0
where Ymin and Ymax are the negative and positive saturation values for the encoder,
limiting the total range of the staircase function.
Finally, y(k - 1) is multiplied by the decay factor h to yield the waveform estimate
x(k - 1). The decay factor determines how quickly the output of the CVSD
decoder returns to zero in the absence of a strongly changing input.
15.4 / LINK MANj\GER SPECIFICATION 491
Table 15.6 CVSD Parameter Values
15.4 LINK MANAGER SPECIFICAlilON ~ , x '
LMP manages various aspects of the radio link between a master and a slave. The
protocol involves the exchange of messages in the form of LMP PDUs (protocol
data units) between the LMP entities in the master and slave. Messages are
always sent as single slot packets with a 1-byte payload header that identifies the
message type and a payload body that contains additional information pertinent
to this message.
The procedures defined for LMP are grouped into 24 functional areas, each of
which involves the exchange of one or more messages. Table 15.7 lists these areas,
together with the PDUs involved in each area.9 We briefly look at each area in turn.
The two general response messages are used to reply to other PDUs in a number
of different procedures. The accepted PDU includes the opcode of the message that is
accepted. The noCaccepted PDU includes the opcode of the message that is not
accepted and the reason why it is not accepted.
LMP supports various security services with mechanisms for managing
authentication, encryption, and key distribution. These services include
• Authentication: Authentication is defined in the baseband specification but
involves the exchange of two LMP PDUs, one containing the random number
and one containing the signed response (Figure 15.14).
• Pairing: This service allows mutually authenticated users to automatically
establish a link encryption key. As a first step, an initialization key is generated
by both sides and used in the authentication procedure to authenticate that
the two sides have the same key. The initialization key is generated from a
common personal identification number (PIN) entered in both devices. The
two sides then exchange messages to determine if the link key to be used for
9In the LMP specification, each PDU name begins with LMP_. For example, the first PDU listed in
Table 15.7 has the name LMP_ accepted. For brevity, we omit the LMP_ prefix.
492 CHAPTER 15 / BLUETOOTHAND IEEE 802.15
Table 15.7 LMP PDUs
Function
General response
Authentication
Pairing
Change link key
Change current link key
Encryption
Clock offset request
Slot offset inf6rmation
Timing accuracy information
request
LMP versioIl
Supported features
Switch master/slave role
Name request
Detach
Roldmode
Sniff mode
Park mode
Power control
Channel quality-driven
change between DM and DR
Quality of service
sca links
Control of multislot packets
Paging scheme
Link supervision
PDUs
accepted, noCaccepted
Security Service
comh kp.v
encryption_mode_req, encryption_key_size_req,
starcencryption_req, stop_encryption_req
Tune/Synchronization
clkoffseCreq, clkoffset3es
SloCoffset
timinp- rp.a ttiimmiilnnlQ"!Laccurac:y__rreess ~ -~, ~

Station Capability
version ;."" -" res
~ . LontrOi
Switch. rea
name--req,name--res
detach
hold, hold rell
sniff, sniff_req, unsnifCreq
park_req, park, seCbroadcasCwindow, modify_beacon,
unparLPM ADDR req, unpark_BD_ADDR_req
incr power req, decr powecreq, max_power, min_power
auto rate. pre:'Eerred_rraalt'tee
quality_oCservice, quality_oCservice_req
max 'OInt m"Y slot rea
supervision_tiJn.eout
future encryptions will be a secret key already configured or a combination
key that is calculated based on the master's link key.
• Change link key: If two devices are paired and use a combination key, then
that key can be changed. One side generates a new key and sends it to the
other side XORed with the old link key. The other side accepts or rejects
the key.
15.4 / LINKM/\NAGER SPECIFICATION 493
Connection-oriented
data channel
Connectionless
data channel
~-------~
Signaling
channel
Device #1
L2CAP
Entity
L2CAP
Entity
Device #3
Figure 15.14 L2CAP Channels
Master
L2CAP
Entity(}------ {)
L2CAP
Entity
Device #4
Device #2
L2CAP
Entity
4& Change current link key: The current link key can be changed temporarily. The

exchange involves the use of random numbers and XOR calculations to generate
the temporary key, which is used for a single session.
4& Encryption: LMP is not directly involved in link encryption but provides services

to manage the encryption process. A number of parameters may be

negotiated, including the operating encryption mode (no encryption, point-topoint
only, point-to-point and broadcast), the size of the key, and the random
seed key use to start a new encryption session. LMP is also used to begin and
end the use of encryption.
LMP provides mechanisms for synchronizing the clocks in the various piconet
participants:
1II Clock offset request: When a slave receives the FRS packet, the difference is

computed between its own clock and the master's clock value included in the
payload of the FRS packet. The clock offset is also updated each time a packet
is received from the master. The master can request this clock offset anytime
during the connection. By saving this clock offset the master knows on what
RF channel the slave wakes up to PAGE SCAN after it has left the piconet.
This can be used to speed up the paging time the next time the same device
is paged.
• Slot offset information: An initiating device can transmit a message that
describes timing differences (time difference between slot boundaries) between
two adjacent piconets.
494 CHAPTER 15 / BLUETOOTHAND IEEE 802.15
• Timing accuracy information request: Used by a device to retrieve the accuracy
parameters of another device's timing subsystem. Parameters inclUde
long-term clock drift and clock jitter.
LMP includes two PDUs that are used to exchange information about the
communicating devices:
• LMPversion: Allows each LMP entity to determine the LMP version implemented
in the other. So far, there is only one version.
• Supported features: The Bluetooth radio and link controller may support only
a subset of the packet types and features described in Baseband Specification
and Radio Specification. The PDU LMP_features_req and LMP_features_res
are used to exchange this information. Table 15.8 lists the features that may be
exchanged.
A Bluetooth device has a number of states and modes that it can occupy. LMP
provides the following PDUs to manage these modes.
• Switch master/slave role: Allows a slave to become the master of the piconet.
For example, this is needed when a paging device must be the master. If a new
device needs to issue a page, it can use this service.
• Name request: Enables a device to request the text name of another device.
• Detach: Enables a device to remove itself from a connection. This can be issued
by either master or slave.
Table 15.8 LMP Supported Feature List
15.5 ! LOGICAL LINK CONTROL AND ADAPTATION PROTOCOL 495
$Hold mode: Places the link between a master and slave in hold mode for a
specified time.
• Sniff mode: To enter sniff mode, master and slave negotiate a sniff interval
T sniff and a sniff offset, D sniff, which specifies the timing of the sniff slots.
The offset determines the time of the first sniff slot; after that the sniff slots
follows periodically with the sniff interval T sniff.
• Park mode: Places a slave in park mode.
• Power control: Used by a device to direct another device to increase or decrease
the second device's transmit power.
s Channel quality-driven change between DM and DH: A device is configured
to use DM packets always or to use DR packets always or to adjust its packet
type automatically according to the quality of the channel. This service allows
an explicit change among these three alternatives. The difference between DM
and DR is that the payload in a DM packet is protected with a 2/3 FEC code,
whereas the payload of a DR is not protected with any FEC
• Quality of service: Two parameters define Bluetooth GoS. The poll interval,
which is the maximum time between transmissions from a master to a particular
slave, is used for capacity allocation and latency control. The number of repetitions
for broadcast packets (NBC). Broadcast packets are not acknowledged and
so the automatic retransmission of all broadcast packets improves reliability.
• SCQ links: Used to establish an SCQ link.
s Control of multislot packets: Arbitrates the maximum number of time slots a
packet can cover. The default value is one. This mechanism can be used to
select 3 or 5.
8 Paging scheme: Controls the type of paging scheme to be used between

devices on the piconet. There is a default scheme that is mandatory for implementation.
Additional optional schemes may be defined.
• Link supervision: Controls the maximum time a device should wait before
declaring the failure of a link.
Like Logical Link Control (LLC) in the IEEE 802 specification, L2CAP provides a
link-layer protocol between entities across a shared-medium network. As with LLC,
L2CAP provides a number of services and relies on a lower layer (in this case, the
baseband layer) for flow and error control.
L2CAP makes use of ACL links; it does not provide support for SCQ links.
Using ACL links, L2CAP provides two alternative services to upper-layer protocols:
• Connectionless service: This is a reliable datagram style of service.
• Connection-mode service: This service is similar to that offered by RDLC
A logical connection is set up between two users exchanging data, and flow
control and error control are provided.
496 CHAPTER 15 / BLUETOOTH AND IEEE 802.15
L2CAP Channels
L2CAP provides three types of logical channels:
• Connectionless: Supports the connectionless service. Each channel is unidirectional.
This channel type is typically used for broadcast from the master to
multiple slaves.
• Connection oriented: Supports the connection-oriented service. Each channel
is bidirectional (full duplex). A quality of service (QoS) flow specification is
assigned in each direction.
• Signaling: Provides for the exchange of signaling messages between L2CAP
entities.
Figure 15.14 provides an example of the use of L2CAP logical channels. Associated
with each logical channel is a channel identifier (CID). For connection-oriented
channels, a unique CID is assigned at each end of the channel to identify this connection
and associate it with an L2CAP user on each end. Connectionless channels are
identified by a CID value of 2, and signaling channels are identified by a CID value
of 1. Thus, between the master and any slave, there is only one connectionless channel
and one signaling channel, but there may be multiple connection-oriented channels.
L2CAP Packets
Figure 15.15 shows the format of L2CAP packets. For the connectionless service, the
packet format consists of the following fields:
• Length: Length of the information payload plus PSM fields, in bytes.
• Channel ID: A value of 2, indicating the connectionless channel.
o Protocol/service multiplexer (PSM): Identifies the higher-layer recipient for
the payload in this packet.
• Information payload: Higher-layer user data. This field may be up to 65533
(216
- 3) bytes in length.
Connection-oriented packets have the same format as connectionless packets,
but without the PSM field. The PSM field is not needed because the CID identifies
the upper-layer recipient of the data. The information payload field may be up to
65535 (216
- 1) bytes in length.
Signaling command packets have the same header format as the connectionoriented
packets. In this case, the CID value is 1, indicating the signaling channel.
The payload of a signaling packet consists of one or more L2CAP commands, each
of which consists of four fields:
o Code: Identifies the type of command.
o Identifier: Used to match a request with its reply. The requesting device sets this
field and the responding device uses the same value in its response. A different
identifier must be used for each original command.
o Length: Length of the data field for this command, in bytes.
• Data: Additional data, if necessary, relating to this command.
15.5 / LOGICAL LINK CONTROL AND ADAPTATION PROTOCOL 497
Octets: 2 2 2=2 oto 65533
Length ChannelID
(OxOO02) PSM Information
(a) Connectionless PDU
2 2 oto 65535
Length IChannel ID Information
(b) Connection-oriented PDU
22
Length ChannelID
(OxOOOl) 1 or more commands
(c) Signaling command PDU
1 1 2 2=0

~ o e tifier Length Data

(d) Command format
Figure 15.15 L2CAP Formats
Signaling C011:111:1ands
There are eleven commands in five categories (Table 15.9). The command reject
command can be sent in response to any command to reject it. Reasons for rejection
include invalid CID or length exceeded.
Connection commands are used to establish a new logical connection. The
request command includes a PSM value indicating the L2CAP user for this connection.
Three values are so far defined, for the service discovery protocol,
RFCOMM, and the telephony control protocol. Other PSM values are assigned
'fahle 15.9 L2CAP Signaling Command Codes
Code
OxOl
Ox02
Ox03
Ox04
Ox05
Ox06
Ox07
Ox08
Ox09
OxOA
OxOB
Description
Command reject
Connection request
Connection response
Configure request
Configure response
Disconnection request
Disconnection response
Echo request
Echoresp()nse
Information request
Information response
.
.
Parameters
Reason
PSM, Source CID
Destination pD,SourceCID, Result,Status
Destination CID, Flags, Options
SoutceGID, }<1ags,Result, Qptions
Destination CID, Source CID
DestinationCID,Sol.lrce CID
Data (optional)
Data (optional)
InfoType
InfoType, Resl.llt,Data (optional)
._ - _. ~--

498 CHAPTER 15 I BLUETOOTH AND IEEE 802.15

dynamically and are implementation dependent. The request command also
includes the CID value that will be assigned to this connection by the source. The
response command includes the source CID and the destination CID, the latter
assigned to this channel by the respondent. The result parameter indicates the outcome
(successful, pending, rejected) and, if the result is pending, the status field
indicates the current status that makes this a pending connection (e.g., authentication
pending, authorization pending).
Configure commands are sent to establish an initial logical link transmission
contract between two L2CAP entities and to renegotiate this contract whenever
appropriate. Each configuration parameter in a configuration request is related
exclusively to either the outgoing or the incoming data traffic. The request command
includes a flags field; currently the only flag is an indicator of whether additional
configuration commands will be sent. The options field contains a list of parameters
and their values to be negotiated. Each parameter is defined by three fields:
• Type (1 byte): The 7 least significant bits of this byte identify the option. If the
most significant bit is set to 0, the option is mandatory and, if not recognized,
the recipient must refuse the configuration request. If the most significant bit
is set to 1, the option is optional and may be ignored by the recipient.
.. Length (1 byte): The length of the option payload. A length of 0 indicates
no payload.
• Option payload: Further information about this option.
The following parameters may be negotiated:
• Maximum transmission unit (MTU): The largest L2CAP packet payload, in
bytes, that the originator of the request can accept for that channel.The MTU is
asymmetric and the sender of the request shall specify the MTU it can receive
on this channel if it differs from the default value. L2CAP implementations
must support a minimum MTU size of 48 bytes. The default value is 672 bytes.
This is not a negotiated value but simply informs the recipient of the size of
MTU that the sender of this request can accept.
• Flush timeout option: Recall in our discussion of the baseband specification
that as part of the ARQ mechanism, a payload will be flushed after failure on
repeated attempts to retransmit. The flush timeout is the amount of time the
originator will attempt to transmit an L2CAP packet successfully before giving
up and flushing the packet.
• Quality of service (QoS): Identifies the traffic flow specification for the local
device's traffic (outgoing traffic) over this channel. This parameter is described
in the following subsection.
In the latter two cases, a negotiation takes place, in which the recipient can
accept the flush timeout and QoS parameters or request an adjustment. The initial
sender can then accept or reject the adjustment.
The configure response command also includes a Flags field with the same meaning
as in the configuration request command. The Result field in the response command
indicates whether the preceding request is accepted or rejected. The Options
field contains the same list of parameters as from the corresponding request command.
15.5 I LOGICAL LINK CONTROL AND ADAPT/UION PROTOCOL 499
For a successful result, these parameters contain the return values for any wild card
parameters (see discussion of QoS, subsequently). For an unsuccessful result, rejected
parameters should be sent in the response with the values that would have been
accepted if sent in the original request.
The disconnection commands are used to terminate a logical channel.
The echo commands are used to solicit a response from a remote L2CAP entity.
These commands are typically used for testing the link or passing vendor-specific
information using the optional data field.
The information commands are used to solicit implementation-specific information
from a remote L2CAP entity.
Quality of Service
The QoS parameter in L2CAP defines a traffic flow specification based on RFC
1363.10 In essence, a flow specification is a set of parameters that indicate a
performance
level that the transmitter will attempt to achieve.
When included in a Configuration Request, this option describes the outgoing
traffic flow from the device sending the request to the device receiving it. When
included in a positive Configuration Response, this option describes the incoming
traffic flow agreement as seen from the device sending the response. When included
in a negative Configuration Response, this option describes the preferred incoming
traffic flow from the perspective of the device sending the response.
The flow specification consists of the following parameters:
GI Service type

• Token rate (bytes/second)

• Token bucket size (bytes)
" Peak bandwidth (bytes/second)
" Latency (microseconds)
Delay variation (microseconds)
(II

The service type parameter indicates the level of service for this flow. A value
of 0 indicates that no traffic will be transmitted on this channel. A value of 1 indicates
a best effort service; the device will transmit data as quickly as possible but
with no guarantees about performance. A value of 2 indicates a guaranteed service;
the sender will transmit data that conform to the remaining QoS parameters.
The token rate and token bucket size parameters define a token bucket scheme
that is often used in QoS specifications. The advantage of this scheme is that it provides
a concise description of the peak and average traffic load the recipient can
expect and it also provides a convenient mechanism by which the sender can implement
the traffic flow policy.
A token bucket traffic specification consists of two parameters: a token
replenishment rate R and a bucket size B. The token rate R specifies the continually
sustainable data rate; that is, over a relatively long period of time, the average
data rate to be supported for this flow is R. The bucket size B specifies the
lOA Proposed Flow Specification, RFC 1363, September 1992.
500 CHAPTER 15 / BLUETOOTH AND IEEE 802.15
Token rate =
R bytes per second
Current bucket
occupancy
Bucket size =
B bytes

Arriving ! n,parting

_d_at_a......,.~ , data.
Figure 15.16 Token Bucket Scheme
amount by which the data rate can exceed R for short periods of time. The exact
condition is as follows: During any time period T, the amount of data sent cannot
exceed RT + B.
Figure 15.16 illustrates this scheme and explains the use of the term bucket. The
bucket represents a counter that indicates the allowable number of bytes of data that
can be sent at any time. The bucket fills with byte tokens at the rate of R (i.e., the
counter is incremented R times per second), up to the bucket capacity (up to the
maximum counter value). Data arrive from the L2CAP user and are assembled into
packets, which are queued for transmission. A packet may be transmitted if there are
sufficient byte tokens to match the packet size. If so, the packet is transmitted and the
bucket is drained of the corresponding number of tokens. If there are insufficient
tokens available, then the packet exceeds the specification for this flow. The treatment
for such packets is not specified in the document; typically, the packet will
simply be queued for transmission until sufficient tokens are available.
Over the long run, the rate of data allowed by the token bucket is R. However,
if there is an idle or relatively slow period, the bucket capacity builds up, so that at
most an additional B bytes above the stated rate can be accepted. Thus, B is a measure
of the degree of burstiness of the data flow that is allowed.
For L2CAP, a value of zero for the two parameters implies that the token
scheme is not needed for this application and will not be used. A value of all 1s is the
wild card value. For best effort service, the wild card indicates that the requestor wants
as large a token or as large a token bucket size, respectively, as the responder will
grant. For guaranteed service, the wild card indicates that the maximum data rate or
bucket size, respectively, is available at the time of the request.
The peak bandwidth, expressed in bytes per second, limits how fast packets
may be sent back-to-back from applications. Some intermediate systems can take
advantage of this information, resulting in more efficient resource allocation. Consider
that if the token bucket is full, it is possible for the flow to send a series of
15.6 / IEEE 802.15 501
back-to-back packets equal to the size of the token bucket. If the token bucket size
is large, this back-to-back run may be long enough to exceed the recipient's capacity.
To limit this effect, the maximum transmission rate bounds how fast successive
packets may be placed on the network.
The latency is the maximum acceptable delay between transmission of a bit by
the sender and its initial transmission over the air, expressed in microseconds.
The delay variation is the difference, in microseconds, between the maximum
and minimum possible delay that a packet will experience. This value is used by
applications to determine the amount of buffer space needed at the receiving side
in order to restore the original data transmission pattern. If a receiving application
requires data to be delivered in the same pattern that the data were transmitted, it
may be necessary for the receiving host briefly to buffer data as they are received
so that the receiver can restore the old transmission pattern. An example of this is
a case where an application wishes to send and transmit data such as voice samples,
which are generated and played at regular intervals. The amount of buffer
space that the receiving host is willing to provide determines the amount of variation
in delay permitted for individual packets within a given flow.
The IEEE 802.15 Working Group for Wireless Personal Area Networks (PANs) was
formed to develop standards for short range wireless PANs (WPANs).A PAN is
communications
network within a small area in which all of the devices on the network
are typically owned by one person or perhaps a family. Devices on a PAN may include
portable and mobile devices, such as PCs, Personal Digital Assistants (PDAs),
peripherals,
cell phones, pagers, and consumer electronic devices. The first effort by the
working group was to develop 802.15.1, with the goal of creating a formal standard of
the Bluetooth specification; this standard was approved in 2002.
Because most or all of the planned 802.15 standards would operate in the same
frequency bands as used by 802.11 devices, both the 802.11 and 802.15 working
groups were concerned about the ability of these various devices to successfully
coexist. The 802.15.2 Task Group was formed to develop recommended practices for
coexistence. This work resulted in a recommended practices document in 2003.
Following the 802.15.1 standard, the 802.15 work went in two directions. The
802.15.3 task group is interested in developing standards for devices that are low
cost and low power compared to 802.11 devices, but with significantly higher data
rates than 802.15.1. An initial standard for 802.15.3 was issued in 2003 and, as of this
writing, work continues on 802.15.3a, which will provide higher data rates than
802.15.3, using the same MAC layer. Meanwhile, the 802.15.4 task group developed
a standard for very low cost, very low power devices at data rates lower than
802.15.1, with a standard issued in 2003.
Figure 15.17 shows the current status of the 802.15 work. Each of the three
wireless PAN standards has not only different physical layer specifications but different
requirements for the MAC layer. Accordingly, each has a unique MAC specification.
Figure 15.18, based on one in [ZHEN04], gives an indication of the relative
scope of application of the wireless LAN and PAN standards. As can be seen,
502 CHAPTER 15 / BLUETOOTH AND IEEE 802.15
802.15.1
2.4GHz
1Mbps
Figure 15.17 IEEE 802.15 Protocol Architecture
the 802.15 wireless PAN standards are intended for very short range, up to about
10 m, which enables the use of low power, low cost devices.
This section provides an overview of 802.15.3 and 802.15.4.
IEEE 802.15.3
The 802.15.3 task group is concerned with the development of high data rate
WPANs. Examples of applications that would fit a WPAN profile but would also
require a relatively high data rate include [GILB04]
>UOMbps } WPAN
~
l-<

,§ Q lt054
Mbps
1 Mbps
20 to 250
kbps
o 10
Indoor range (m)
n x 100
WLAN
WPAN
Figure 15.18 Wireless Local Networks
15.6 / IEEE 802.15 503
• Connecting digital still cameras to printers or kiosks
• Laptop to projector connection
• Connecting a personal digital assistant (PDA) to a camera or PDA to a printer
• Speakers in a 5:1 surround-sound system connecting to the receiver
• Video distribution from a set-top box or cable modem
• Sending music from a CD or MP3 player to headphones or speakers
• Video camera display on television
• Remote view finders for video or digital still cameras
These applications are mainly in the consumer electronics area and generate
the following requirements:
• Short range: On the order of 10m.
• High throughput: Greater than 20 Mbps to support video and/or multichannel
audio.
• Low power usage: To be useful in battery-powered portable devices.
• Low cost: To be reasonable for inexpensive consumer electronic devices.
• QoS (quality of service) capable: To provide guaranteed data rate and other
OoS features for applications sensitive to throughput or latency.
• Dynamic environment: Refers to a piconet architecture in which mobile,
portable, and stationary devices enter and leave the piconet often. For mobile
device, a speed of less than 7 kilometers per hour is addressed.
• Simple connectivity: To make networking easy and eliminate the need for a
technically sophisticated user.
• Privacy: To assure the user that only the intended recipients can understand
what is being transmitted.
These requirements are not readily met with an IEEE 802.11 network, which
was not designed with this set of applications and requirements in mind.
Mediuul Access Control An 802.15.3 network consists of a collection of devices
(DEVs). One of the DEVs also acts as a piconet coordinator (PNC). The PNC
assigns time for connections between devices; all commands are between the PNC
and DEVs. Note the contrast between a PNC and an 802.11 access point (AP). The
AP provides a link to other networks and acts as a relay point for all MAC frames.
The PNC is used to control access to the time resources of the piconet and is not
involved in the exchange of data frames between DEVs.
The OoS feature of the 802.15.3 MAC layer is based on the use of a TDMA
(time division multiple access) architecture with the provision of guaranteed time
slots (GTSs).
Physical Layer The 802.15.3 physical layer operates in the 2.4-GHz band, using
five modulation formats with an 11 Mbaud symbol rate to achieve data rates from
11 to 55 Mbps. Table 15.10 summarizes the key parameters. The most significant
aspect of the scheme is the use of trellis-coded modulation (TCM). TCM is an old
504 CHAPTER 15 / BLUETOOTHAND IEEE 802.15
Table 15.10 IEEE 802.15.3 Physical Layer Characteristics
QPSK = quadrature phase-shift keying
DQPSK = differential QPSK
QAM = quadrature amplitude modulation
TCM = trellis-coded modulation
technique, used in voice-grade telephone network modems. In the remainder of this
subsection, we provide an overview ofTCM.
Before proceeding, we briefly review some definitions from Chapter 6
(Table 6.1).A bit is the fundamental unit that takes on the values 0 or 1. A signal
element,
or symbol, is that part of a signal that occupies the shortest interval of a signaling
code; typically, it is a pulse of constant frequency, phase, and amplitude and
may represent one or more bits. The signaling rate is measured in signaling elements
per second, or baud.
In all of the approaches to transmission that we have seen so far in this book,
signal encoding, or modulation, is performed separately from encoding for forward
error correction. Furthermore, error control is achieved by adding additional bits to
the data bits, which has the effect of lower the data transmission rate per channel
bandwidth. When faced with a combination of a channel of limited bandwidth and a
high data rate requirement, an effective approach is to combine modulation and
coding and treat them as a single entity. This approach is referred to asTCM and has
three basic features: .
1. The number of different signal elements used is larger than what is required
for the given modulation scheme and data rate. The additional signal elements
allow redundancy for forward error correction without sacrificing
data rate.
2. Convolutional coding is used to introduce dependency between successive signal
elements, such that only certain sequences of signal elements are allowed.
3. Decoding is done by modeling the coder as a trellis and using a Viterbi-type
decoding algorithm to perform error correction.
The concepts mentioned in points (2) and (3) are discussed in Section 8.3.
Recall that the convolutional code gives rise to a state transition diagram that can
be laid out in a trellis pattern. Also, decoding involves use of a Viterbi algorithm,
typically with a metric based on Hamming distance. In the case of TCM, the metric
used is Euclidean distance. We next explain these concepts using a simple example
based on a QPSK modulation scheme. Keep in mind that TCM can be used with
more complex modulation schemes, such as QAM.