|
This is the most comprehensive part of the Bluetooth protocol and one
which is most important. This tutorial page touches the different aspects
of baseband only very briefly. For more information on the subject in
context, please click More .. on the right side wherever the
link is provided.
Baseband
Baseband is the physical layer of the Bluetooth which manages physical
channels and links apart from other services like error correction, data
whitening, hop selection and Bluetooth security. Baseband lies on top of
Bluetooth radio in Bluetooth stack and essentially
acts as a link controller and works with link manager for carrying out
link level routines like link connection and power control. Baseband also
manages asynchronous and synchronous links, handles packets and does
paging and inquiry to access and inquire the Bluetooth devices. Baseband
transceiver applies a time-division duplex (TDD) scheme. (alternate
transmit and receive). Therefore apart from different hopping frequency
(frequency division), the time is also slotted. In the normal connection
mode, the master shall always start at even numbered slots and slave
transmission shall always start at odd numbered slots (though they may
continue to transmit regardless of the number of the slot).
ACL and SCO links
Baseband handles two types of
links : SCO (Synchronous Connection-Oriented) and ACL (Asynchronous
Connection-Less) link. The SCO link is a symmetric point-to-point link
between a master and a single slave in the piconet. The master maintains
the SCO link by using reserved slots at regular intervals (circuit
switched type). The SCO link mainly carries voice information. The master
can support up to three simultaneous SCO links while slaves can support
two or three SCO links. SCO packets are never retransmitted. SCO packets
are used for 64 kB/s speech transmission.
The ACL link is a point-to-multipoint link between the master and all
the slaves participating on the piconet. In the slots not reserved for the
SCO links, the master can establish an ACL link on a per-slot basis to any
slave, including the slave already engaged in an SCO link (packet switched
type). Only a single ACL link can exist. For most ACL packets, packet
retransmission is applied.
Logical Channels
Bluetooth has five logical channels which can be used to transfer
different types of information. LC (Control Channel) and LM (Link Manager)
channels are used in the link level while UA, UI and US channels are used
to carry asynchronous, isosynchronous and synchronous user information.
Bluetooth Addressing
There are basically four types of device addresses in Bluetooth:
| BD_ADDR |
48 bit Bluetooth
device address (IEEE802 standard). It is divided into LAP (Lower
Address Part of 24 bits), UAP (Upper Address Part of 8 bits) and NAP
(Non-significant Address Part of 16 bits). |
| AM_ADDR |
3 bit active member
address. The all zero AM_ADDR is for broadcast messages. |
| PM_ADDR |
8-bit member
address that is assigned to parked slaves. |
| AR_ADDR |
The access request
address is used by the parked slave to determine the slave-to-master
half slot in the access window it is allowed to send access
messages. |
Bluetooth packets
The data on the piconet channel is conveyed in packets. The general
packet is shown below:
| A standard blueooth packet |
| ACCESS CODE [72] |
HEADER [54] |
PAYLOAD [0-2745] |
Access code are used for timing synchronization, offset compensation,
paging and inquiry. There are three different types of Access code:
Channel Access Code (CAC), Device Access Code (DAC) and Inquiry Access
Code (IAC). The channel access code identifies a piconet (unique for a
piconet) while DAC is used for paging and its responses. IAC is used for
inquiry purposes. The header contains information for packet
acknowledgement, packet numbering for out-of-order packet reordering, flow
control, slave address and error check for header. The packet payload can
contain either voice field, data field or both. The packet can occupy more
than one slot (multi-slot packets) and can continue transmission in the
next slot. The payload also carries a 16-bit CRC for error detection and
correction in the payload. SCO packets do not include CRC.
There are five common types of packet, four SCO packets and seven ACL
packets. There brief description is given below. For more information
click More ..
| TYPE |
NAME |
DESCRIPTION |
| Common |
ID |
Carries device
access code (DAC) or inquiry access code (IAC). Occupies one slot. |
| Common |
NULL |
NULL packet has no
payload. Used to get link information and flow control. Occupies one
slot. Not acknowledged. |
| Common |
POLL |
No payload.
Acknowledged. Used by master to poll the slaves to know whether they
are up or not. Occupies one slot. |
| Common |
FHS |
A special control
packet for revealing Bluetooth device address and the clock of the
sender. Used in page master response, inquiry response and frequency
hop synchronization. Ocuupies one slot. 2/3 FEC encoded. |
| Common |
DM1 |
To support control
messages in any link type. can also carry regular user data.
Occupies one slot. |
| SCO |
HV1 |
Carries 10
information bytes. Typically used for voice transmission. 1/3 FEC
encoded. Occupies one slot. |
| SCO |
HV2 |
Carries 20
information bytes. Typically used for voice transmission. 2/3 FEC
encoded. Occupies one slot. |
| SCO |
HV3 |
Carries 30
information bytes. Typically used for voice transmission. Not FEC
encoded. Occupies one slot. |
| SCO |
DV |
Combined data-voice
packet. Voice field not protected by FEC. Data field 2.3 FEC
encoded. Voice fiels is never retransmitted but data field can be. |
| ACL |
DM1 |
Carries 18
information bytes. 2/3 FEC encoded. Occupies one slot. |
| ACL |
DH1 |
Carries 28
information bytes. Not FEC encoded. Occupies one slot. |
| ACL |
DM3 |
Carries 123
information bytes. 2/3 FEC encoded. Occupies three slots. |
| ACL |
DH3 |
Carries 185
information bytes. Not FEC encoded. Occupies three slots. |
| ACL |
DM5 |
Carries 226
information bytes. 2/3 FEC encoded. Occupies five slots. |
| ACL |
DH5 |
Carries 341
information bytes. Not FEC encoded. Occupies five slots. |
| ACL |
AUX1 |
Carries 30
information bytes. Resembles DH1 but no CRC code. Occupies one slot. |
More ..
Error correction
There are three kinds of error correction schemes: 1/3 rate
FEC, 2/3 rate FEC and ARQ scheme. In 1/3 rate FEC every bit is repeated
three times for redundancy, in 2/3 a generator polynomial is used to encode
10 bit code to a 15 bit code, and in ARQ scheme a packet is retransmitted
till an acknowledgement is received (or timeout is exceeded). Bluetooth uses
fast, unnumbered acknowledgement in which it uses positive and negative
acknowledgements by setting appropriate ARQN values. If timeout is exceeded,
Bluetooth flushes the packet and proceeds with the next.
Bluetooth Controller
Flow control and synchronization
Bluetooth recommends using FIFO queues in ACL and SCO links
for transmission and receive. Link Manager fills these queues and link
controller empties the queues automatically.

If these RX FIFO queues are full, flow control is used to
avoid dropped packets and congestion. If data cannot be received, a STOP
indication is transmitted inserted by the Link Controller of the receiver
into the header of the return packet. When the transmitter receives the STOP
indication, it freezes its FIFO queues. If receiver is ready it sends a GO
packet which resumes the flow again.
We already know that Bluetooth transceiver uses a
time-division duplex (TDD) scheme. This means that it alternately transmits
and receives in a synchronous manner. The average timing of master packet
transmission must not drift faster than 20 ppm relative to the ideal slot
timing of 625 microseconds. Jitter from average timing should be less than 1
microsecond. The piconet is synchronized by the system clock of the master.
The Bluetooth Device Address (BD_ADDR) of the master determines the
frequency hopping sequence and the channel access code; the system clock of
the master determines the phase in the hopping sequence. Master controls the
traffic on the channel by a polling scheme. The master never adjusts its
system clock during the existence of the piconet. The slaves adapt their
native clocks with a timing offset in order to match the master clock. The
Bluetooth clocks should have a resolution of 312.5 microseconds.
A 20 microsecond uncertainty window is allowed around the
exact receive time in order for the access correlator for the receiver to
search for the correct channel access code and get synchronized with the
transmitter. When a slave returns from the hold mode, it can correlate over
a bigger uncertainty window till they dont overlap slots. A parked slave
periodically wakes up to listen to beacons from the master and
re-synchronizes its clock offset.
Controller States
Bluetooth controller operates in two major states: Standby
and Connection . There are seven substates which are used to add
slaves or make connections in the piconet. These are page, page scan,
inquiry, inquiry scan, master response, slave response and inquiry response .

The Standby state is the default low power state in
the Bluetooth unit. Only the native clock is runnning and there is no
interaction with any device whatsoever. In the Connection state, the
master and slave can exchange packets. using the channel (master) access
code and the master Bluetooth clock. The hopping scheme used is the channel
hopping scheme.
Normally, a connection between two devices occur in the
following fashion. First master uses the GIAC and DIAC to inquire about the
Bluetooth devices in the range (Inquire substate). If any nearby Bluetooth
device is listening for these inquiries (Inquiry scan substate), it responds
to the master by sending its address and clock information (FHS packet) to
the master (Inquiry response substate). After sending the information, the
slave may start listening for page messges from the master (Page scan). The
master after discovering the in range Bluetooth devices may page these
devices (Page substate) for connection setup. The slave in page scan mode if
paged by this master will respond (Slave response substate) with its device
access code (DAC). The master after receiving the response from the slave,
may respond by transmitting the master's real time clock, master's BD_ADDR,
the BCH parity bits and the class of the device (FHS packet). After slave
has received this FHS packet, both enter into Connection state.

Below we describe each of these states briefly:
|
Page
|
This substate is used by the master to activate and
connect to a slave. Master sends page messages by transmitting slave's
device access code (DAC) in different hop channels.
|
|
Page scan
|
In this substate, a slave listens for its own device
access code (DAC) for a duration of scan window. The slave listens at
a single hop frequency (derived from its page hopping sequence) in
this scan window
|
|
Slave response
|
Slave responds to master's page message in this
substate which is resulted if slave correlates in the page scan
substate to the master's page message. Slave enters Connection state
after receiving FHS packet from master.
|
|
Master response
|
Master reaches this substate after it receives slave's
response to its page message for it. Master sends a FHS packet to
slave and if slave replies then master enters Connection state.
|
|
Inquiry
|
Inquiry is used to find the identity of the Bluetooth
devices in the close range. The discovering unit collects the
Bluetooth device addresses and clocks of all units that respond to the
inquiry message.
|
|
Inquiry scan
|
In this state, the Bluetooth devices are listening for
inquiries from other devices. In this scanning device may listen for
general inquiry access code (GIAC) or dedicated inquiry access codes
(DIAC).
|
|
Inquiry response
|
For inquiry, only slave responds but not the master.
The slave responds with the FHS packet which contains the slave's
device access code, native clock and some other slave information.
|
Connection States
The Connection state starts with a POLL packet sent
by the master to verify that slave has switched to the master's timing and
channel frequency hopping. Th slave can respond with any type of packet.
A Bluetooth device in Connection state can be in any
of the four following states: Active, Hold, Sniff and Park mode.
One of the challenges in Bluetooth is to move between these states
especially from Park to Active and vice versa. These modes are described
briefly below:
|
Active
|
In this mode both master and
slave partcipate actively on the channel by listening, transmitting or
receiving the packets. Master and slave are kept synchronized to each
other.
|
|
Sniff
|
In this mode slave rather than
listening on every slot for master's message for that slave, sniffs on
specified time slots for its messages. Hence the slave can go to sleep
in the free slots thus saving power.
|
|
Hold
|
In this mode, a device can
temporarily not support ACL packets and go to low power sleep mode to
make the channel available for things like paging, scanning etc.
|
|
Park
|
When a slave does not need to
participate on the piconet channel, but still wants to remain
synchronized to the channel. it can enter park mode which is a low
power mode with very little activity. The device is given a Parking
Member Address (PM_ADDR) and it losses its Active Member Address
(AM_ADDR).
|
Bluetooth Security
Bluetooth security
is an important if we have to allow keyless doors and automatic billing in
super-stores. At the link layer, security is maintained by authentication of
the peers and encryption of the information. For this basic security we need
a public address which is unique fro each device (BD_ADDR), two secret keys
(authentication keys and encryption key) and a random number generator.
First a device does the authentication by issuing a challenge and the other
device has to then send a response to that challenge which is based on the
challenge, it's BD_ADDR and a link key shared between them. After
authentication, encryption may be used to communicate.
There are four types of link keys: combination key, unit
key, temporary key and initialization key .
Move to Link Manager
After looking at the Baseband and its various important
features, lets move to understanding Link Manager Protocol
(LMP) which is a link layer above Baseband.
|