Bluetooth

Bluetooth
Contents at a Glance
Part ONE
Part TWO
Part THREE
Bluetooth Basics
xi
CHAPTER 1
What is Bluetooth?
CHAPTER 2
Technical Overview
Bluetooth Protocol and Network Aspects
10
CHAPTER 1
Bluetooth Protocol
11
CHAPTER 2
Radio Interface
13
CHAPTER 3
Baseband / Link Controller
18
CHAPTER 4
Link Manager Protocol
38
CHAPTER 5
Host Controller Interface
54
CHAPTER 6
Logical Link Control and Adaptation Protocol
80
CHAPTER 7
RFCOMM
96
CHAPTER 8
Service Discovery Protocol
105
CHAPTER 9
Telephony Control Protocol
112
CHAPTER 10
WAP, OBEX and IrDA
128
Bluetooth Profiles
136
CHAPTER 1
137
Profiles
i
Amplify Mindware
Table of Contents
Part ONE
Bluetooth Basics
CH. 1
Xi
What is Bluetooth?
1.1
Introduction
1.1.1
Open specification
1.1.2
Short-range wireless
1.1.3
Voice and data
1.1.4
Anywhere in the world
1.2
1.3
The Bluetooth Special Interest Group
1.2.1
Technology and SIG Origins
1.2.2
SIG Progression
The Bluetooth Name and History
Summary
CH. 2
Technical Overview
2.1
The Aim of Bluetooth
2.2
Features
2.3
Bluetooth Components
2.4
Bluetooth comparisons with other wireless technologies
Summary
Part TWO
Bluetooth Protocol and Network Aspects
10
CH. 1
Bluetooth Protocol
11
1.1
Protocol Architecture
11
1.2
Layer Functions
12
CH. 2
Radio Interface
13
2.1
Transmitter Characteristics
13
2.1.1
13
Frequency Hopping
2.1.2
Modulation
14
2.1.3
Spurious Emissions
15
ii
Amplify Mindware
2.1.4
15
Frequency Tolerance
2.2
15
Receiver Characteristics
2.2.1
15
Sensitivity Level
2.2.2
Interference Performance
15
2.2.3
Out-of-Band Blocking
16
2.2.4
Maximum Usable Level
16
2.2.5
Receiver Signal Strength Indicator
16
2.2.6
Interference Signal
16
Summary
17
CH. 3
18
3.1
Introduction
18
3.2
Physical Channel
19
3.2.1
19
3.3
3.4
3.5
Time Slots
Physical Links
20
3.3.1
SCO Link
20
3.3.2
ACL Link
21
Packets
22
3.4.1
Access Code
22
3.4.2
Packet Header
23
3.4.3
Payload
24
3.4.4
Packet Types
25
Error Correction
27
3.5.1
1/3 rate FEC
28
3.5.2
2/3 rate FEC
28
3.5.3
ARQ scheme
28
3.6
Data Whitening or bit randomization
29
3.7
Logical Channels
29
3.7.1
LC Control Channel
29
3.7.2
LM Control Channel
29
3.7.3
UA/UI Channel
29
iii
Amplify Mindware
3.7.4
3.8
3.9
3.10
US Channel
30
Channel Control
30
3.8.1
Bluetooth Clock
30
3.8.2
Clock Types
31
3.8.3
States
31
3.8.4
Access Procedures
32
3.8.5
Inquiry Procedures
33
3.8.6
Connection Modes
33
3.8.7
Scatternet
34
Audio
34
3.9.1
LOG PCM Codec
35
3.9.2
CVSD Codec
35
Bluetooth Addressing
35
Summary
37
CH. 4
38
4.1
Introduction
38
4.2
Format of LMP
38
4.3
The Procedure Rules and PDUs
39
4.3.1
General Response Messages
40
4.3.2
Authentication
40
4.3.3
Pairing
41
4.3.4
Change Link Key
41
4.3.5
Change the Current Link Key
41
4.3.6
Encryption
42
4.3.7
Clock Offset Request
42
4.3.8
Slot Offset Information
42
4.3.9
Time Accuracy Information Request
43
4.3.10
LMP Version
43
4.3.11
Supported Features
44
4.3.12
Switch of Master-Slave Role
45
4.3.13
Name Request
45
iv
Amplify Mindware
4.4
4.3.14
Detach
46
4.3.15
Hold Mode
46
4.3.16
Sniff Mode
46
4.3.17
Park Mode
47
4.3.18
Power Control Mode
48
4.3.19
Channel Quality-Driven Change between DM & DH
49
4.3.20
QOS
49
4.3.21
SCO Links
50
4.3.22
Multi-Slot Packets
50
4.3.23
Paging
51
Connection Establishment
51
Summary
53
CH. 5
54
5.1
Introduction
54
5.2
Bluetooth Hardware Block Diagram
56
5.3
HCI Packet Types
58
5.3.1
Command Packets
59
5.3.2
Event Packets
59
5.3.3
Data Packets
60
5.4
Commands and Events
60
5.4.1
Link Control Commands
60
5.4.2
Link Policy Commands
63
5.4.3
Host Controller and Baseband Commands
64
5.4.4
Informational parameters
69
5.4.5
Status Parameters
70
5.4.6
Testing Commands
71
5.5
Events
71
5.6
Flow Control
74
5.7
Host Controller Transport Layer
76
5.7.1
USB Transport Layer
76
5.7.2
Serial Transport Layer
77
v
Amplify Mindware
5.7.3
UART Transport Layer
77
5.7.4
RS232 Transport Layer
78
Summary
79
CH.6
80
6.1
Introduction
80
6.1.1
81
6.2
6.3
6.4
L2CAP Functional Requirements
General Operations
82
6.2.1
Channels and channel Identifiers
82
6.2.2
Operation between Devices
82
6.2.3
SAR
84
L2CAP State Machines
84
6.3.1
Events
86
6.3.2
Actions
88
Data Packet
90
6.4.1
Connection-Oriented Channel
90
6.4.2
Connectionless Channel
90
6.5
Signaling
91
6.6
Service Primitives
92
6.6.1
92
Some Service Primitives
Summary
95
CH.7
RFCOMM
96
7.1
Introduction
96
7.1.1
96
7.2
Device Types
Service Overview
97
7.2.1
RS232 Control Signals
97
7.2.2
Null Modem Emulation
97
7.2.3
Multiple Emulated Serial Ports between two devices
98
7.2.4
Multiple Emulated Serial Ports between more devices
98
7.3
Service Definition Model
99
7.4
TS 07.10 Subset Support by RFCOMM and its Adaptation
99
7.5
TS 07.10 Adaptations
100
vi
Amplify Mindware
7.6
7.5.1
Basic Option Frame
100
7.5.2
TS 07.10 Multiplexer Startup & Closedown Procedure
101
7.5.3
Multiplexer commands
102
Flow Control
102
7.6.1
L2CAP Flow Control
102
7.6.2
Wired Serial Port Flow Control
102
7.6.3
RFCOMM Flow Control
102
7.6.4
Port Emulation Entity Serial Flow Control
102
Summary
104
Ch.8
105
8.1
Introduction
105
8.1.1
105
8.2
8.3
SDP Client-Server Interaction
SDP Services
106
8.2.1
Service Record
106
8.2.2
Service Attribute
107
8.2.3
Service Class
107
8.2.4
Data Elements
107
8.2.5
Service Search
108
8.2.6
Browsing for Services
108
Protocol Description
109
8.3.1
Partial Responses and Continuation State
109
8.3.2
Error Handling
109
8.3.3
Service Search Transaction
110
8.3.4
Service Attribute Transaction
110
8.3.5
Service Search Attribute Transaction
110
Summary
111
CH.9
112
9.1
Introduction
112
9.1.1
Operation between Devices
112
9.1.2
Operation Between Layers
114
9.2
Call Control
115
vii
Amplify Mindware
9.3
Part THREE
9.2.1
Call Establishment
115
9.2.2
Call Clearing
118
Group management
120
9.3.1
Wireless User Group
120
9.3.2
Obtain Access Rights
120
9.3.3
Configuration Distribution
121
9.3.4
Fast Inter-Message Access
122
9.4
Connectionless TCS
124
9.5
Supplementary Services
124
9.5.1
Call Line Identity
124
9.5.2
DTMF Start & Stop
125
9.5.3
Register Recall
126
Summary
127
CH.10
WAP, OBEX and IrDA
128
10.1
Wireless Application Protocol
128
10.2
WAP in Bluetooth
128
10.2.1
Initiation by Client Device
129
10.2.2
Termination by Client Device
129
10.2.3
Initiation by Server Device
129
10.3
Network Support for WAP
130
10.4
Interpretability Requirements
130
10.4.1
Stage 1 Basic Interoperability
130
10.4.2
Stage 2 Advanced Interoperability
131
10.5
OBEX and IrDA
131
10.6
OBEX Object and Protocol
132
10.6.1
133
Session Protocol
10.7
OBEX over RFCOMM
134
10.8
OBEX over TCP/IP
134
Summary
135
Bluetooth Profiles
136
CH. 1
137
Profiles
viii
Amplify Mindware
1.1
Introduction
137
1.2
Generic Access Profile (GAP)
138
1.2.1
138
Operation Modes
1.3
Serial Port Profile (SPP)
139
1.4
Dial up networking profile
140
1.5
FAX Profile
140
1.6
Headset Profile
141
1.7
LAN Access Profile
141
1.8
Generic Object Exchange Profile (GOEP)
142
1.9
File Transfer Profile
142
1.10
Object Push Profile
142
1.11
Synchronization Profile
142
1.12
Intercom Profile
143
1.13
Cordless Telephony Profile
143
Summary
144
References
145
Further Reading/ Information Resources
146
ix
Amplify Mindware
Preface
The Bluetooth specification was originally developed by Ericsson in 1994 as a
short-range wireless technology for cable replacement. Since then, the specification
was adopted by several companies, which formed a trade association that is now known
as the Bluetooth Special Interest Group (SIG). In recent years, Bluetooth has grown
from a wireless cable replacement solution to incorporating virtually all types of wireless
applications including voice, data and multimedia.
Topics covered will be the design of the components that comprise the Bluetooth
Module protocol stack including the RF/Baseband layers, the Link Controller and
Manager Layers and the Host Controller Interface Layer. The Bluetooth Host stack will
also be covered including the Logical Link Control and Adaptation Protocol layer, the
RFCOMM layer, the Service Discovery layer and the Bluetooth Profiles. The protocol
stack also has provisions for QOS, security and power control that will also be
discussed. Bluetooth compared with other wireless technologies are also discussed.
x
Amplify Mindware
P A R T O NE
I N T RO D U C TI ON
T O T HE T EC H N O LO G Y
xi
Amplify Mindware
Bluetooth
Chapter One
What is Bluetooth?
What is Bluetooth?
1.1 INTRODUCTION
The term Bluetooth refers to an open specification for a technology to enable
short-range wireless voice and data communications anywhere in the world. This simple
and straightforward description of the Bluetooth technology includes several points that
are important to its understanding:
1.1.1 OPEN SPECIFICATION
The Bluetooth Special Interest Group (SIG) has produced a specification for
Bluetooth wireless communication that is publicly available and royalty free. To help
foster widespread acceptance of the technology, a truly open specification has been a
fundamental objective of the SIG since its formation.
1.1.2 SHORT-RANGE W IRELESS
There are many instances of short-range digital communication among
computing and communications devices; today much of that communication takes place
through cables. These cables connect to a mass of devices using a wide variety of
connectors with many combinations of shapes, sizes and number of pins; this can
become quite burdensome to users.
With Bluetooth technology, these devices can communicate without wires over a
single air-interface, using radio waves to transmit and receive data. Bluetooth wireless
technology is specifically designed for short-range nominally 10 meters communications;
one result of this design is very low power consumption, making the technology well
suited for use with small, portable personal devices that typically are powered by
batteries.
1.1.3 VOICE AND DATA

Traditional lines between computing and communications environments are
continually becoming less distinct. Voice is now commonly transmitted and stored in
digital formats. Voice appliances such as mobile telephones are also used for data
1
Amplify Mindware
Bluetooth
What is Bluetooth?
applications such as information access or browsing. Through voice recognition,

computers can be controlled by voice, and through voice synthesis, computers can
produce audio output in addition to visual output. Some wireless communication
technologies are designed to carry only voice while others handle only data traffic.
Bluetooth wireless communication makes provisions for both voice and data, and thus it
is an ideal technology for unifying these worlds by enabling all sorts of devices to
communicate using either or both of these content types.
1 .1 .4 AN YW HE R E IN TH E W ORL D
The telecommunications industry is highly regulated in many parts of the world.
Telephone systems, for example, must comply with many governmental restrictions, and
telephony standards vary by country. Many forms of wireless communications are also
regulated; radio frequency spectrum usage often requires a license with strict
transmission power obligations. However, some portions of the available radio frequency
spectrum may be used without license, and Bluetooth wireless communications operate
within a chosen frequency spectrum that is unlicensed throughout the world. Thus
devices that employ Bluetooth wireless communication can be used unmodified, no
matter where a person might be.
The Bluetooth short-range wireless technology is ideally suited for replacing the
many cables that are associated with todays pervasive devices. The Bluetooth
specification explicitly defines a means for wireless transports to replace serial cables,
such as those used with modems, digital cameras and personal digital assistants; the
technology could also be used to replace other cables, such as those associated with
computer peripherals including printers, scanners, keyboards, mice and others.
Moreover, wireless connectivity among fixed and mobile devices can enable many other
new and exciting usage scenarios beyond simple cable replacement.
1.2 THE BLUETOOTH SPECIAL INTEREST GROUP

Bluetooth wireless communication is embodied as a technology specification.
This specification is a result of the cooperation of many companies within an
organization called the Bluetooth Special Interest Group, or SIG. There is no Bluetooth
headquarters nor is there neither any Bluetooth corporation nor any sort of legally
incorporated entity. The SIG is governed by legal agreements among the member
parties but it is not a company unto itself. The SIG should not be construed as a formal
2
Amplify Mindware
Bluetooth
What is Bluetooth?
standards body; rather it is an organization chartered to define and promote the

technology. In fulfilling this charter the SIG is dependent upon the contributions and
participation of its member companies. Clearly a major task of the SIG has been to
develop the specification, but other SIG activities include joint work with other consortia
and standards and regulatory bodies, educational and promotional events such as
developers conferences and the definition of a testing and certification process.
1.2.1 TECHNOLOGY AND SIG ORIGINS
Bluetooth wireless technology was conceived by engineers at Swedish
telecommunications manufacturer Telefonaktiebolaget LM Ericsson (hereafter, Ericsson)
who realized the potential of global short-range wireless communications. In 1994
Ericsson had begun a project to study the feasibility of a low-power and low-cost radio
interface to eliminate cables between mobile phones and their accessories.
In early 1998, leading companies in the computing and telecommunication
industries formed the Bluetooth SIG to focus on developing exactly such an open
specification. The founding companies of the SIG are Ericsson, Intel Corporation,
International Business Machines Corporation (IBM), Nokia Corporation and Toshiba
Corporation. These companies formed the original core group (known as promoter
companies) of the SIG. The SIG was publicly announced in May 1998 with a charter to
produce an open specification for hardware and software that would promote
interoperable, cross-platform implementations for all kinds of devices.
1.2.2 SIG PROGRESSION

As the specification evolved and awareness of the technology and the SIG
increased, many other companies joined the SIG as adopters; adopters are entitled to a
royalty-free license to produce products with Bluetooth wireless communication based
upon the specification and can receive and comment upon early versions of SIG
publications.
Today there are over 1,800 adopter members of the SIG, representing academia
and industries such as consumer electronics, automotive, silicon manufacturing,
consulting, telecommunications and many others. The original SIGs objective was to
develop, as rapidly as possible, an open specification that was sufficiently complete to
enable implementations. By carefully organizing the SIG and making use of frequent in
person meetings supplemented by even more frequent conference calls and e-mail
3
Amplify Mindware
Bluetooth
What is Bluetooth?
exchanges, the SIG produced a thorough specification in about one and one-half years
(version 1.0 of the specification, including profiles, was published in July 1999).
The SIG organized itself into several working groups, each with a focus on a
specific part of the technology or on some supporting service. These working groups
included:
The air interface working group, which focused on the radio and baseband
layers;
The software working group, which developed the specification for the protocol
stack;
The interoperability working group, which focused on profiles;
The compliance working group, which defined the testing, compliance and
certification process;
The legal working group, which managed the legal affairs of the SIG such as
membership and intellectual property agreements; and
The marketing working group, which promoted the technology and helped to
generate the marketing requirements that the specification was to address.
Some of the larger working groups, such as the software working group, were
further divided into task forces focusing on a particular layer of the Bluetooth protocol
stack. Coordinating all of these working groups and governing the overall SIG was a
program management committee composed of voting representatives from each of the
promoter companies.
In December 1999, four new promoter companies like 3Com Corporation, Lucent
Technologies Inc., Microsoft Corporation and Motorola, Inc., some of whom had made
contributions to the original specification as adopter companies joined the SIG. The
group remains very active today in maintaining the existing documentation and in
creating enhancements to the specification, along with new profiles. It easily can be
seen that it took an enormous effort to develop over 1,500 pages of complex and
detailed information in just over a years time. For many in the SIG this became their fulltime job or at least a primary responsibility. Issues, both technical and non-technical,
inevitably arose and were handled through discussion and voting when necessary, but in
general the development and refinement of specifications and profiles progressed in an
exemplary manner.
4
Amplify Mindware
Bluetooth
What is Bluetooth?
1.3 THE BLUETOOTH NAME
AND
HISTORY
Bluetooth is notable in the high-technology industry in several respects, but in

particular its name garners much attention. Most new industry initiatives are known by a
name which describes their associated technology or its application and often they
quickly become known by an acronym describing the full name. Why wasnt the
technology called, for example, Short-Range Wireless Radio, or SRWR, or some other
descriptive name? The answer lies in the heritage of the original inventors. There are
numerous histories and accounts of the Bluetooth namesake and how that name came
to be chosen; the generally accepted story and facts are cited here.
Harald Blatand was King of Denmark from approximately A.D. 940 to 985. During
his reign King Harald is reported to have united Denmark and Norway and to have
brought Christianity to Scandinavia. Apparently Blatand translates, at least loosely, to
Blue Tooth. The origins of this name are uncertain, although it was relatively common
during this time for kings to have a distinguishing name.
For a technology with its origins in Scandinavia, it seemed appropriate to the SIG
founders to name the organization that was intended to unify multinational companies
after a Scandinavian king who united countries. Thus was born the Bluetooth name,
which initially was an unofficial code name for the project but today has become the
trademark name of the technology and the special interest group.
Figure 1.1 shows the Bluetooth logo, inspired by the initials H B for Harald
Bluetooth.
Figure 1.1: Bluetooth Logo
Bluetooth wireless communication has engendered tremendous interest since

the SIGs formation was announced. Articles in many leading computer-industry trade
press publications and in quite a few of the mainstream media have appeared with some
frequency. Many analysts such as the Cahners In-Stat Group and the Gartner Group
DataQuest now include Bluetooth wireless communications in their studies and
forecasts.
5
Amplify Mindware
Bluetooth
What is Bluetooth?
Summary
Bluetooth refers to an open specification for a technology to enable shortrange wireless voice and data communications anywhere in the world.
The Bluetooth SIG has produced a specification for Bluetooth wireless
communication that is publicly available and royalty free.
The founding SIG members are Ericsson, Intel, IBM, Nokia, & Toshiba
6
Amplify Mindware
Bluetooth
Technical Overview
Chapter Two
2.1 THE AIM
OF
Technical Overview
BLUETOOTH
The aim has been set quite height. It is to arrive at a specification for a
technology that optimizes the usage model of all mobile computing and communications
devices, and providing
Global usage
Voice and data handling
The ability to establish ad-hoc connections
The ability to withstand interference from other sources in open band
Very small size, in order to accommodate integration into variety of devices
Negligible power consumption in comparison to other devices for similar use
An open interface standard
Competitively low cost of all units, as compared to their non-Bluetooth
correspondents
2.2 FEATURES
Bluetooth is a wireless technology that enables any electrical device to wirelessly
communicate in the 2.5 GHz ISM frequency band. It allows devices such as mobile
phones, headsets, PDA's and portable computers to communicate and send data to
each other without the need for wires or cables to link to devices together. It has been
specifically designed as a low cost, low power, radio technology, which is particularly
suited to the short range Personal Area Network (PAN) application.
The Main Features of Bluetooth:
Operates in the 2.4GHz frequency band without a license for wireless
communication.
Real-time data transfer usually possible between 10-100m.
Close proximity not required as with infrared data (IrDA) communication devices
as Bluetooth doesn't suffer from interference from obstacles such as walls.
7
Amplify Mindware
Bluetooth
Technical Overview
Supports both point-to-point wireless connections without cables between mobile

phones and personal computers, as well as point-to-multipoint connections to ad
hoc local wireless networks.
It is based on a frequency hopping radio link for facilitating fast and secure
transmissions of both voice and data (1600 hops/s).
Maximum data throughout is 1Mbps.
2.3 BLUETOOTH COMPONENTS

A complete Bluetooth system will require these elements:
An RF portion for receiving and transmitting data
A module with a baseband microprocessor
Memory
An interface to the host device (such as a mobile phone)
This basic system will vary, however, depending on whether the Bluetooth
module is independent of the host or embedded. First, consider the module scenario.
The RF portion can be implemented as a module or as a single chip. Another option for
manufacturers is to embed a fully integrated RF/baseband Bluetooth chip.
2.4 BLUETOOTH
COMPARISONS W ITH OTHER W IRELESS TECHNOLOGIES
8
Amplify Mindware
Bluetooth
Technical Overview
Summary
The main aim of bluetooth was to have global usage, Voice and data handling,
ability to establish ad-hoc connections, to withstand interference from other
sources in open band, less power consumption, open interface standard, etc.
Bluetooth Operates in the 2.4GHz (ISM) frequency band
Maximum data throughout is 1Mbps.
Supports both point-to-point as well as point-to-multipoint connections
Basic components of bluetooth are an RF portion for receiving and transmitting

data, a module with a baseband microprocessor, Memory, an interface to the
host device (such as a mobile phone)
9
Amplify Mindware
Bluetooth
Technical Overview
PART TWO
BLUETOOTH
PROTOCOL AND NETWORK ASPECTS
10
Amplify Mindware
Bluetooth
Technical Overview
Chapter Three
Bluetooth Protocol
3.1 PROTOCOL ARCHITECTURE

Bluetooth does not just define a radio system, it also defines a software stack to
enable applications to find other Bluetooth devices in the area, discover what services
they can offer, and use those services. The Bluetooth stack is defined as a series of
layers, though there are some features, which cross several layers. The protocol stack is
illustrated below,
Figure 3.1: Bluetooth Stack
11
Amplify Mindware
Bluetooth
Technical Overview
3.2 LAYER FUNCTIONS

Radio: modulates and demodulates data for transmission and reception on air.
Baseband and Link Controller: controls the physical links via the radio,
assembling packets and controlling frequency hopping.
Link Manager: controls and configures links to other devices.
Host Controller Interface (HCI): handles communications between a separate
host and a Bluetooth module.
Logical Link Control and Adaptation (L2CAP): multiplexes data from higher layers
and converts between different packet sizes.
RFCOMM: provides an RS232 like serial interface.
WAP and OBEX: provides interfaces to the higher layer parts of other
communication protocols.
Service Discovery Protocol (SDP): lets Bluetooth devices discover what services
other Bluetooth devices support.
Telephony Control Protocol Specification (TCS): provides telephony services.
Applications: provides support for various Bluetooth profiles to implement the
Bluetooth protocol in various Bluetooth applications.
12
Amplify Mindware
Bluetooth
Radio Interface
Chapter Four
Radio Interface
The Bluetooth system operates in the 2.4 GHz ISM (Industrial Scientific
Medicine) band. The range of this frequency band in Europe and USA is 2400 2483.5 MHz. This band may vary from one country to another due to frequency
limitations. For Spain and France the frequency band is 2445 2475 MHz and
2446.5 2483.5 MHz respectively. Channel spacing is 1 MHz. In order to comply
with out-of-band regulations a guard band is used at the lower and upper band edge.
4.1 TRANSMITTER CHARACTERISTICS

The classification is done into 3 power classes,
Table 4.1: Power Classes
Note 1: Pmin < -30 dBm is suggested, but not compulsory and may be application dependent.
4.1.1 FREQUENCY HOPPING

It is possible that a data packet sent over a radio channel may be blocked
temporarily by an interference source in the busy ISM band. A Bluetooth specification
provides the scheme for re-transmission of such packets that are loss during
transmission. It is more convenient to re-transmit data over a new channel by a
frequency hopping method, which may also be blocked latter some time. Frequency
hopping algorithm is employed to calculate the frequency hop sequence, which
ensures maximum distance between adjacent hop channels.
13
Amplify Mindware
Bluetooth
Radio Interface
4.1.2 MODULATION
The operating band of 83.5 MHz is divided into 1MHz channel. To utilize
maximum available channel bandwidth, GFSK (Gaussian Frequency Shift Keying)
modulation scheme with a BT=0.5 is used producing the data rate of 1Mbps.
The Modulation index is between 0.28 and 0.35. The Bandwidth Product (BT)
is a product of adjacent signal frequency separation i.e. 0.5 MHz and symbol duration
i.e. 1 s. Modulation index can be represented as 2fdT, where T is symbol duration.
Thus,
2fdT
2fdT
fd
0.28 / (2 * 1 s)
fd
140 KHz
Modulation index
0.28
Therefore,
Similarly for Modulation index of 0.35

fd
175 KHz
So the frequency deviation range is 140 KHz to 175 KHz. In addition, the minimum
deviation shall never be smaller than 115 kHz.
A binary one represents positive frequency deviation, and a binary zero
represents negative frequency deviation. The symbol timing shall be better than
20ppm. That means the clock managing the logic processing functionality for the
symbol must be accurate to 20ppm. The zero crossing error is the time difference
between the ideal symbol period and the measured crossing time. This shall be less
than 1/8 of a symbol period i.e. 0.12 s.
Figure 4.1: Modulation
14
Amplify Mindware
Bluetooth
Radio Interface
4.1.3 SPURIOUS EMISSIONS

The hopping transmitter hopping on a single frequency is used to measure
the spurious emissions, in-band and out-of-band, which indicates that the synthesizer
must change frequency between, receive slot and transmit slot, but always returns to
the same transmit frequency.
4.1.4 FREQUENCY TOLERANCE

The transmitted initial center frequency accuracy must be 75 kHz from Fc.
The initial frequency accuracy is defined as being the frequency accuracy before any
information is transmitted. Note that the frequency drift requirement is not included in
the 75 kHz.
4.2 RECEIVER CHARACTERISTICS

A loop back facility, where the equipment sends back the decoded
information and it is necessary to measure the Bit Error Rate (BER).
4.2.1 SENSITIVITY LEVEL
The actual sensitivity level for Bluetooth devices must be of 70dBm or better,
so as to meet the BER of 0.1%.
4.2.2 INTERFERENCE PERFORMANCE
The interference performance on Co-channel and adjacent 1 MHz and 2 MHz
are measured with the wanted signal 10 dB over the reference sensitivity level. The
interference performance is shown below.
Table 4.2: Interference Performance
15
Amplify Mindware
Bluetooth
Radio Interface
4.2.3 OUT-OF-BAND BLOCKING

The out-of-band blocking is measured with the wanted signal 3db over the
reference sensitivity level. The interference signal shall be a continuous sine wave
and the BER shall be equal to 0.1%.
4.2.4 MAXIMUM USABLE LEVEL
The maximum usable input level the receiver shall operate at shall be better
than 20dBm. The BER shall be less or equal to 0.1% at 20 dBm input power.
4.2.5 RSSI RECEIVER SIGNAL STRENGTH INDICATOR

A transceiver that wishes to take part in a power-controlled link must be able
to measure its own receiver signal strength and determine if the transmitter on the
other side of the link should increase or decrease its output power level. A Receiver
Signal Strength Indicator (RSSI) makes this possible. It is an optional one. The way
the power control is specified is to have a golden receive power. This golden receive
power is defined as a range with a low limit and a high limit. The RSSI must have a
minimum dynamic range equal to this range. The RSSI must have an absolute
accuracy of 4dB or better when the receive signal power is 60dBm. In addition, a
minimum range of 206 dB must be covered, starting from 60 dB and up. The RSSI
dynamic range and accuracy is shown below.
Figure 4.2: RSSI dynamic range and accuracy
4.2.6 INTERFERENCE SIGNAL

A Bluetooth modulated interfering signal is defined as
Modulation = GFSK
Modulation index = 0.321%
BT= 0.51%
Bit Rate = 1 Mbps 1ppm
Modulating Data = PRBS9
Frequency accuracy better than 1ppm.
16
Amplify Mindware
Bluetooth
Radio Interface
Summary
Operates in 2.4 GHz ISM band.
Channel spacing is 1 MHz and Guard bands are use to avoid interference
Frequency Hopping algorithm is employed to calculate the frequency hop
sequence, which ensures maximum distance between adjacent hop channels
GFSK (Gaussian Frequency Shift Keying) modulation scheme with a BT=0.5 is
used producing the data rate of 1Mbps is used with index is between 0.28 and
0.35.
Spurious emission - The synthesizer must change frequency between receive
slot and transmit slot, but always returns to the same transmit frequency.
Receiver
Characteristics
include
Look
back
process,
Sensitivity
level,
Interference performance, out of band blocking, maximum usage level and RSSI.
17
Amplify Mindware
Bluetooth
Chapter Five
5.1 INTRODUCTION
Baseband is responsible for controlling the radio. This layer provides frequency
hopping. It also takes care of lower level encryption for secure links. It is a physical layer
of Bluetooth system. Baseband lies above the Bluetooth radio in the protocol stack and
acts as a link controlling the link with the link manager for carrying out link routines like
link connection and power control. A slotted channel with nominal slot length of 625 s is
used. For full duplex transmission, Time-Division Duplex (TDD) scheme is applied. On
the channel, information is exchanged through packets such that each packet is
transmitted on a different hop frequency covering a single slot, but can be extended to
cover up to five slots.
The Bluetooth protocol combines circuit as well as packet switching. Bluetooth
can support an asynchronous data channel, up to three simultaneous synchronous voice
channels, or a channel, which simultaneously supports asynchronous data and
synchronous voice. Each voice channel supports a 64 kb/s synchronous (voice) channel
in each direction and asynchronous channel can support maximal 723.2 kb/s
asymmetric, or 433.9 kb/s symmetric.
The Bluetooth system provides a point-to-point connection as well as point-tomultipoint connection. In the point-to-multipoint connection, the channel is shared among
several Bluetooth units forming a piconet. Maximum of eight units can participate in a
piconet with one unit acting as the master of the piconet and the other remaining units
acting as slaves in an active mode. In addition, many more slaves can remain locked to
the master in a parked state, which remain synchronized to the master. The master
controls both for active and parked slaves. Multiple piconets with overlapping coverage
areas form a scatternet. Only one master is present in each piconet. However, slaves
can participate in different piconets on a time-division multiplex basis. In addition, a
master in one piconet can become a slave in another piconet. Each piconet has its own
hopping channel. This is described in the diagram below,
18
Amplify Mindware
Bluetooth
Figure 5.1 a. Piconets with a single slave, b. multi-slave, c. scatternet operation
5.2 PHYSICAL CHANNEL

Physical channel in Bluetooth is the actual radio link between devices. The
channel is represented by a pseudo-random hopping sequence hopping through the 79
or 23 RF channels. Bluetooth device address of the master is used to determine the
hopping sequence and the Bluetooth clock of the master determines the phase in the
hopping sequence. The channel is divided into time slots where each slot corresponds to
an RF hop frequency. The nominal hop rate is 1600 hops/s. All Bluetooth units
participating in the piconet are time- and hop-synchronized to the channel.
5.2.1 TIME SLOTS
The physical channel is divided into time slots where the master and slave
devices may exchange the data. The time slots used by master to send data to a slave
are called master-to-slave and the time slots used by slave to send data to a master are
called slave-to-master. The channel is divided into time slots, each 625 Vs in length. The
time slots numbering is done according to the mater Bluetooth clock. The slot numbering
ranges from 0 to 227-1 and is cyclic with a cycle length of 227. The masters and slaves
use this time slot to transfer packets alternatively in TDD scheme.
In even time slots the master starts its transmission, while the slave start its
transmission in odd numbered time slots. The packet start shall be aligned with the slot
start. Packets transmitted by the master or the slave may extend over up to five time
slots. This is shown below,
19
Amplify Mindware
Bluetooth
Figure 5.2: TDD and Timing
Figure 5.2: Multi-slot packets
5.3 PHYSICAL LINKS

There are two kinds of links that can be established between a master and one
or more slaves
Synchronous Connection-Oriented (SCO) link
Asynchronous Connection-Less (ACL) link
5.3.1 SCO LINK
The SCO link is a symmetric, point-to-point link wherein the master reserves
slots for SCO link and hence considered as a circuit-switched connection between the
master and a single slave in piconet. The SCO link carries mainly time bound
information like voice. The master can support up to three SCO links to the same slave
or to different slaves and slave can support up to three SCO links from the same master.
Due to time constrains SCO packets are never retransmitted. The master reserves the
20
Amplify Mindware
Bluetooth
slot at regular intervals for sending SCO packets using, the so-called SCO interval TSCO.
The SCO slave is always allowed to respond with an SCO response packet in the
following slave-to-master slot unless it finds that the decoded packet header is
inappropriate and is not addressed as expected. If the SCO slave fails to decode the
slave address in the packet header, it is still allowed to return an SCO response packet
in the reserved SCO response slot. Master uses LM protocol to establish the SCO link
by sending the SCO setup message. This message contains timing parameters such as
the SCO interval TSCO and the offset DSCO to specify the reserved slots.
In order to prevent clock wrap-around problems, an initialization flag in the LMP
setup message indicates whether initialization procedure 1 or 2 is to be used by slave.
The master uses initialization 1 when the MSB of the current master clock (CLK27) is 0;
it uses initialization 2 when the MSB of the current master clock (CLK27) is 1. The
master-to-slave SCO slots reserved by the master and the slave shall be initialized on
the slots for which the clock satisfies the following equation:
CLK27-1 mod TSCO = DSCO for initialization 1
(CLK27, CLK26-1) mod TSCO = DSCO for initialization 2
The slave-to-master SCO slots shall directly follow the reserved master-to-slave
SCO slots. After initialization, the clock value CLK (k+1) for the next master- to-slave
SCO slot is found by adding the fixed interval TSCO to the clock value of the current
master-to-slave SCO slot:
CLK (k+1) = CLK (k) + TSCO
5.3.2 ACL LINK

In the slots not reserved for SCO links, the master can exchange packets with
any slave on a per-slot basis using ACL link providing a packet-switched connection
between the master and all active slaves participating in the piconet. The ACL link
supports asynchronous and isochronous services. Between a master and a slave only a
single ACL link can exist. Packet retransmission is applied for data integrity. A slave is
permitted to return an ACL packet in the slave-to-master slot if and only if it has been
addressed in the preceding master-to-slave slot. If the slave fails to decode the slave
21
Amplify Mindware
Bluetooth
address in the packet header, it is not allowed to transmit. ACL packets not addressed to
a specific slave are considered as broadcast packets and are read by every slave.
5.4 PACKETS
The data on the piconet channel is conveyed in packets. The general packet
format is shown below
Table 5.1: Packet format
The Packet consists of 3 entities: the access code, the header, and the payload.
The access code is 72 bits and header is 54 bits in length. The payload can range from
zero to a maximum of 2745 bits.
5.4.1 ACCESS CODE
The access code is used for synchronization, DC offset compensation and
identification. The access code identifies all packets exchanged on the channel of the
piconet such that they are preceded by the same channel access code. The access
code is also used in paging and inquiry procedures. In this case, the access code itself is
used as a signaling message and neither a header nor a payload is present.
There are three different types of access codes defined:
Channel Access Code (CAC) identifies the piconet and is included in all
packets exchange over piconet.
Device Access Code (DAC) used for paging and its response.
Inquiry Access Code (IAC) is further divided into General IAC (GIAC) used to
discover other Bluetooth devices and Dedicated IAC (DIAC) used to discover
other Bluetooth devices with same characteristics.
CAC consists of preamble, sync word and trailer with 72 bits length whereas
DAC and IAC does not have trailer and is 68 bits long.
22
Amplify Mindware
Bluetooth
Preamble is 4-bit pattern of alternating ones and zeros and is either 1010 or 0101
depending upon the LSB of sync word whether it is 1 or 0 respectively. It is used
for DC offset compensation.
Sync word is 64 bit word derived from 24-bit LAP of Bluetooth device address.
For the CAC the masters LAP is used; for the GIAC and the DIAC, reserved,
dedicated LAPs are used; for the DAC, the slave unit LAP is used.
Trailer is 4-bit code with zero-one bit pattern. It can be either 1010 or 0101
depending whether the MSB of sync word is 0 or 1 respectively. It is used for DC
offset compensation.
5.4.2 PACKET HEADER
Header length is 18 bits and is encoded with the rate of 1/3 FEC resulting in 54bit header.
Table 5.2: Packet Header
Header consists of 6 fields,

AM_ADDR is 3-bit address assigned to each active member in the piconet. It is a
temporary address assigned as each slave moves from park state to active state.
Master-Slave packet exchange contains this field of slave. All zero indicates the
broadcasting packet from master to all slaves.
Type is a 4-bit type code specifying the packet type providing information about
SCO or ACL packet with respective packet slots.
FLOW is use to control the flow of packets over ACL links between the master
and slave. It is a 1-bit value. SCO link is not affected by this flow bit. If the
receiver buffer is full for ACL link, a STOP indication i.e. Flow = 1 is returned to
stop the further packet flow. To start again GO indication i.e. Flow = 0 is returned.
23
Amplify Mindware
Bluetooth
ARQN is 1-bit acknowledgement field to inform the sender about successful

packet transfer. ACK = 1 indicates success and NAK = 0 indicates failure with
NAK being default.
SEQN is used for sequential numbering of packets to avoid the retransmission of
the packets.
HEC is used in each packet header for header error check to check header
integrity.
5.4.3 PAYLOAD
To important fields are synchronous voice field and asynchronous data field. ACL
packets have only the data field and SCO packets only have voice field with exception of
DV packet, which has both. Voice field for HV packet is 240 bits and for DV packet is 80
bits without any payload header.
Data field has payload header, payload body and CRC code. Payload header
size is packet size dependent. For 1 slot packets, the payload header is 1 byte and for
multislot packet it is 2 bytes. The payload header specifies logical channel (L_CH),
length and channel FLOW. The FLOW fields controls the data flow over the channel. If
FLOW is binary zero then flow must stop over channel and if it is binary one the flow can
continue. L_CH indicates if packet is a single packet or continuation fragment of packet
as shown below.
Table 5.3: L_CH channel contents
24
Amplify Mindware
Bluetooth
The payload body has actual user information or data and length field in payload
header determines its length. CRC code is used for data integrity.
5.4.4 PACKET TYPES

For SCO and ACL link 12 packet types are defined with 4 control packets
common to both links. The TYPE field of header indicates the type of packet. Type is
divided into 4 segments depending upon the packet time slot.
COMMON PACKETS
o
ID packet: This carries DAC or IAC. It takes one slot space for
transmission having 68-bit fixed length and is used for paging, inquiry.
NULL packet: This has no payload consisting of CAC and packet header.
It is 126-bit long and is never acknowledged. It is used for getting link
information and flow control.
POLL
packet:
It
is
similar
to
NULL
packet,
but
it
requires
acknowledgement. It is used by master to poll the slaves.

o
FHS packet: This is a special control packet having sender clock

information and Bluetooth address. The payload is 144-bit long with 16-bit
CRC code. 2/3 FEC techniques are applied making the told packet length
of 240 bits. It is used in page master response, inquiry response and
master slave switch.
DM1 packet: It is recognized on SCO link as well on ACL link and may
carry user data, although it is a control packet.
S C O P A C K E T S : These packets are used for SCO link in synchronous mode.

They do not have CRC code and are never retransmitted.
o
HV1 packet: It carries 10 user information bytes. Typically used for voice
transmission (stands for HIGH VOICE) with 1/3 FEC encoded. Payload
length is 240 bits with no payload header.
25
Amplify Mindware
Bluetooth
o

transmission (stands for HIGH VOICE) with 2/3 FEC encoded. Payload
length is 240 bits with no payload header.
transmission (stands for HIGH VOICE) without any FEC encoded.
Payload length is 240 bits with no payload header.
DV packet: It carries combined data and voice. Voice is not FEC encoded
whereas data is 2/3 FEC encoded. No CRC coding used for voice. But
data field is 16-bit CRC coded. The payload is divided into 80-bit voice
and 150-bit data.
A C L P A C K E T S : ACL packets are used for asynchronous links. The information

can be user data or control data. No acknowledgement is used in ACL links.
o
DM1 packet: It carries 18 information bytes with data only having 16-bit
CRC code. DM is Data Medium rate. It is 2/3 FEC encoded.
DH1 packet: This is similar to DM1 packet; the only major difference is it
is not FEC encoded. It carries 28 information bytes with data only having
16-bit CRC code. DM is Data High rate.
DM3 packet: This is similar to DM1 packet with larger payload extending
for 3 time slots. It carries 123 information bytes with data only having 16bit CRC code. It is 2/3 FEC encoded.
16-bit CRC code.
DM5 packet: It carries 226 information bytes with data only having 16-bit
CRC code. DM is Data Medium rate. It is 2/3 FEC encoded. It occupies
5 time slots.
26
Amplify Mindware
Bluetooth
o

16-bit CRC code.
AUX1 packet: This can carry 30 information bytes. It resembles DH1 but
no CRC code. It occupies only one slot.
Table 5.4 summarizes the packets defined so far for the SCO and ACL link
types.
Table 5.4: SCO and ACL Links
5.5 ERROR CORRECTION

Bluetooth specification defines following error correction schemes:
1/3 rate FEC
2/3 rate FEC
27
Amplify Mindware
Bluetooth
ARQ scheme for the data

FEC scheme reduces the number of retransmissions. In 1/3 rate FEC every bit is
repeated thrice 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 acknowledgement
is received or timeout exceeds.
5.5.1 1/3 RATE FEC

This involves repetition of each bit three times. This is decoded by carrying out
majority function of receiving side. This is used for the entire header and for voice in HV1
packet.
5.5.2 2/3 RATE FEC
In this scheme, every 10 bits of data is fed into the LFSR, thus shifting the five
parity bits from the five registers to form a five bit parity value. This value is appended to
the information bits. Thus for every for 10 bits input, 15 bits output is obtained. Therefore
2/3 FEC uses a (15, 10) shortening Hamming code implemented as an LFSR.
5.5.3 ARQ SCHEME

With an automatic repeat request scheme, DM, DH and the data field of DV
packets are transmitted and retransmitted until acknowledgement of a successful
reception is returned by the destination (or timeout is exceeded). The acknowledgement
information is included in the header of the return packet, so-called piggy-backing. To
determine whether the payload is correct or not, a cyclic redundancy check (CRC) code
is added to the packet. The ARQ scheme only works on the payload in the packet (only
that payload which has a CRC). The packet header and the voice payload are not
protected by the ARQ scheme.
In addition to above coding, Cyclic Redundancy Coding (CRC) and Header Error
Check (HEC) are utilized for error corrections. Packets can be further encrypted for
secure packet transmissions.
28
Amplify Mindware
Bluetooth
5.6 DATA W HITENING

OR BIT RANDOMIZATION
To avoid DC bias or prolong continuing sequence of zeros or ones, a process of

data whitening is applied to the user data. This involves mixing up of pseudo random
sequence of bits to the actual data bit stream so as to randomize the data. This process
improves the transmission and reception of the user data.
5.7 LOGICAL CHANNELS

Logical channels are the control channels. They are used to carry the data
needed for maintaining and controlling the link between a master and a slave. In the
Bluetooth system, five logical channels are defined:
LC control channel
LM control channel
UA user channel
UI user channel
US user channel
The control channels LC and LM are used at the link control level and link
manager level, respectively. The user channels UA, UI, and US are used to carry
asynchronous, isochronous, and synchronous user information, respectively. The LC
channel is carried in the packet header; all other channels are carried in the packet
payload.
5.7.1 LC CONTROL CHANNEL (LINK CONTROL)

This channel carries low-level link control information like flow control, and
payload characterization.
5.7.2 LM CONTROL CHANNEL (LINK MANAGER)
The LM control channel carries control information exchanged between the link
managers of the master and the slaves.
5.7.3 UA/UI CHANNEL (USER ASYNCHRONOUS/ISOCHRONOUS DATA)
29
Amplify Mindware
Bluetooth
The UA channel carries L2CAP transparent asynchronous user data. This data
may be transmitted in one or more packets. Timing start packets properly at higher
levels supports UI channel
5.7.4 US CHANNEL (USER SYNCHRONOUS DATA)
The US channel carries transparent synchronous user data. This channel is
carried over the SCO link.
5.8 CHANNEL CONTROL

By definition, the master is represented by the Bluetooth unit that initiates the
connection (to one or more slave units). Note that the names master and slave only
refer to the protocol on the channel: the Bluetooth units themselves are identical; that is,
any unit can become a master of a piconet. Once a piconet has been established,
master-slave roles can be exchanged.
5.8.1 BLUETOOTH CLOCK
Every Bluetooth unit has an internal system clock, which determines the timing
and hopping of the transceiver. The Bluetooth clock is derived from a free running native
clock, which is never adjusted and is never turned off. For synchronization with other
units, only offsets are used that, added to the native clock, provide temporary Bluetooth
clocks which are mutually synchronized. It should be noted that the Bluetooth clock has
no relation to the time of day; it can therefore be initialized at any value. The Bluetooth
clock provides the heart beat of the Bluetooth transceiver. The clock has a cycle of about
a day. The Bluetooth clock of the master determines the timing and the frequency
hopping on the channel of a piconet. When the piconet is established, the master clock
is communicated to the slaves. Each slave adds an offset to its native clock to be
synchronized to the master clock. Since the clocks are free-running, the offsets have to
be updated regularly.
The clock determines critical periods and triggers the events in the Bluetooth
receiver. Four periods are important in the Bluetooth system: 312.5 s, 625 s, 1.25 ms,
and 1.28 s; these periods correspond to the timer bits CLK0, CLK1, CLK2, and CLK12,
respectively, Master-to-slave transmission starts at the even-numbered slots when CLK0
and CLK1 are both zero. CLKN is the free-running native clock and is the reference to all
30
Amplify Mindware
Bluetooth
other clock appearances. CLKE and CLK are derived from the reference CLKN by
adding an offset. CLKE is a clock estimate a paging unit makes of the native clock of the
recipient.
Figure 5.3: Bluetooth Clock
5.8.2 CLOCK TYPES

Native Clock: This clock is an actual h/w oscillator value in a Bluetooth unit. This
value is a reference to determine the values of the other clocks in the system.
Bluetooth Clock: The Bluetooth clock is used to define the timing and hop
sequence of the units radio transceiver. The Bluetooth clock value is determined
by adding an offset to the value of a native clock.
Estimated Clock: This clock is used during paging to speed up the formation of
connection. The value of an estimated clock is obtained by adding an offset
derived from the clock value present in the response from an inquiry message.
Master Clock: The master clock value is communicated to slave units so that
they may add an offset to their native clocks in order to synchronize to the
channel and frequency hop sequence.
5.8.3 STATES
There are two major states: Standby and Connection; in addition, there are
seven substates, page, page scan, inquiry, inquiry scan, master response, slave
response, and inquiry response. The substates are interim states that are used to add
new slaves to a piconet. To move from one state to the other, either command from the
Bluetooth link manager are used, or internal signals in the link controller are used.
31
Amplify Mindware
Bluetooth
Figure 5.4: State Diagram of Link Controller
The Standby state is the default state in the Bluetooth unit. In this state, the
Bluetooth unit is in a low-power mode. Only the native clock is running. The controller
may leave the Standby state to scan for page or inquiry messages, or to page or inquiry
itself. When responding to a page message, the unit will not return to the STANDBY
state but enter the Connection state as a slave. When carrying out a successful page
attempt, the unit will enter the Connection state as a master.
5.8.4 ACCESS PROCEDURES
In order to establish new connections the procedures inquiry and paging are
used. The inquiry procedure enables a unit to discover which units are in range, and
what their device addresses and clocks are. With the paging procedure, an actual
connection can be established. Only the Bluetooth device address is required to set up a
connection. Knowledge about the clock will accelerate the setup procedure. A unit that
establishes a connection will carry out a page procedure and will automatically be the
master of the connection. In the paging and inquiry procedures, the device access code
32
Amplify Mindware
Bluetooth
(DAC) and the inquiry access code (IAC) are used, respectively. A unit in the page scan
or inquiry scans substate correlates against these respective access codes with a
matching correlator. For the paging process, several paging schemes can be applied.
There is one mandatory paging scheme which has to be supported by each Bluetooth
device. This mandatory scheme is used when units meet for the first time, and in case
the paging process directly follows the inquiry process.
5.8.5 INQUIRY PROCEDURES
In the Bluetooth system, an inquiry procedure is defined which is used in
applications where the destinations device address is unknown to the source. One can
think of public facilities like printers or facsimile machines, or access points to a LAN.
Alternatively, the inquiry procedure can be used to discover which other Bluetooth units
are within range. During an inquiry substate, the discovering unit collects the Bluetooth
device addresses and clocks of all units that respond to the inquiry message. It can then,
if desired, make a connection to any one of them by means of the previously described
page procedure. The inquiry message broadcasted by the source does not contain any
information about the source. However, it may indicate which class of devices should
respond.
There is one general inquiry access code (GIAC) to inquire for any Bluetooth
device, and a number of dedicated inquiry access codes (DIAC) that only inquire for a
certain type of devices. The inquiry access codes are derived from reserved Bluetooth
device addresses. A unit that wants to discover other Bluetooth units enters an inquiry
substate. In this substate, it continuously transmits the inquiry message at different hop
frequencies. The inquiry hop sequence is always derived from the LAP of the GIAC.
Thus, even when DIACs are used, the applied hopping sequence is generated from the
GIAC LAP. A unit that allows it to be discovered regularly enters the inquiry scan
substate to respond to inquiry messages. The following sections describe the message
exchange and contention resolution during inquiry response. The inquiry response is
optional: a unit is not forced to respond to an inquiry message.
5.8.6 CONNECTION MODES
Bluetooth in its Connection state can be in any of the four modes,
33
Amplify Mindware
Bluetooth
Active: In this mode both the master and the slave participate actively on the
channel by listening, transmitting or receiving the packets. Both the devices are
kept synchronized to each other.
Sniff: In this mode, the slave rather then listening on every slot for masters
message for that slave sniffs on specified time slots for its message. Hence the
slave can go to sleep in free slot to save 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 etc.
Park: When a slave does not wants to participate in the piconet channel, but still
wants to be synchronize to the channel, it goes into a park mode.
5.8.7 SCATTERNET
Multiple piconets may cover the same area. Since each piconet has a different
master, the piconets hop independently, each with their own channel hopping sequence
and phase as determined by the respective master. In addition, the packets carried on
the channels are preceded by different channel access codes as determined by the
master device addresses. As more piconets are added, the probability of collisions
increases; a graceful degradation of performance results as is common in frequencyhopping spread spectrum systems. If multiple piconets cover the same area, a unit can
participate in two or more overlaying piconets by applying time multiplexing. To
participate on the proper channel, it should use the associated master device address
and proper clock offset to obtain the correct phase. A Bluetooth unit can act as a slave in
several piconets, but only as a master in a single piconet: since two piconets with the
same master are synchronized and use the same hopping sequence, they are one and
the same piconet. A group of piconets in which connections consists between different
piconets is called a scatternet.
A master or slave can become a slave in another piconet by being paged by the
master of this other piconet. On the other hand, a unit participating in one piconet can
page the master or slave of another piconet. Since the paging unit always starts out as
master, a master-slave role exchange is required if a slave role is desired.
5.9 AUDIO
A Bluetooth unit is capable of supporting up to three real time audio connections
at a rate of 64 kb/s. There are two types of audio codecs that are supported by the
34
Amplify Mindware
Bluetooth
Bluetooth Baseband module and can be used to code and decode the real time audio
data. The determination of which codec to use is up to the application to decide. The
codecs are,
5.9.1 LOG PCM CODEC (PULSE CODE MODULATION)
Since the voice channels on the air-interface can support a 64 kb/s information
stream, a 64 kb/s log PCM traffic can be used for transmission.
5.9.2 CVSD CODEC (CONTINUOUS VOICE SLOPE DELTA MODULATION)
A more robust format for voice over the air interface is a delta modulation. This
modulation scheme follows the waveform where the output bits indicate whether the
prediction value is smaller or larger then the input waveform. The system is clocked at
64 kHz.
5.10 BLUETOOTH ADDRESSING

Each Bluetooth transceiver is allocated a unique 48-bit Bluetooth device address
(BD_ADDR). This address is derived from the IEEE802 standard. This 48-bit address is
divided into three fields:
LAP field: lower address part consisting of 24 bits
UAP field: upper address part consisting of 8 bits
NAP field: non-significant address part consisting of 16 bits
The LAP and UAP form the significant part of the BD_ADDR. The total address
space obtained is 232.
Figure 5.5: Format for BD_ADDR
LAP: The LAP is used often in the generation of the channel access code value.
LAP is used most often because the lower bits of the address are the most
unique portion of the address. By using LAP, Bluetooth is able to keep a large
base of unique identifiers as well as reduce the amount of data that must be
passed around on Bluetooth links and within the Bluetooth module itself.
35
Amplify Mindware
Bluetooth
UAP: The UAP is used primarily in the calculation of the Bluetooth units
frequency hopping sequence.
NAP: NAP is not used for much of anything in Bluetooth. Name itself tells that
those bits are not very much in use. They may be use as seeding bits in
implementation purposes.
Other Bluetooth addressing schemes are briefed below:
36
Amplify Mindware
Bluetooth
Summary
The channel is represented by a pseudo-random hopping sequence hopping
through the 79 or 23 RF channels.
The channel is divided into time slots where each slot corresponds to an RF hop
frequency; the hop rate is 1600 hops/s.
The SCO link is a symmetric, point-to-point link wherein the master reserves
slots for SCO link which takes place during a circuit switched connection
between master and a single slave
In the slots not reserved for SCO links, the master can exchange packets with
any slave on a per-slot basis using ACL link which is a Packet-switched
connection.
There are three types of packet types namely the common packets, ACL packets
and SCO packets
There are five logical channels in bluetooth. They are LC, LMUA, UI,and US
Four types of clock in Bluetooth namely the bluetooth clock, Native clock,
Estimated clock and the master clock.
Active; Sniff; Hold; Park are the four connection modes.
37
Amplify Mindware
Bluetooth
Chapter Six
6.1 INTRODUCTION
There are two issues that are to be dealt with network management protocols
and applications. One deals with the set of services provided by the protocol and second
deals with the set of mechanisms used by the protocol to deliver those services. The link
manager controls paging, changing slave modes and handling necessary changes in
master/slave transactions. Its also manages the link and control of multislot packets.
Security, QOS and authentication are some of the added capabilities of LM. The link
managers communicate with each other by means of LMP Link Manager Protocol,
which uses underlying Baseband services. LMP is a command / response packet
oriented protocol. The Bluetooth LMP is used to control logical link establishment,
manage security, and provide general control services. It operates on top of the logical
link protocol for data exchange.
The LMP packets that are sent in the ACL payload are differentiated from L2CAP
packets by a bit in ACL header. They are always sent in single slot packets and have a
higher priority over L2CAP packets. The packets are transported through the Bluetooth
Baseband link protocol. LMP packets are limited by size to make them fit into the single
time slot.
6.2 FORMAT
OF
LMP
LM PDUs are always sent as single-slot packets with the payload header being
one byte. Logical channel is depicted in the two least significant bits in the payload
header. For LM PDUs these bits are set to 11. FLOW bit is always one.
Figure 6.1: Payload Body for LMP PDU
38
Amplify Mindware
Bluetooth
Each PDU is assigned a 7-bit opcode. This identifies different types of PDUs.
The opcode and a one-bit transaction ID are positioned in the first byte of the payload
body. The transaction ID is positioned in the LSB as shown above. The transaction id is
0 if the PDU belongs to a transaction initiated by the master and 1 if the PDU belongs to
a transaction initiated by the slave. Extra parameters these are placed in the payload
starting at the second byte of the payload body. The number of bytes used is parameter
length dependent. The source/destination of the PDUs is determined by the AM_ADDR
in the packet header. Each PDU is either mandatory or optional denoted by M/O field.
The LM does not need to be able to transmit a PDU that is optional. The LM must
recognize all optional PDUs that it receives and, if a response is required, send a valid
response according to the procedure rules. If the optional PDU that is received does not
require a response, no response is sent.
6.3 THE PROCEDURE RULES
AND
PDUS
Each procedure is described and depicted with a sequence diagram below.
Figure 6.2: Procedure
PDU1 is a PDU sent from A to B. PDU2 is a PDU sent from B to A. PDU3 is a

PDU that is optionally sent from A to B. PDU4 is a PDU that is optionally sent from B to
A. PDU5 is a PDU sent from either A or B. A vertical line indicates that more PDUs can
optionally be sent.
39
Amplify Mindware
Bluetooth
6.3.1 GENERAL RESPONSE MESSAGES

Number of different procedures is used respond to other PDUs with the help of
the PDUs LMP_accepted and LMP_not_accepted. The PDU LMP_accepted includes
the opcode of the message that is accepted. The PDU LMP_not_accepted includes the
opcode of the message that is not accepted and the reason why it is not accepted.
Figure 6.3: Response PDUs
6.3.2 AUTHENTICATION
The verifier sends an LMP_au_rand PDU having a random number to the
claimant. The claimant calculates a response, using the challenge sent by verifier; the
claimants BD_ADDR and a secret key and sends back the calculated response to the
verifier. The verifier checks if the response was correct or not. A secret key has to be
shared by two devices for this process. Both the master and the slave can be verifiers.
The authentication procedure is thus based on a challenge-response scheme. The
following PDUs are used in the authentication procedure:
Figure 6.4: Authentication PDUs
If the claimant has a link key associated with the verifier, it calculates the
response and sends it to the verifier with LMP_sres. The verifier checks the response. If
the response is not correct, the verifier can end the connection by sending LMP_detach
with the reason code authentication failure.
If the claimant does not have a link key associated with the verifier it sends
LMP_not_accepted with the reason code key missing after receiving LMP_au_rand.
40
Amplify Mindware
Bluetooth
6.3.3 PAIRING
In this scheme, authentication response is based on initialization key instead of
the link key. When two devices do not have a common link key an initialization key is
created based on a PIN and a random number using which authentication is done. The
PDUs used in the pairing procedure are:
Figure 6.5: Pairing PDUs
6.3.4 CHANGE LINK KEY

The link key derived from combination keys can be changed. If the link key is a
unit key, the units must go through the pairing procedure in order to change the link key.
The contents of the PDUs are protected by a bitwise XOR with the current link key.
Figure 6.6: PDUs for change of link key
6.3.5 CHANGE THE CURRENT LINK KEY

The current link key can be a semi-permanent link key or a temporary link key. It
can be changed temporarily, but the change is only valid for the session. Changing to a
temporary link key is necessary if the piconet is to support encrypted broadcast.
Figure 6.7: PDUs for change of current link key
41
Amplify Mindware
Bluetooth
6.3.6 ENCRYPTION
If at least one authentication has been performed encryption may be used. If the
master wants all slaves in the piconet to use the same encryption parameters it must
issue a temporary key and make this key the current link key for all slaves in the piconet
before encryption is started. This is necessary if broadcast packets should be encrypted.
Figure 6.8: Encryption PDUs
6.3.7 CLOCK OFFSET REQUEST

When a slave receives the packet, the difference is computed between its own
clock and the masters clock included in the payload of the 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.
Figure 6.9: PDUs for Clock offset request
6.3.8 SLOT OFFSET INFORMATION

With LMP_slot_offset the information about the difference between the slot
boundaries in different piconets is transmitted. This PDU carries the parameters slot
offset and BD_ADDR. The slot offset is the time in s between the start of the masters
TX slot in the piconet where the PDU is transmitted and the start of the masters TX slot
in the piconet where the BD_ADDR device is master. This PDU shall be transmitted from
42
Amplify Mindware
Bluetooth
the device that becomes master in the switch procedure. If the master initiates the switch
procedure, the slave sends LMP_slot_offset before sending LMP_accepted. If the slave
initiates the switch procedure, the slave sends LMP_slot_offset before sending
LMP_switch_req. The PDU can also be useful in inter-piconet communications.
Figure 6.10: PDU used for slot offset information
6.3.9 TIME ACCURACY INFORMATION REQUEST

LMP supports requests for the timing accuracy. This information can be used to
minimize the scan window for a given hold time when returning from hold and to extend
the maximum hold time. It can also be used to minimize the scan window when scanning
for the sniff mode slots or the park mode beacon packets. The timing accuracy
parameters returned are the long term drift measured in ppm and the long term jitter
measured in s of the clock used during hold, sniff and park mode. These parameters
are fixed for a certain device and must be identical when requested several times. If a
device does not support the timing accuracy information it sends LMP_not_accepted
with the reason code unsupported LMP feature when the request is received. The
requesting device must in this case assume worst case values (drift=250ppm and
jitter=10s).
Figure 6.11: PDUs for time accuracy info request
6.3.10 LMP VERSION

LMP supports requests for the version of the LM protocol. The requested device
will send a response with three parameters: VersNr, CompId and Sub-VersNr. VersNr
43
Amplify Mindware
Bluetooth
specifies the version of the Bluetooth LMP specification that the device supports.
CompId is used to track possible problems with the lower Bluetooth layers. All
companies that create a unique implementation of the Link Manager shall have their own
CompId. The same company is also responsible for the administration and maintenance
of the Sub-VersNr. It is recommended that each company has a unique Sub-VersNr for
each RF/BB/LM implementation. For a given VersNr and CompId, the values of the SubVersNr must increase each time a new implementation is released. For both CompId
and Sub-VersNr the value 0xFFFF means that no valid number applies. There is no
ability to negotiate the version of the LMP. The sequence below is only used to
exchange the parameters.
Figure 6.12: PDUs for LMP version
6.3.11 SUPPORTED FEATURES

The Bluetooth radio and link controller may support only a subset of the packet
types and features. The PDU LMP_features_req and LMP_features_res are used to
exchange this information. After the features request has been carried out, the
intersection of the supported packet types for both sides may also be transmitted.
Whenever a request is issued, it must be compatible with the supported features of the
other device.
Figure 6.13: PDUs for features request
44
Amplify Mindware
Bluetooth
6.3.12 SW ITCH OF MASTER-SLAVE ROLE

Since the paging device always becomes the master of the piconet, a switch of
the master-slave role is sometimes needed. Suppose device A is slave and device B is
master. The device that initiates the switch finalizes the transmission of the current
L2CAP message and then sends LMP_switch_req. If the switch is accepted, the other
device finalizes the transmission of the current L2CAP message and then responds with
LMP_accepted.
If
the
switch
is
rejected,
the
other
device
responds
with
LMP_not_accepted and no switch is performed.
Figure 6.14: PDU for master-slave switch
6.3.13 NAME REQUEST

LMP supports name request to another Bluetooth device. The name is a user
friendly name associated with the Bluetooth device and consists of a maximum of
fragmented 248 bytes coded according to the UTF-8 standard. When the
LMP_name_req is sent, a name offset indicates which fragment is expected. The
corresponding LMP_name_res carries the same name offset, the name length indicating
the total number of bytes in the name of the Bluetooth device and the name fragment,
where:
name fragment(N) = name(N + name offset), if (N + name offset) < name length
name fragment (N) = 0, otherwise.
Here 0N13. In the first sent LMP_name_req, name offset=0.
Figure 6.15: PDUs for Name Request
45
Amplify Mindware
Bluetooth
6.3.14 DETACH
The connection between two Bluetooth devices can be closed anytime by the
master or the slave. A reason parameter is included in the message to inform the other
party of why the connection is closed.
Figure 6.16: PDU for detach
6.3.15 HOLD MODE

The ACL link of a connection between two Bluetooth devices can be placed in
hold mode for a specified hold time. During this time no ACL packets will be transmitted
from the master. The hold mode is typically entered when there is no need to send data
for a relatively long time. The transceiver can then be turned off in order to save power.
But the hold mode can also be used if a device wants to discover or be discovered by
other Bluetooth devices, or wants to join other piconets. What a device actually does
during the hold time is not controlled by the hold message, but it is up to each device to
decide.
Figure 6.17: PDUs for hold mode
6.3.16 SNIFF MODE

To enter sniff mode, master and slave negotiate a sniff interval and a sniff offset,
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. To avoid
problems with a clock wrap-around during the initialization, one of two options is chosen
for the calculation of the first sniff slot. A timing control flag in the message from the
master indicates this. Note: Only bit1 of this field is valid. When the link is in sniff mode
the master can only start a transmission in the sniff slot. Two parameters control the
listening activity in the slave. The sniff attempt parameter determines for how many slots
46
Amplify Mindware
Bluetooth
the slave must listen, beginning at the sniff slot, even if it does not receive a packet with
its own AM address. The sniff timeout parameter determines for how many additional
slots the slave must listen if it continues to receive only packets with its own AM
address.
Figure 6.18 : PDUs for sniff mode
6.3.17 PARK MODE

All PDUs sent from the master to the parked slaves are broadcast. These PDUs
(LMP_set_broadcast_scan_window, LMP_modify_beacon, MP_unpark_BD_addr_req
and LMP_unpark_PM_addr_req) are the only PDUs that can be sent to a slave in park
mode and the only PDUs that can be broadcast.
47
Amplify Mindware
Bluetooth
Figure 6.19: PDUs for park mode
6.3.18 POW ER CONTROL MODE

The output power is increased or decreased on receipt of any new message. At
the master side the TX power is completely independent for different slaves; a request
from one slave can only affect the masters TX power for that same slave.
48
Amplify Mindware
Bluetooth
Figure 6.20: PDUs for Power Control
If the receiver of LMP_incr_power_req already transmits at maximum power

LMP_max_power is returned. Similarly, if the receiver of LMP_decr_power_req already
transmits at minimum power then LMP_min_power is returned.
6.3.19 CHANNEL Q UAL ITY-DRIVEN CHANGE BETW EEN DM AND DH
According to quality of channel a device configures itself to use DM packets or
DH packets. Nevertheless, all devices are capable of transmitting either DM or DH
packets. If a device wants to automatically adjust between DM and DH it sends
LMP_auto_rate to the other device. Based upon quality measures in LC, the device
determines if throughput will be increased by a change of packet type. If so,
LMP_preferred_rate is sent to the other device.
Figure 6.21: PDUs for Channel Quality-Driven Change Between DM And DH
6.3.20 QOS
The Link Manager provides Quality of Service capabilities. QOS is determine by
the poll interval, which is defined as the maximum time between subsequent
transmissions from the master to a particular slave.
49
Amplify Mindware
Bluetooth
Figure 6.22: PDUs for QOS
6.3.21 SCO LINKS

When a connection has been established between two Bluetooth devices the
connection consists of an ACL link. One or more SCO links can then be established. The
SCO link reserves slots separated by the SCO interval, Tsco. The first slot reserved for
the SCO link is defined by Tsco and the SCO delay, Dsco. After that the SCO slots
follows periodically with the SCO interval. To avoid problems with a wrap-around of the
clock during initialization of the SCO link, a flag indicating how the first SCO slot should
be calculated is included in a message from the master.
Figure 6.23: PDUs for SCO Links
6.3.22 MULTI-SLOT PACKETS

The number of slots used by a slave in its return packet can be limited. The
master allows the slave to use a maximal number of slots by sending the PDU
LMP_max_slots providing max slots as parameter. The default value is 1 slot, i.e. if the
slave has not been informed about the number of slots, it may only use 1-slot packets.
Two PDUs are used for the control of multi-slot packets.
50
Amplify Mindware
Bluetooth
Figure 6.24: PDUs for Multi-Slot Packets
6.3.23 PAGING
LMP provides a means to negotiate the paging scheme, which is to be used the
next time a unit is paged.
Figure 6.25: PDUs for Paging
6.4 CONNECTION ESTABLISHMENT

After the paging procedure, the master must poll the slave by sending POLL or
NULL packets, with a max poll interval. LMP procedures that do not require any
interactions between the LM and the host at the paged units side can then be carried
out. When the paging device wishes to create a connection involving layers above LM, it
sends LMP_host_connection_req. When the other side receives this message, the host
is informed about the incoming connection. The remote device can accept or reject the
connection request by sending LMP_accepted or LMP_not_accepted. When a device
does not require any further link set-up procedures, it will send LMP_setup_complete.
The device will still respond to requests from the other device. When the other device is
also ready with link set-up, it will send LMP_setup_complete. After this, the first packet
on a logical channel different from LMP can then be transmitted.
51
Amplify Mindware
Bluetooth
Figure 6.26: Connection Establishment
Figure 6.27: PDUs for Connection Establishment
52
Amplify Mindware
Bluetooth
Summary
LMP is a command / response packet oriented protocol.
LMP packets are limited by size to make them fit into the single time slot.
LMP procedures include authentication, Pairing, Change Link key, change the
current link key, Encryption, Clock offset request, Time Accuracy Information
Request, LMP Version, Supported Features, Switch of Master-Slave Role, Name
Request, Detach, Hold Mode, Sniff Mode, Park Mode, Power Control, Channel
Quality-Driven Change Between DM And DH, QOS, SCO Links, Multi-Slot
Packets, Paging and Connection Establishment
53
Amplify Mindware
Bluetooth
Chapter Seven
The Link Management Protocol, Baseband and the Radio are implemented in the
Bluetooth hardware modules. These modules can be interfaced with the host in many
ways.
7.1 INTRODUCTION
The HCI provides a uniform interface method between the Bluetooth hardware
capabilities and the Bluetooth Host. The HCI exists across three sections, The Bluetooth
Host, Physical Bus (Transport Layer) and Bluetooth Hardware (Host Controller).
Figure 7.1: Lower Software Layers
54
Amplify Mindware
Bluetooth
As shown above, the HCI firmware implements the HCI Commands by accessing
baseband commands, link manager commands, hardware status registers, control
registers, and event registers. Several layers may exist between the HCI driver on the
host system and the HCI firmware in the Bluetooth hardware. The intermediate layers
between the HCI driver on the host system and the HCI firmware provide the ability to
transfer data without intimate knowledge about the type of data. The figure below
illustrates the path of a data transfer from one device to other.
Figure 7.2: Data Transfer
The HCI driver on the Host exchanges data and commands and thus
communicates with the corresponding HCI firmware on the Bluetooth hardware. The
Host Control Transport Layer (i.e. physical bus) driver provides both HCI layers with the
ability to exchange information with each other. The Host will receive asynchronous
notifications of HCI events over Host Controller Transport Layer.
55
Amplify Mindware
Bluetooth
7.2 BLUETOOTH HARDW ARE BLOCK DIAGRAM
Figure 7.3: Bluetooth Hardware
Bluetooth hardware consists of the Bluetooth radio and the Host Controller. The
Host Controller has a hardware digital signal processing part the Link Controller (LC), a
CPU core, and it interfaces to the host environment.
The Link Controller (LC) consists of hardware and software parts that perform
Bluetooth baseband processing, and physical layer protocols such as ARQ protocol and
FEC coding.
The CPU core will allow the Bluetooth module to handle Inquiries and filter Page
requests without involving the host device. The Link Manager (LM) software runs on the
CPU Core. The LM discovers other remote LMs and communicates with them via the
Link Manager Protocol (LMP) to perform its service provider role using the services of
the underlying Link Controller (LC).
Various physical bus interfaces could be used to connect to the Bluetooth
hardware. The Bluetooth Host Controller initially supports two physical bus architectures,
USB, and PC Card.
USB supports a single physical channel (via Endpoints) over which several
logical channels can exist thus avoiding additional physical interfaces for control, data,
and voice channels. However USB does not have direct access to registers/memory on
the Bluetooth module. Instead, this is done by using the appropriate HCI Commands and
by using the Host Controller Transport Layer interface.
Besides the USB interface, Compact Flash/PC Card interfaces are an option for
an integrated PC solution. Unlike USB, all traffic between the Host and the Bluetooth
module will go across the PC Card bus interface. PC cards have direct access to
registers/memory on the Bluetooth module.
56
Amplify Mindware
Bluetooth
Figure 7.4: Bluetooth Specification for HCI
The responsibility of enumerating devices that are in range of the Bluetooth bus
rests with an RF Bus Driver RFBD. The RFBD is the core of Bluetooth software stack. It
co-exists with an HCI Driver in same binary. The HCI driver is responsible for all
interactions with the Bluetooth Host Controller present on the Bluetooth module
interfacing to the PC. It also serves to abstract the Bluetooth hardware interface in terms
of a private interface exposed by it.
An HCI transport driver is typically layered under the HCI driver. It has the
responsibility of handling the interface used to connect the Bluetooth device hardware
module to PC. Two such HCI transport drivers for the purposes of exposition: USB driver
stack and PC card driver. It is important to note that the only one HCI transport driver is
to be active at any given time.
In case of USB transport, the Bluetooth module interface with the PC using USB.
The HCI commands are transported using the USB control pipe, HCI events are
transported on to the USB interrupt pipe, asynchronous data are transported as USB
bulk data, and synchronous data are transported over USB isochronous pipes as
specified in the HCI USB specification. The Bluetooth USB minidriver on the OS, USB
stack is responsible for abstracting the HCI transport specifics and presenting the data,
events and commands to the HCI driver in a transport-independent manner. An IRPbased6 interface is defined under the HCI driver for this purpose, and all HCI transport
57
Amplify Mindware
Bluetooth
drivers use this interface to talk to the HCI driver. Having such common interface
enables support for different HCI transport drivers.
The Bluetooth drivers loaded by the RFBD (client driver) talk to the RFBD using a
kernel-mode interface called the RF Bus Driver Interface RFBDI. Client drivers typically
implement minidriver or port driver functionality for some class driver in OS. This is
important to ensure seamless integration into OS. The class drivers expose interface to
these drivers as domain specific APIs in user mode.
There is one key module in user mode and it is called Bluetooth Executive
BTEXEC. Among other tasks, the BTEXEC is responsible for exposing a user mode
interface that all user-mode applications can use to access Bluetooth functionality. The
interface is called Bluetooth API BTAPI.
The inquiry process is initiated by a user command and it results in a command
to the Bluetooth host controller on the module through the HCI. This results in the LMP
and baseband firmware executing the inquiry sequence. The PC discovers the other
Bluetooth device, and this is communicated back to the host driver stack through some
HCI events carried across USB. Thus the HCI driver communicates virtually with the HCI
firmware on host Bluetooth module to learn about the new device. To do this, the USB
minidriver interfaces with the USB firmware on the module and USB stack, native OS,
interfaces with the USB controller and interfaces with the USB hardware on the host
module.
Once the HCI driver knows about the new device through events, the RFBD
propagates this information to the user. The user drives further actions on the device,
particularly those relating the service discovery.
7.3 HCI PACKET TYPES

Bluetooth specification for HCI defines following packets:
Command Packets Host uses for controlling the Bluetooth module.
Event Packets used by Bluetooth module to notify events to Host.
Data Packets used for transferring actual user data.
Transport layer carries these packets.
58
Amplify Mindware
Bluetooth
7.3.1 COMMAND PACKETS

HCI Command Packets are used to transfer the HCI commands. HCI commands
are used by Host to control and monitor the Bluetooth module. It begins with an two byte
opcode. This is divided into Opcode Command Field (OCF) identifying the group of
command and Opcode Group Field (OGF) identifying the command within the group.
This is followed by parameter length. Finally parameters are present. On immediate
completion of command HCI_Command_Complete event is returned, else if the
command cannot be completed immediately HCI_Command_Status event is returned
with another event returned later when the command is actually completed. HCI
command packet structure is shown below.
Figure 7.5: HCI Command Packet
7.3.2 EVENT PACKETS

HCI Event Packets is used by the Host Controller to notify the Host when events
occur. The Host must be able to accept HCI Event Packets with up to 255 bytes of data
excluding the HCI Event Packet header. The format is shown below
59
Amplify Mindware
Bluetooth

Figure 7.6: HCI Event Packet
7.3.3 DATA PACKETS

HCI Data Packets are used to exchange data between the Host and Host
Controller. The data packets are defined for both ACL and SCO data types.
Figure 7.7: HCI ACL Data Packet
The Connection Handle specifies the ACL connection for data. Packet Boundary
identifies whether the start of L2CAP packet or continuing fragment of L2CAP packet.
The Broadcast Flag identifies the broadcasting data. The Data Length is total data
length. The diagram below shows the HCI SCO Data Packet.
Figure 7.8: HCI SCO Data Packet
7.4 COMMANDS & EVENTS

7.4.1 LINK CONTROL COMMANDS
The Host Controller controls the other Bluetooth devices using link control
commands and thus instructs the LM to create and modify the link layer connections.
60
Amplify Mindware
Bluetooth
61
Amplify Mindware
Bluetooth
62
Amplify Mindware
Bluetooth
7.4.2 LINK POLICY COMMANDS

The methods for link management are provided by the Link Policy Commands.
The establishment and maintenance of the Bluetooth piconet and scatternets are still
controlled by the LM. These commands modify the LM behavior that can result in
changes to the link layer connections with Bluetooth remote devices.
63
Amplify Mindware
Bluetooth
7.4.3 HOST CONTROLLER AND BASEBAND COMMANDS

These commands provide access and control to various capabilities of Bluetooth
hardware. These commands provide control of Bluetooth devices and of the capabilities
of the host controller, link manager and baseband.
64
Amplify Mindware
Bluetooth
65
Amplify Mindware
Bluetooth
66
Amplify Mindware
Bluetooth
67
Amplify Mindware
Bluetooth
68
Amplify Mindware
Bluetooth
7.4.4 INFORMATIONAL PARAMETERS

This parameter is fixed by the Bluetooth hardware manufactures providing
information about the hardware capabilities of the Bluetooth device
69
Amplify Mindware
Bluetooth
7.4.5 STATUS PARAMETERS

These parameters provide information about the current state of the Host
Controller, Link Manager, and Baseband.
70
Amplify Mindware
Bluetooth
7.4.6 TESTING COMMANDS

The Testing commands are used to provide the ability to test various
functionalities of the Bluetooth hardware.
7.5 EVENTS
Events are returned back by the Bluetooth Module (Hardware) to the Bluetooth
Host in response to the commands given by the Bluetooth Host.
71
Amplify Mindware
Bluetooth
72
Amplify Mindware
Bluetooth
73
Amplify Mindware
Bluetooth
7.6 FLOW CONTROL

The Host is responsible for the data flow control from Host to the Host Controller
thus avoiding the filling up the Host Controller data buffers with ACL data destined for a
remote device that is not responding.
On Initialization, the Host issues the Read_Buffer_Size command. Two of the
return parameters of this command determine the maximum size of HCI ACL and SCO
Data Packets (excluding header) sent from the Host to the Host Controller. There are
also two additional return parameters that specify the total number of HCI ACL and SCO
Data Packets that the Host Controller can have waiting for transmission in its buffers.
When there is at least one connection to another device, or when in local loop back
mode, the Host Controller uses the Number of Completed Packets event to control the
flow of data from the Host. This event contains a list of connection handles and a
corresponding number of HCI Data Packets that have been completed (transmitted,
flushed, or looped back to the Host) since the previous time the event was returned (or
74
Amplify Mindware
Bluetooth
since the connection was established, if the event has not been returned before for a
particular connection handle). Based on the information returned in this event, and the
return parameters of the Read_Buffer_Size command that specify the total number of
HCI ACL and SCO Data Packets that can be stored in the Host Controller, the Host can
decide for which Connection Handles the following HCI Data Packets should be sent.
After every time it has transferred an HCI Data Packet, the Host must assume that the
free buffer space for the corresponding link type (ACL or SCO) in the Host Controller has
decreased by one HCI Data Packet. When the Host receives a new Number Of
Completed Packets event, the Host gets information about how much the buffer usage
has decreased since the previous time the event was returned. It can then calculate the
actual current buffer usage. While the Host Controller has HCI data packets in its buffer,
it must keep sending the Number of Completed Packets event to the Host at least
periodically; until it finally reports that all the pending ACL Data Packets have been
transmitted or flushed. The rate with which this event is sent is manufacturer specific.
For each individual Connection Handle, the data must be sent to the Host
Controller in HCI Data Packets in the order in which it was created in the Host. The Host
Controller must also transmit data on the air that is received from the Host for a given
Connection Handle in the same order as it is received from the Host. Furthermore, data
that is received on the air from another device must, for the corresponding Connection
Handle, be sent in HCI Data Packets to the Host in the same order as it is received. This
means that the scheduling is made on a Connection Handle basis. For each individual
Connection Handle, the order of the data must not be changed from the order in which
the data has been created.
The flow control from Host Controller to the Host may sometimes become
necessary. There is therefore a command Set_Host_Controller_To_Host_Flow_Control
to turn flow control on or off in that direction. If turned on, it works in exactly the same
way as described above. On initialization, the Host uses the Host_Buffer_Size command
to notify the Host Controller about the maximum size of HCI ACL and SCO Data Packets
sent from the Host Controller to the Host. The command also contains two additional
command parameters to notify the Host Controller about the total number of ACL and
SCO Data Packets that can be stored in the data buffers of the Host. The Host then
uses the Host_Number_Of_Completed_Packets command in exactly the same way as
the Host Controller uses the Number Of Completed Packets event (as was previously
described in this section). The Host_Number_Of_Completed_Packets command is a
75
Amplify Mindware
Bluetooth
special command for which no command flow control is used, and which can be sent
anytime there is a connection or when in local loop back mode. This makes it possible
for the flow control to work in exactly the same way in both directions, and the flow of
normal commands will not be disturbed.
When the Host receives a Disconnection Complete event, the Host can assume
that all HCI Data Packets that have been sent to the Host Controller for the returned
Connection_Handle have been flushed, and that the corresponding data buffers have
been freed. The Host Controller does not have to notify the Host about this in a Number
of Completed Packets event. If flow control is also enabled in the direction from the Host
Controller
to
the
Host,
the
Host
Controller
can
after
it
has
sent
Disconnection_Complete event assume that the Host will flush its data buffers for the
sent Connection_Handle when it receives the Disconnection_Complete event. The Host
does
not
have
to
notify
the
Host
Controller
about
this
in
Host_Number_Of_Completed_Packets command.
7.7 HOST CONTROLLER TRANSPORT LAYER

The HCI Driver and Firmware communicates via the Host Controller Transport
Layer that may exist between the HCI driver on the host system and the HCI firmware in
the Bluetooth hardware. This intermediate layers should provide the ability to transfer
data without intimate knowledge of the data being transferred. Several Host Controllers
can be used, however Bluetooth defines: USB, UART and RS232.
7.7.1 USB TRANSPORT LAYER
The objective of the Universal Serial Bus (USB) Transport Layer is to use USB
hardware interface for Bluetooth hardware. Different HCI packets can be transferred
using various USB connection endpoints. Bluetooth defines mapping between HCI
packets and USB endpoints.
HCI Commands is mapped with USB control endpoint wherein the HCI command
packets are transfer over the USB transport layer. For HCI ACL Data packet transfers
USB bulk point is used thus allowing fast and robust ACL data transfer with 64-byte
packet mapped with USB frame. It also provides error free and uncorrupt data transfer.
The HCI SCO Data packet is transfer using USB isochronous endpoint filling the hosts
SCO FIFO buffers. The interval of 1ms should be set up for USB isochronous endpoint.
76
Amplify Mindware
Bluetooth
However no error correction is used in this endpoint and SCO data may get corrupted.
Event Packets are transferred using USB interrupt endpoint.
A class code will be used that is specific to all USB Bluetooth devices to allow
proper driver stack to load, regardless of which vendor builds the device. It also allows
the HCCI commands to be differentiated from USB commands across the control
endpoint. The codes are,
bbDeviceClass = 0xE0 for wireless controller
bbDeviceSubClass = 0x01 for RF controller
bbDeviceProtocol = 0x01 for Bluetooth Programming
7.7.2 SERIAL TRANSPORT LAYER

The framing to identify the packets are:
0x01 HCI command packet
0x02 HCI ACL Data packet
0x03 HCI SCO Data packet
0x04 HCI Event packet
Both RS232 and UART serial transport layers provide the above framing.
However, RS232 also provides two more framings for error management.
0x05 Error Message packet
0x06 Negotiation packet
7.7.3 UART TRANSPORT LAYER
The objective of the UART Transport Layer is to make it possible to use the
Bluetooth HCI over a serial interface between two UARTs on the same PCB. It utilizes
null-modem connections such that TXD is connected to RXD and CTS is connected to
RTS. The HCI UART Transport Layer assumes that the UART communication is free
from line errors.
7.7.4 RS232 TRANSPORT LAYER
77
Amplify Mindware
Bluetooth
This layer objective is to make it possible to use the Bluetooth HCI over one
physical RS232 interface between the Bluetooth host and the Bluetooth host controller.
There is error free link over RS232 interface.
The RS232 HCI packet frame is shown below.
78
Amplify Mindware
Bluetooth
Summary
The Link Management Protocol, Baseband and the Radio are implemented in the
Bluetooth hardware modules that are interfaced with host using HCI.
Bluetooth specification for HCI defines following packets: Command Packets,
Event Packets and Data Packets
The HCI Driver and Firmware communicates via the Host Controller Transport
Layer.
Different types of transport layers are used. They are USB transport layer,
RS232 transport layer, Serial transport layer, and UART.
79
Amplify Mindware
Bluetooth
Chapter Eight
Logical Link Control and Adaptation

Protocol
8.1 INTRODUCTION
Logical Link Control and Adaptation Protocol also referred, as L2CAP is
responsible for multiplexing, SAR and group abstraction and QOS as shown below. It
provides connection-oriented and connectionless data services to layers above it with
maximum of 64-kbytes L2CAP data packets transmission and reception.
Figure 8.1: L2CAP with protocol layers
The L2CAP Specification is defined for only ACL links and no support for SCO
links is planned. However for ACL links AUX1 packet should not be used, as it does not
support data integrity through CRC check. The ACL payload header for single slot and
multi slot packet is shown below. The FLOW bit is set to 1 for L2CAP packet
transmission, else set to 0 indicating no further transmission.
Figure 8.2: ACL Payload Header - Single Slot Packet
80
Amplify Mindware
Bluetooth
Figure 8.3: ACL Payload Header - Multi Slot Packet
8.1.1 L2CAP Functional Requirements

The
functional
requirements
for
L2CAP
include
protocol
multiplexing,
segmentation and reassembly (SAR), and group management. Figure below shows how
L2CAP fits into the Bluetooth Protocol Stack.
Figure 8.4: L2CAP Architecture
As shown above L2CAP lies above the Baseband. It interfaces with other
communication protocols such as the Bluetooth Service Discovery Protocol, RFCOMM,
Telephony Control (TCS) and Audio.
Baseband SCO links are used for Voice-quality channels for audio and telephony
applications and packetized audio data, such as IP Telephony, may be sent using
communication protocols running over L2CAP.
Essential protocol requirements for L2CAP include simplicity and low overhead
with less consumption of power. Memory requirements for protocol implementation
should also be kept to a minimum. Furthermore, the protocol should be designed to
achieve reasonably high bandwidth efficiency.
81
Amplify Mindware
Bluetooth
L2CAP must support protocol multiplexing. Large L2CAP packets must be

segmented into multiple smaller Baseband packets prior to their transmission over the
air. Similarly, multiple received Baseband packets may be reassembled into a single
larger L2CAP packet. The L2CAP connection establishment process allows the
exchange of information regarding the quality of service (QoS) expected between two
Bluetooth units. The Baseband Protocol supports the concept of a piconet, a group of
devices synchronously hopping together using the same clock. The L2CAP must support
group abstraction.
However, L2CAP does not transport audio designated for SCO links, reliable
channel or ensure data integrity and reliable multicast channel.
8.2 GENERAL OPERATIONS

8.2.1 CHANNELS AND CHANNEL IDENTIFIERS
The logical channel endpoint on a device is assigned with local names referred to
as Channel identifiers (CIDs). The illegal identifier is defined as null identifier (0x0000),
which must never be used as a destination end-point. Signaling channel is assigned with
0x0001 CID, Connectionless reception channel is assigned with 0x0002 CID. Identifiers
from 0x0001 to 0x003F are reserved. CID is to a particular device independent from
other devices. Thus, even if the same CID value has been assigned to (remote) channel
endpoints by several remote devices connected to a single local device, the local device
can still uniquely associate each remote CID with a different device.
8.2.2 OPERATION BETW EEN DEVICES
The connection oriented data channels and connectionless channels are
represented using the CID identifier from local device to remote device. This CID
identifies the endpoint of the channel.
82
Amplify Mindware
Bluetooth
Figure 8.5: Device Channels
The connectionless channels restrict data flow to a single direction whereas the
data flow is in both directions in connection-oriented channel. These channels are used
to support a channel group where the CID on the source represents one or more
remote devices. The signaling channel is a reserved channel for which CID is reserved.
CID allocation is shown in the table below.
Table 8.1: Types of Channel identifiers

The layer communication is explained below:
L2CAP implementations must transfer data between higher layer protocols and
lower layer protocols.
Each implementation must also support a set of signaling commands for use
between L2CAP implementations
L2CAP implementations should also prepare to accept certain types of events
from lower layers to generate events to upper layers.
83
Amplify Mindware
Bluetooth
Fig 8.6: Layer Operations
8.2.3 SAR
Segmentation and reassembly (SAR) operations facilitates for having maximum
transmission unit (MTU) size larger than the largest Baseband packet. However the size
of packet sent from above layer of L2CAP to L2CAP must be below the MTU limit. The
protocol data units (PDUs) will be made by L2CAP by segmenting the higher layer
packet sent to L2CAP. If L2CAP runs directly over the Baseband Protocol, an
implementation may segment the packet into Baseband packets for transmission over
the air. If L2CAP runs above the host controller interface, an implementation may send
block-sized chunks to the host controller where they will be converted into Baseband
packets. As the Baseband controller receives ACL packets, it either signals the L2CAP
layer on he arrival of each Baseband packets, or accumulates a number of packets
before the receive buffer fills up or a timer expires before signaling the L2CAP layer. If
channel reliability is not needed, packets with improper lengths may be silently
discarded. For reliable channels, L2CAP implementations must indicate to the upper
layer that the channel has become unreliable.
8.3 L2CAP STATE MACHINES

The state machine is only pertinent to bi-directional CIDs and is not
representative of the signaling channel or the uni-directional channel.
84
Amplify Mindware
Bluetooth
Fig 8.7: Layer Interaction
Client is initiator of request and Server simply represents the responder of the
request. The vertical interface between two layers uses the prefix of the lower layer
offering the service to the higher layer, e.g., L2CA. The horizontal interface between two
entities of the same layer uses the prefix of the protocol (adding a P to the layer
identification), e.g., L2CAP. Events coming from above at initiator end are called
Requests (Req) which goes above on the peer of responder in form of Indications (Ind)
and corresponding replies in responder are called Responses (Rsp) which comes back
on the peer in initiator as Confirms (Cfm). Responses requiring further processing are
called Pending (Pnd). The notation for Confirms and Responses assumes positive
replies. Negative replies are denoted by a Neg suffix such as L2CAP_ConnectCfmNeg.
While Requests for an action always result in a corresponding Confirmation (for the
successful or unsuccessful satisfaction of the action), Indications do not always result
into corresponding Responses.
Message Sequence Chart (MSC) to illustrate the normal sequence of events.
The two outer vertical lines represent the L2CA interface on the initiator (the device
issuing a request) and the acceptor (the device responding to the initiators request).
Request commands at the L2CA interface result in Requests defined by the protocol.
When the protocol communicates the request to the acceptor, the remote L2CA entity
presents the upper protocol with an Indication. When the acceptors upper protocol
responds, the response is packaged by the protocol and communicated back the to
85
Amplify Mindware
Bluetooth
initiator. The result is passed back to the initiators upper protocol using a Confirm
message.
Fig 8.8: MSC
8.3.1 EVENTS
Events are partitioned into five categories: Indications and Confirms from lower
layers, Requests and Responses from higher layers, data from peers, signal Requests
and Responses from peers, and events caused by timer expirations. Thus events are all
incoming messages to the L2CA layer along with timeouts.
Lower-Layer to L2CAP events
The Bluetooth specification describes the following messages exchanged
between the lower layer protocol (Baseband) and L2CAP during connection process.
LP_ConnectCfm: Confirms the request to establish a lower layer connection.
LP_ConnectCfmNeg: Confirms the failure of request for connection from lower
layer.
LP_ConnectInd: Indicates lower layer for successful connection establishment.
LP_DisconnectInd: Indicates lower layer for shut down of connection.
LP_QoSCfm: Confirms request for a given QOS.
LP_QoSCfmNeg: Confirms the failure for request of QOS.
LP_QoSViolationInd: Indication to lower layer that a violation for QOS has
detected.
86
Amplify Mindware
Bluetooth
L2CAP to L2CAP Signaling events

L2CAP_ConnectReq: A Connection Request packet has been received.
L2CAP_ConnectRsp: A Connection Response packet has been received with a
positive result indicating that the connection has been established.
L2CAP_ConnectRspPnd: A Connection Response packet has been received
indicating the remote endpoint has received the request and is processing it.
L2CAP_ConnectRspNeg: A Connection Response packet has been received,
indicating that the connection could not be established.
L2CAP_ConfigReq: A Configuration Request packet has been received
indicating the remote endpoint wishes to engage in negotiations concerning
channel parameters.
L2CAP_ConfigRsp: A Configuration Response packet has been received
indicating the remote endpoint agrees with all the parameters being negotiated.
L2CAP_ConfigRspNeg: A Configuration Response packet has been received
indicating the remote endpoint does not agree to the parameters received in the
response packet.
L2CAP_DisconnectReq: A Disconnection Request packet has been received and
the channel must initiate the disconnection process.
L2CAP_DisconnectRsp: A Disconnection Response packet has been received.
L2CAP to L2CAP Data events
L2CAP_Data: A Data packet has been received.
Upper-Layer to L2CAP events
L2CA_ConnectReq: Request from upper layer for the creation of a channel to a
remote device.
L2CA_ConnectRsp: Response from upper layer to the indication of a connection
request from a remote device
L2CA_ConnectRspNeg: Negative response (rejection) from upper layer to the
indication of a connection request from a remote device
L2CA_ConfigReq: Request from upper layer to (re)configure the channel.
L2CA_ConfigRsp: Response from upper layer to the indication of a (re)
configuration request
87
Amplify Mindware
Bluetooth
L2CA_ConfigRspNeg: A negative response from upper layer to the indication of

a (re) configuration request
L2CA_DisconnectReq:
Request
from
upper
layer
for
the
immediate
disconnection of a channel.
L2CA_DisconnectRsp: Response from upper layer to the indication of a
disconnection request
L2CA_DataRead: Request from upper layer for the transfer of received data from
L2CAP entity to upper layer.
L2CA_DataWrite: Request from upper layer for the transfer of data from the
upper layer to L2CAP entity for transmission over an open channel.
RTX
The Response Timeout eXpired (RTX) timer is used to terminate the channel
when the remote endpoint is unresponsive to signaling requests.
ERTX
The Extended Response Timeout eXpired (ERTX) timer is used in place of the
RTX timer when it is suspected the remote endpoint is performing additional processing
of a request signal.
8.3.2 ACTIONS
Actions are partitioned into five categories: Confirms and Indications to higher
layers, Request and Responses to lower layers, Requests and Responses to peers,
data transmission to peers, and setting timers.
L2CAP to Lower Layer actions

LP_ConnectReq: L2CAP requests the lower protocol to create a connection.
LP_QoSReq: L2CAP requests the lower protocol to accommodate a particular
QoS parameter set.
LP_ConnectRsp: A positive response accepting the previous connection
indication request.
LP_ConnectRspNeg: A negative response denying the previous connection
indication request.
88
Amplify Mindware
Bluetooth
L2CAP to L2CAP Signaling actions

This section contains the same names identified in events except the actions
refer to the transmission, rather than reception, of these messages.
L2CAP to L2CAP Data actions
This section is the counterpart of events. Data transmission is the action
performed here.
L2CAP to Upper Layer actions
L2CA_ConnectInd: Indicates a Connection Request has been received from a
remote device.
L2CA_ConnectCfm: Confirms that a Connection Request has been accepted.
L2CA_ConnectCfmNeg: Negative confirmation (failure) of a Connection Request.
L2CA_ConnectPnd: Confirms that a Connection Response (pending) has been
received from the remote device.
L2CA_ConfigInd: Indicates a Configuration Request has been received from a
remote device.
L2CA_ConfigCfm: Confirms that a Configuration Request has been accepted,
following the receipt of a Configuration Response from the remote device.
L2CA_ConfigCfmNeg: Negative confirmation (failure) of a Configuration Request.
L2CA_DisconnectInd: Indicates a Disconnection Request has been received
from a remote device or the remote device has been disconnected because it
has failed to respond to a signaling request.
L2CA_DisconnectCfm: Confirms that the remote device following the receipt of a
Disconnection Response from the remote device has processed a Disconnect
Request.
L2CA_TimeOutInd: Indicates that a RTX or ERTX timer has expired.
L2CA_QoSViolationInd: Indicates that the quality of service agreement has been
violated.
89
Amplify Mindware
Bluetooth
8.4 Data Packet

Packets are based on connection-oriented and connectionless channels.
8.4.1 CONNECTION-ORIENTED CHANNEL
The packet format for connection-oriented channel is shown below.
Fig 8.9 Packet Format
The packet consists of:

Length determines the size of information payload in bytes excluding L2CAP
header length. It is 2 octets in length.
Channel ID identifies the CID of destination endpoint. It is 2 octets in length.
Information specifies the payload received from upper layer protocol or
delivered to upper layer protocol i.e. outgoing or incoming packet. It can be 64
Kbytes.
8.4.2 CONNECTIONLESS CHANNEL
Connectionless channels implements group-oriented channel wherein data sent
to group is received to all members of group. Connectionless channel transmissions are
unreliable with no response.
Fig 8.10: Packet format for connection-oriented channel
90
Amplify Mindware
Bluetooth
The packet consists of:

Length determines the size of information payload in bytes excluding L2CAP
header length. It is 2 octets in length.
Channel ID identifies the CID of destination endpoint, which is fixed to 0x0002.
It is 2 octets in length.
Protocol/Service Multiplexer (PSM) used for address mechanism. It is 2 octets.
Information specifies the payload received from upper layer protocol or
delivered to upper layer protocol i.e. outgoing or incoming packet. It can be 64
Kbytes.
8.5 SIGNALING
Signaling commands passed between two L2CAP entities on remote devices for
event and action management with the CIS being 0x0001. The L2CAP packet containing
signal command and command format is shown below.
Fig 8.11: The L2CAP packet
91
Amplify Mindware
Bluetooth
The code indicates the signaling command. Identifier is used to correlate the
request with response. Length indicates the data length.
The code and command mapping is shown below.
8.6 SERVICE PRIMITIVES

Several services are offered by L2CAP in terms of service primitives and
parameters. The service interface is required for testing. They include primitives to:
Connection: setup, configure, disconnect
Data: read, write
Group: create, close, add member, remove member, get membership
Information: ping, get info, request a call-back at occurrence of an event
Connection-less Traffic: enable, disable
8.6.1 SOME SERVICE PRIMITIVES
Event Indication: This primitive requests a callback condition to implement when
the indication event occurs.
92
Amplify Mindware
Bluetooth
Connect: This primitive request for the initiation of the channel creation.
Connect Response: In response to connect service primitive, Connect Response
primitive is issued.
Configure: The use of this primitive requests the initial configuration (or
reconfiguration) of channel to a new set of channel parameters.
Configuration Response: In response to Configure service primitive this service
primitive is issued.
Disconnect: To disconnect the channel Disconnect primitive is used.
Write: this primitive request for the data transfer over the channel.
Read: These primitive requests for the data reception over the channel.
Group Create: The use of this primitive requests the creation of a CID to
represent a logical connection to multiple devices.
Group Close: Closes down the group.
Group Add Member: this primitive request for the addition of new member in the
group.
Group Remove Member: this primitive request for the deletion of a member from
the group.
Get Group Membership: Use of this primitive return the members of the group.
Ping: This primitive asks for the echo response from the peer L2CAP device.
Getinfo: This primitive asks for the configuration information response from the
peer L2CAP device.
Disable Connectionless Traffic: This primitive is used to disable reception of
connectionless data.
93
Amplify Mindware
Bluetooth
Enable Connectionless Traffic: This primitive is used to enable reception of
connectionless data.
94
Amplify Mindware
Bluetooth
Summary
L2CAP is responsible for multiplexing, SAR and group abstraction and QOS
It provides connection-oriented and connectionless data services to layers above
it with maximum of 64-Kbytes L2CAP data packets transmission and reception.
Segmentation and reassembly (SAR) operations facilitates for having maximum
transmission unit (MTU) size larger than the largest Baseband packet.
Events are partitioned into five categories: Indications and Confirms from lower
layers, Requests and Responses from higher layers, data from peers, signal
Requests and Responses from peers, and events caused by timer expirations.
Actions are partitioned into five categories: Confirms and Indications to higher
layers, Request and Responses to lower layers, Requests and Responses to
peers, data transmission to peers, and setting timers.
95
Amplify Mindware
Bluetooth
RFCOMM
Chapter Nine
RFCOMM
9.1 INTRODUCTION
RFCOMM is a cable replacement protocol, based on ETSI European
Telecommunication Standard Institute 07.10 specification. RFCOMM is a simple
transport protocol with framing multiplexing support, which can emulate 9 circuits of
RS232 serial ports over L2CAP layer supporting maximum of 60 connections
between two Bluetooth devices.
RFCOMM provides a communication path between two communicating
Bluetooth devices with a communication segment existing between them.
Fig 9.1: RFCOMM Communication Path

9.1.2 DEVICE TYPES
RFCOMM can support two device types:
Type 1 devices are communication end points such as computers and
printers.
Type 2 devices are those that are part of the communication segment; e.g.
modems.
96
Amplify Mindware
Bluetooth
RFCOMM
The information transferred between two RFCOMM entities has been defined
to support both type 1 and type 2 devices. Type 2 devices only need some
information while other information is intended to be used by both. In the protocol, no
distinction is made between type 1 and type 2.
9.2 SERVICE OVERVIEW

9.2.1 RS232 CONTROL SIGNALS
RFCOMM emulates the 9 circuits of an RS-232 interface. The circuits are
listed below.
9.2.2 NULL MODEM EMULATION

RFCOMM is based on TS 07.10. The way in which TS 07.10 transfers the
RS-232 control signals and data creates an implicit null modem when two devices of
the same kind are connected together. This is shown below.
Fig 9.2: Null Modem Emulation
97
Amplify Mindware
Bluetooth
RFCOMM
9 . 2 . 3 MU L T I P L E E MU L A T E D S E RI A L P O R TS B E TW EE N TW O DE V I C E S
As two Bluetooth devices using RFCOMM in their communication may open
multiple emulated serial ports (60max), the number to be used is specific to
implementation. The active connection between two BT devices using RFCOMM is
identified using Data Link Connection Identifier (DLCI) which is unique to a single
RFCOMM session. It is 6 bits in length.
Fig 9.3: Multiple Emulated Serial Ports

9.2.4 MUL TIPLE EMUL A TE D SERIAL PORTS B ETW EE N MU LTIP L E BT
DEVICES
To implement Multiple Emulated Serial Ports between multiple BT devices the

RFCOMM utilizes a multiplexing concept. RFCOMM entity runs multiplexed sessions
using L2CAP layer.
Fig 9.4: Multiple Emulated Serial Ports between Multiple Devices
98
Amplify Mindware
Bluetooth
RFCOMM
9.3 SERVICE DEFINITION MODEL

The figure below shows the service definition model and the services defined
Fig 9.5: RFCOMM Model

Each of the RFCOMM block is defined in the table below.
9.4 TS 07.10 SUBSET SUPPORT
BY
RFCOMM
AND ITS
ADA PTA TION
TS 07.10 is asymmetric protocol used by GSM phones for multiplexing

several streams of data over one physical serial cable. However, RFCOMM is
symmetric protocol, which sends TS 07.10 frames over L2CAP using TS 07.10 frame
99
Amplify Mindware
Bluetooth
RFCOMM
features and commands. The TS 07.10 frames become the payload of L2CAP
packets. The frame types and commands for this are shown below
Fig 9.6: Frame Types
Fig 9.7: Commands
9.5 TS 07.10 ADAPTATIONS

9.5.1 BASIC OPTION FRAME
The structure of basic option frame is shown below.
100
Amplify Mindware
Bluetooth
RFCOMM
The opening flag and the closing flags in the 07.10 basic option frame are not
used in RFCOMM, instead it is only the fields contained between the flags that are
exchanged between the L2CAP layer and RFCOMM layer.
The address field identifies the multiplexed channel to which the frame belongs. The
control field specify the frame type, the length field indicates the data length the
default being 32 bytes; the maximum is 32767. Frequency Check Sequence (FCS) is
used for framing.
9.5.2 TS 07. 10 MULTIP LEXER STARTUP & CLOSEDOW N PROCEDU RE
At any time, there must be at most one RFCOMM session between any pair
of devices. When establishing a new DLC, the initiating entity must check if there
already exists an RFCOMM session with the remote device, and if so, establish the
new DLC on that. The Bluetooth BD_ADDR of the two endpoints identifies a session.
Step 1: Startup Procedure
The device opening up the first emulated serial port connection between two
devices is responsible for first establishing the multiplexer control channel.
This involves the following steps:
o
Establish an L2CAP channel to the peer RFCOMM entity
Start the RFCOMM multiplexer
Step 2: Closedown Procedure

o
The device closing the last connection (DLC) is responsible for closing
the multiplexer by closing the corresponding L2CAP channel.
Closing the multiplexer by first sending a DISC command frame on

DLCI 0 is optional, but it is mandatory to respond correctly to a DISC
(with UA response).
Step 3: Link loss handling

o
If an L2CAP link loss notification is received, the local RFCOMM entity

is responsible for sending a connection loss notification to the port
emulation/proxy entity for each active DLC.
Then all resources associated with the RFCOMM session should be

freed.
101
Amplify Mindware
Bluetooth
RFCOMM
9.5.3 MU LTIPLEXER COMMANDS

Remote Port Negotiation Command (RPN): The RPN command can be used
before a new DLC is opened and should be used whenever the port settings
change. The RPN command is specified as optional in TS 07.10, but it is
mandatory to recognize and respond to it in RFCOMM.
Remote Line Status Command (RLS): This command is used for indication of
remote port line status. The RLS command is specified as optional in TS
07.10, but it is mandatory to recognize and respond to it in RFCOMM.
DLC parameter negotiation (PN): The PN command is specified as optional in
TS 07.10, but it is mandatory to recognize and respond to it in RFCOMM.
This command can be used before a new DLC is opened.
9.6 FLOW CONTROL

Wired ports commonly use flow control such as RTS/CTS to control
communications. On the other hand, the flow control between RFCOMM and the
lower layer L2CAP depends on the service interface supported by the
implementation. In addition RFCOMM has its own flow control mechanisms.
9.6.1 L2CAP FLOW CONTROL
L2CAP relies on the flow control mechanism provided by the Link Manager
layer in the baseband. The flow control mechanism between the L2CAP and
RFCOMM layers is implementation-specific.
9.6.2 W IRED SE RIAL PORT FLOW CONTROL
Wired Serial ports falls into two camps software flow control-using
characters such as XON/XOFF, and flow control using RTS/CTS or DTR/DSR
circuits.
9.6.3 RFCOMM FLOW CONTROL
The RFCOMM protocol provides two flow control mechanisms:
The RFCOMM protocol contains flow control commands that operate on the
aggregate data flow between two RFCOMM entities
The Modem Status command is the flow control mechanism that operates on
individual entity.
9.6.4 PORT EMULATION ENTI TY SE RIA L FLOW CONTROL
102
Amplify Mindware
Bluetooth
RFCOMM
On Type 1 devices some port drivers will need to provide flow control services
as specified by the API they are emulating. An application may request a particular
flow control mechanism like XON/XOFF or RTS/CTS and expect the port driver to
handle the flow control. On type 2 devices the port driver may need to perform flow
control on the non-RFCOMM part of the communication path; i.e. the physical RS232 port.
103
Amplify Mindware
Bluetooth
RFCOMM
Summary
RFCOMM is a simple transport protocol with framing multiplexing support, which
can emulate 9 circuits of RS232 serial ports over L2CAP layer
Supports maximum of 60 connections between two Bluetooth devices.
RFCOMM is symmetric protocol, which sends TS 07.10 frames over L2CAP
using TS 07.10 frame features and commands.
There are different multiplex commands namely Remote Port Negotiation
Command (RPN), Remote Line Status Command (RLS), and DLC parameter
negotiation (PN)
104
Amplify Mindware
Bluetooth
Chapter Ten
10.1 INTRODUCTION
The service discovery protocol (SDP) provides a means to discover everchanging services of those devices in motion, which are in RF proximity of the client
device. It provides ability for the clients to search for the services using specific service
attributes. These services are categorized into classes for efficient service discovery
procedures. Those new services of the devices already in RF proximity of the client can
also be discover along with the services of the new devices entering the RF proximity.
Similarly SDP helps to determine those services that can become unavailable as the
device may leave the RF proximity of the client. No third device is involved in service
discovery procedures of two devices. SDP is independent of transport layer.
10.1.1 SDP CLIENT-SERVER INTERACTION

The client applications interact with the server applications to discover the
existence of services and its attributes provided by server applications.
SDP client communicates with the SDP server to utilize the services offered by
the SDP server. The server maintains a list of service records that contains information
about services and their characteristics associated with the server. A client issues a SDP
request to the SDP server to retrieve particular service information with the SDP server
responding to the client request. If the client, or an application associated with the client,
decides to use a service, it must open a separate connection to the service provider in
order to utilize the service. A single Bluetooth device may function both as an SDP
server and as an SDP client. If multiple applications on a device provide services, an
105
Amplify Mindware
Bluetooth
SDP server may act on behalf of those service providers to handle requests for
information about the services that they provide. Similarly, multiple client applications
may utilize an SDP client to query servers on behalf of the client applications. The set of
SDP servers available to an SDP client, changes dynamically based on the RF proximity
of the servers to the client. In such cases on server availability, a potential client must be
notified by a means other than SDP. Later the client can use SDP request to query
services from the server. Similarly, there is no explicit notification via SDP given to the
client when the server leaves the RF proximity. In such case the client polls the server
and when it does not receive any response from server, it assumes that the server has
left the RF proximity of client.
10.2 SDP SERVICES

10.2.1 SERVICE RECORD
The service is an entity that performs an action based on information. It has an
ability to control resources. All of the information about a service that is maintained by an
SDP server is contained within a single service record. The SDP server maintains a list
of this service record identifying each services provided by the SDP server. A unique 32bit number handle identifies each service record within SDP server. Note that if two SDP
servers with same service record provide identical services, then these two records are
completely independent of each other.
New service records identifying new services can be added in the SDP server. In
such case there is no mechanism provided via SDP to notify the client about the same.
Similarly removal of any services in turn the corresponding service record from the SDP
server is never notified to the client and the further requests to the server will result in an
error response indicating an invalid service record handle. An SDP server must ensure
that no service record handle values are re-used while an L2CAP connection remains
established.
The service record handle with the value 0x00000000 is a, handle to the service
record that represents the SDP server itself, which defines attributes for the SDP server
and the protocol it supports. Service record handle values 0x00000001-0x0000FFFF are
reserved.
106
Amplify Mindware
Bluetooth
10.2.2 SERVICE ATTRIBUTE

Each service attribute describes a single characteristic of a service. Some
examples of service attributes are shown below.
Note: For detail description of all the attributes please refer to the Bluetooth
specifications.
A service attribute consists of two components: an attribute ID and an attribute

value. An attribute ID is a 16-bit unsigned integer uniquely identifying each attribute of
the within the service record. A service class definition specifies each of the attribute IDs
and its respective attribute value. The attribute value is a variable length field determined
by the attribute ID associated with it and by the service class of the service record in
which the attribute is contained.
10.2.3 SERVICE CLASS
Each service and hence its associated service record is an instance of a service
class. The service class defines attributes of the service with an attribute id, its attribute
value and associated format. A service (service record) is an instance of the service
class such that all the attributes defined in the service class applies to the service. Each
service class is also assigned a unique identifier. This service class identifier is
contained in the attribute value, and is represented as a UUID.
10.2.4 DATA ELEMENTS
The type and size of the attribute values are represented using data elements.
The device receiving the attribute shall determine the type and size of attribute by using
107
Amplify Mindware
Bluetooth
this data element. It consists of header field and data field. The header consists of 5-bit
type descriptor and 3-bit size descriptor. The data is sequence of bytes such that the
size descriptor determines its length and its data type is determined by type descriptor.
10.2.5 SERVICE SEARCH
The Service Search Transaction allows a client to retrieve the service record
handles for particular service records based on the attribute values in those service
records. The capability is provided to search only for attributes whose values are
Universally Unique Identifiers (UUIDs). Important attributes of services that can be used
to search for a service are represented as 128-bit value UUIDs. A service search pattern
is a list of UUIDs used to locate matching service records. A service search pattern is
said to match a service record if each and every UUID in the service search pattern is
contained within any of the service records attribute values. The only time a service
search pattern does not match a service record is if the service search pattern contains
at least one UUID that is not contained within the service records attribute values.
10.2.6 BROW SING FOR SERVICES
In SDP, the mechanism for browsing for services is based on an attribute shared
by all service classes. This attribute is called the BrowseGroupList attribute. The value of
this attribute contains a list of UUIDs. Each UUID represents a browse group with which
a service may be associated for the purpose of browsing. When a client desires to
browse an SDP servers services, it creates a service search pattern containing the
UUID that represents the root browse group. All services that may be browsed at the top
level are made members of the root browse group by having the root browse groups
UUID as a value within the BrowseGroupList attribute. The services offered by an SDP
server may be organized in a browse group hierarchy, by defining additional browse
groups below the root browse group.
A service record with a service class of BrowseGroupDescriptor describes each
of these additional browse groups. A browse group descriptor service record defines a
new browse group by means of its Group ID attribute. In order for a service contained in
one of these newly defined browse groups to be browseable, the browse group
descriptor service record that defines the new browse group must in turn be browseable.
The hierarchy of browseable services that is provided by the use of browse group
descriptor service records allows the services contained in an SDP server to be
108
Amplify Mindware
Bluetooth
incrementally browsed and is particularly useful when the SDP server contains many
service records.
10.3 PROTOCOL DESCRIPTION

SDP uses a request/response model. This model transfers one request protocol
data unit (PDU) and one response PDU in a transaction. In case if the SDP is utilizing
L2CAP transport protocol, then several SDP PDUs must accommodate a single L2CAP
packet. A single L2CAP packet per connection to SDP server should exist.
Every SDP PDU consists of a PDU header followed by PDU-specific parameters.
The header contains three fields: a PDU ID, a Transaction ID, and a Parameter Length.
PDU ID indicates the type of PDU like ServiceSearchRequest, ServiceSearchResponse
etc. Transaction ID is used to match a request with a corresponding response.
Parameter Length specifies the length of all parameters contained in the PDU.
Parameters may include a continuation state parameter
10.3.1 PARTIAL RESPONSES AND CONTINUATION STATE
Certain SDP responses can be so large that it cannot be fit in a single response
PDU. In this case, the SDP server will generate a partial response along with a
continuation state parameter. The client later uses this continuing parameter and
requests the server to send the remaining portion response. The continuation state
parameter is a variable length field whose first byte contains the number of additional
bytes of continuation information in the field. After a client receives a partial response
and the accompanying continuation state parameter, it can re-issue the original request
(with a new transaction ID) and include the continuation state in the new request
indicating to the server that the remainder of the original response is desired. The
maximum allowable value of the InfoLength field is 16 (0x10). Note that an SDP server
can split a response at any arbitrary boundary.
10.3.2 ERROR HANDLING
Each request PDU issued by the client is responded by a response PDU by the
server. However, if the server finds that the request PDU is not in appropriate format or if
it is unable to decode the request PDU or if the server cannot generate response PDU, it
responds with an SDP_ErrorResponse PDU with the reason.
109
Amplify Mindware
Bluetooth
10.3.3 SERVICE SEARCH TRANSACTION

The SDP client generates an SDP_ServiceSearchRequest to locate service
records that match the service search pattern given as the first parameter of the PDU.
Upon receipt of this request, the SDP server will examine its service record database
and return an SDP_ServiceSearchResponse containing the service record handles of
service records that match the given service search pattern.
10.3.4 SERVICE ATTRIBUTE TRANSACTION
The SDP client generates an SDP_ServiceAttributeRequest to retrieve specified
attribute values from a specific service record. The service record handle of the desired
service record and a list of desired attribute IDs to be retrieved from that service record
are
supplied
as
parameters.
The
SDP
server
generates
an
SDP_ServiceAttributeResponse upon receipt of a valid SDP_ServiceAttributeRequest.

The response contains a list of attributes (both attribute ID and attribute value) from the
requested service record.
10.3.5 SERVICE SEARCH ATTRIBUTE TRANSACTION
The SDP_ServiceSearchAttributeRequest transaction combines the capabilities
of the SDP_ServiceSearchRequest and the SDP_ServiceAttributeRequest into a single
request. As parameters, it contains both a service search pattern and a list of attributes
to be retrieved from service records that match the service search pattern. The
SDP_ServiceSearchAttributeRequest and its response are more complex and may
require more bytes than separate SDP_ServiceSearch and SDP_ServiceAttribute
transactions. However, using SDP_ServiceSearchAttributeRequest may reduce the total
number of SDP transactions, particularly when retrieving multiple service records. The
SDP server generates an SDP_ServiceSearchAttributeResponse upon receipt of a valid
SDP_ServiceSearchAttributeRequest. The response contains a list of attributes (both
attribute ID and attribute value) from the service records that match the requested
service search pattern.
110
Amplify Mindware
Bluetooth
Summary
The service discovery protocol (SDP) provides a means to discover everchanging services of those devices in motion, which are in RF proximity of the
client device.
It provides ability for the clients to search for the services Supports maximum of
60 connections between two Bluetooth devices.
SDP is independent of transport layer.
111
Amplify Mindware
Bluetooth
Chapter Eleven
11.1 INTRODUCTION
TCS defines how telephone calls should be sent across a Bluetooth link. The
TCS provides:
Call Control (CC) used for signaling of speech or data call establishment and
release between Bluetooth devices.
Group Management used for group management signaling thus handling
groups of Bluetooth devices
ConnectionLess TCS (CL) used for signaling information exchange
Fig 11.1: TCS in Bluetooth Stack

TCS uses point-to-point signaling when it knows the destination side for call
establishment. It uses point-to-multipoint signaling otherwise i.e. if more than one sides
are available for call establishment. Point-to-point signaling is mapped towards a
connection-oriented L2CAP channel, whereas point-to-multipoint signaling is mapped
towards the connectionless L2CAP channel,
11.1.1 O PERATION BETW EEN DEVICES

Point-to-point signaling to establish a voice or data call is in a single-point
configuration. In step A the device is notified of the call request using the point-to-point
112
Amplify Mindware
Bluetooth
signaling channel. In step B the same signaling channel is used to establish the speech
or data channel for data transfer as shown below.
Fig 11.2: Point-to-Point Signaling in Single Configuration

In point-to-multipoint signaling many devices are available for call establishment.
In step A all the devices are signaled of the call request using point-to-multipoint
signaling channel. In step B one of the devices responds to this signal on the point-topoint signaling channel; the same signaling channel is used to further establish the
speech or data channel in step C as shown below.
Fig 11.3: Signaling in Multi-Point Configuration
113
Amplify Mindware
Bluetooth
11.1.2 O PERATION BETW EEN LAYERS
Fig 11.4: TCS Architecture

Information is exchanged across these interfaces for the following purposes:
A - The Call Control entity provides timing information to the speech
synchronization control for setup and release of the speech paths.
B - For message SETUP procedures using point-to-multipoint signaling L2CAP
connectionless channel is utilized, similarly L2CAP uses this interface to inform
TCS of a SETUP message received on the connectionless channel.
C - For sending TCS message using point-to-point signaling, L2CAP connectionoriented channel is utilized. During L2CAP channel establishment specific quality
114
Amplify Mindware
Bluetooth
of service to be used for the connection will be indicated, in particular the usage
of low power modes (L2CAP will inform LMP about this interface F).
D - The Call Control entity controls the LMP directly, for the purpose of
establishing and releasing SCO links.
E & G - The Group Management entity controls the LMP and LC/Baseband
directly during initialization procedures to control the inquiry, paging and pairing.
11.2 CALL CONTROL

11.2.1 CALL ESTABLISHMENT
A connection-oriented L2CAP channel between the Outgoing and Incoming Side
shall be available before any of the CC procedures can operate. A multi-point
configuration, a connectionless L2CAP channel shall be available between the Outgoing
and Incoming Side.
Following procedure takes place for Call Establishment

The Outgoing Side initiates call establishment by sending a SETUP message,
and starting timer T303. This message is send over L2CAP connection-oriented
channel for point-to-point signaling configuration or is send over L2CAP
connectionless channel for point-to-multipoint signaling configuration. The
SETUP message contains the necessary information required by the Incoming
Side to process the call. This message also contains bearer capability element
(SCO link or ACL link) indicating requested bearer. The Incoming Side may
negotiate on the requested bearer by including a Bearer capability information
element in the first message in response to the SETUP message.
Outgoing Side enters the Call initiated state after sending SETUP message. On
receipt of the SETUP message the Incoming Side enters the Call present state.
If no response is received from the Incoming Side before T303 expires, the
Outgoing Side returns to Null state for connectionless channel configuration
which stops SETUP message transmission, else for connection-oriented channel
configuration the Outgoing Side sends RELEASE COMPLETE message to
Incoming Side.
If the received SETUP message does not contain Sending complete indication
information element, then Incoming Side starts T302 timer and sends SETUP
115
Amplify Mindware
Bluetooth
ACKNOWLEDGE message to Outgoing Side and enters Overlap receiving state.

When the SETUP ACKNOWLEDGE message is received, the Outgoing Side
shall enter the Overlap sending state, stop timer T303, and start timer T304.
The Outgoing Side on receiving SETUP ACKNOWLEDGE sends the remaining
call information if any is send to the Incoming Side in INFORMATION messages.
For each of this message T304 is restarted. Similarly the Incoming Side on
receiving the INFORMATION messages restarts its T302 timer till it gets the
called party number through this INFORMATION messages.
At expiry of T304 timer, the Outgoing Side initiates call-clearing process.
At expiry of T302 timer, the Incoming Side initiates call clearing process if it finds
that it does not have enough information for CALL PROCEEDING process, else
it replies with CALL PROCEEDING, ALERTING or CONNECT messages.
The Incoming Side, if it has adequate information, sends a CALL PROCEEDING
message to the Outgoing Side to acknowledge the SETUP message and to
indicate that the call is being processed and stops T302 timer.
Upon receipt of the CALL PROCEEDING message, the Outgoing Side enters the
Outgoing Call proceeding state, stops timer T303 (or T304) and start timer T310.
After sending the CALL PROCEEDING message, the Incoming Side enters the
Incoming Call proceeding state.
On expiry of T310 timer the Outgoing Side starts call clearing process
Upon receiving an indication that user alerting has been initiated at the called
address, the Incoming Side shall send an ALERTING message, and shall enter
the Call received state.
When the Outgoing Side receives the ALERTING message, the Outgoing Side
may begin an internally generated alerting indication and shall enter the Call
delivered state. The Outgoing Side shall stop timer T304, stop timer T303 or
T310 (if running), and start timer T301.
An Incoming Side indicates acceptance of an incoming call by sending a
CONNECT message to the Outgoing Side, and stopping the user alerting. Upon
sending the CONNECT message the Incoming Side shall start timer T313.
On receipt of the CONNECT message, the Outgoing Side shall stop any
internally generated alerting indications, shall stop (if running) timers T301, T303,
T304, and T310, shall complete the requested bearer channel to the Incoming
116
Amplify Mindware
Bluetooth
Side, shall send a CONNECT ACKNOWLEDGE message, and shall enter the
Active state.
Upon receipt of the CONNECT ACKNOWLEDGE message, the Incoming Side
shall connect to the bearer channel, stop timer T313 and enter the Active state.
While in the Active state, both sides may exchange any information related to the
ongoing call using INFORMATION messages.
Fig 11.5: Call Establishment Message Flow

The figure above provides a complete view of the messages exchanged during
successful Call Establishment. A solid arrow indicates the mandatory messages. A
dotted arrow indicates the optional messages. A triangle indicates a running timer.
117
Amplify Mindware
Bluetooth
11.2.2 CALL CLEARING

The clearing procedures are symmetrical and may be initiated by either the
Outgoing or the Incoming Side.
Following procedure takes place for Call Clearing:
Any protocol timer other than T305 and T308 shall be stopped, on sending or
receiving any call clearing message.
A DISCONNECT message is send by Outgoing Side disconnecting the bearer
channel and enters the Disconnect request sate. It starts T305 timer.
On receipt of DISCONNECT message, the Incoming Side enters the Disconnect
indication state. The bearer channel is disconnected. Once the channel has been
disconnected Incoming Side sends RELEASE message to Outgoing Side, starts
timer T308 and enter the Release request state.
On receipt of the RELEASE message the Outgoing Side shall cancel timer T305,
release the bearer channel, send a RELEASE COMPLETE message, and return
to the Null state.
Following the receipt of a RELEASE COMPLETE message from the Outgoing
Side, the Incoming Side shall stop timer T308, release the bearer channel, and
return to the Null state.
If the Outgoing Side does not receives the RELEASE message in response to
DISCONNECT message before T305 expires, it sends RELEASE message to
Incoming Side and starts T308 timer and enters into Release request state.
If in the Release request state, a RELEASE COMPLETE message is not
received before timer T308 expires, the side that expected the message shall
return to the Null state.
In normal conditions, call is terminated by sending DISCONNECT message by
either sides, however there are exceptions:
In response to a SETUP message, the Incoming Side can reject a call by
responding with a RELEASE COMPLETE message and enter the Null state.
In case of a multi-point configuration, non-selected user call clearing will be
initiated with RELEASE message(s) from the Outgoing Side.
118
Amplify Mindware
Bluetooth
In case of a multi-point configuration, where the SETUP message is delivered on

a connection-less channel, if a remote (calling) user disconnect indication is
received during call establishment, any Incoming Side which has responded, or
subsequently responds, shall be cleared by a RELEASE message. The Outgoing
Side enters the Null state upon completion of clearing procedures for all
responding Incoming Sides.
Fig 11.6: Call Clearing Message Flow
Call States
The states are named as follows. States in bold are mandatory states, part of
Lean TCS:
General States
o
Null (0)
Active (10)
Disconnect request (11)
Disconnect indication (12)
Release request (19)
Outgoing Side States

o
Call initiated (1)
Overlap sending (2)
Outgoing call proceeding (3)
119
Amplify Mindware
Bluetooth
o

Call delivered (4)
Incoming Side States

o
Call present (6)
Call received (7)
Connect request (8)
Incoming call proceeding (9)
Overlap receiving (25)
11.3 GROUP
MANAGEMENT
This involves management of group devices. The procedures supported are:

Obtain access rights: enables the requesting device to use the telephony
services of another device, part of a group of devices
Configuration distribution: facilitates the handling and operation of a group of
devices
Fast inter-member access: enables faster contact establishment between
devices of the same group
These management procedures are implemented using Wireless User Group (WUG).
11.3.1 W IRELESS USER GROUP
A WUG consists of a group of Bluetooth units supporting TCS. One of the
devices is called the WUG master and others are called WUG members. The WUG
master acts typically as gateway, providing other WUG members with the access to
external network. All members of the WUG in range are members of a piconet (active or
parked). Master of this piconet is always the WUG master. All the units participating in
the WUG are provided with the information as to who are WUG members and WUG
master. WUG master provides this information. The WUG master is responsible for
authentication, encryption of the devices.
11.3.2 OBTAIN ACCESS RIGHTS

Obtain access rights procedures are use to gain access of telephony services of
other devices that are part of WUG.
The following is the procedure:
120
Amplify Mindware
Bluetooth
The device that needs access sends ACCESS RIGHTS REQUEST message
and starts T401 timer.
On receipt of the above message, the receiving device accepts the request by
sending ACCESS RIGHTS ACCEPT message.
The requesting device stops the timer T401 on receipt of ACCESS RIGHTS
ACCEPT message and the access rights procedure is completed successfully.
If the receiving device finds that is not in the position to accept the ACCESS
RIGHTS REQUEST message is responds with ACCESS RIGHTS Reject
message, upon receipt of this message the requesting devices stops timer T401
and considers that the request is been denied.
If the requesting device does not receive any response before T401 timer
expires, it assumes that the ACCESS RIGHTS REQUEST message is denied.
Fig 11.7: Access Rights Message Flow
11.3.3 CONFIGURATION DISTRIBUTION

Various units are added or removed from the WUG. All the devices in the WUG
should be notified with these changes. The Configuration distribution procedure is used
to exchange this data. When a WUG configuration change occurs, the WUG master
initiates the Configuration distribution procedure on all WUG members. The WUG
master keeps track of which WUG members have been informed of WUG configuration
changes. Some WUG members may be out of range and may therefore not be reached.
The update of these WUG members will be performed when these members renew
contact with the WUG master.
121
Amplify Mindware
Bluetooth
The procedure is as followed:

The WUG master initiates this procedure by sending INFO SUGGEST message,
which has complete WUG configuration information, to all the WUG members
and starts timer T403.
The WUG members respond with the INFO ACCEPT message indicating the
upgradation of the configuration information.
On receipt of INFO ACCEPT the WUG master stops the T403 timer and the
procedure is successfully completed.
Fig 11.8: Configuration Distribution Message Flow
11.3.4 FAST INTER-MESSAGE ACCESS

When two WUG members are both active in the WUG master piconet, a WUG
member can use the Fast inter-member access procedure to obtain fast access to
another WUG member. With the Fast inter-member access procedure, the originating
WUG member obtains clock information from the terminating WUG member and forces
the terminating WUG member to go into PAGE_SCAN for a defined period (T406).
The procedure is as followed:
The WUG member initiates the procedure by transferring LISTEN REQUEST
message to WUG master, indicating the WUG member with which it wants to
communicate. It starts the timer T404.
Before the expiry of the T404 timer, if the WUG member does not receives the
response of the LISTEN REQUEST message, it terminates the procedure.
122
Amplify Mindware
Bluetooth
The WUG master on receipt of LISTEN REQUEST message, checks for the
validity of the terminating WUG member, if valid starts the T405 timer and sends
LISTEN SUGGEST message to the terminating WUG member.
On receipt of LISTEN SUGGEST message, the terminating WUG member
returns with a LISTEN ACCEPT message to the WUG master. The message
contains the WUG members clock offset and goes into PAGE-SCAN state for
T406 timer period.
The WUG master stops the T405 timer on receipt of the LISTEN ACCEPT
message and informs the originating WUG member about the status by sending
LISTEN ACCEPT message with a terminating WUG members clock offset.
Upon receipt of the LISTEN ACCEPT message, the originating WUG member
stops timer T404, and starts paging the terminating WUG member.
If no response to the LISTEN SUGGEST message is received by the WUG
master before the first expiry of timer T405, then the WUG master shall terminate
the Fast inter-member access procedure by sending a LISTEN REJECT
message to both originating and terminating WUG member.
The originating WUG member is send by WUG master indicating the rejection of
Fast inter-member access procedure, if the WUG master can not satisfy the
request and the originating WUG member on receipt of this message stops timer
T404.
If the terminating WUG member rejects the suggested action received in the
LISTEN SUGGEST message, it sends a LISTEN REJECT message to the WUG
master and on receipt of this message the WUG master stops T405 timer.
Fig 11.9: Fast Inter-Message Access Message Flow
123
Amplify Mindware
Bluetooth
11.4 CONNECTIONLESS TCS

A connectionless TCS message can be used to exchange signaling information
without establishing a TCS call. It is thus a connectionless service offered by TCS. A
connectionless TCS message is a CL INFO message. A connection-oriented L2CAP
channel between the Outgoing and Incoming Side shall be available before a CL INFO
message can be sent.
Alternatively, in a multi-point configuration, a connectionless L2CAP channel may
be used and, if so, shall be available before a CL INFO can be sent.
Fig 11.10 Connectionless TCS Message Flow
11.5 SUPPLEMENTARY SERVICES

TCS provides supplementary services like Call Line Identity, DTMF Start & Stop,
and Register Recall.
11.5.1 CALL LINE IDENTITY
To inform the Incoming Side of the identity of the originator of the call, the
Outgoing Side may include the calling party number information element in the SETUP
message transferred as part of the call request.
124
Amplify Mindware
Bluetooth
Fig 11.11: Call Line Identity Message Flow
11.5.2 DTMF START & STOP

DTMF messages can be provided by either sides, however the side on the PSTN
n/w will be recipient. DTMF messages can be transmitted only in the active state of a
call. Tone generation shall end when the call is disconnected.
Start DTMF request: A user may cause a DTMF tone to be generated; e.g. by
depression of a key. The relevant action is interpreted as a requirement for a
DTMF digit to be sent in a START DTMF message on an established signaling
channel. This message contains the value of the digit to be transmitted (0, 1...9,
A, B, C, D, *, #). Only a single digit will be transferred in each START DTMF
message.
Start DTMF response: The side receiving the START DTMF message will
reconvert the received digit back into a DTMF tone which is applied toward the
remote user, and return a START DTMF ACKNOWLEDGE message to the
initiating side. This acknowledgment may be used to generate an indication as a
feedback for a successful transmission. If the receiving side cannot accept the
START DTMF message, a START DTMF REJECT message will be sent to the
initiating side.
Stop DTMF request: When the user indicates the DTMF sending should cease
(e.g. by releasing the key) the initiating side will send a STOP DTMF message to
the other side.
125
Amplify Mindware
Bluetooth
Stop DTMF response: Upon receiving the STOP DTMF message, the receiving
side will stop sending the DTMF tone (if still being sent) and return a STOP
DTMF ACKNOWLEDGE message to the initiating side.
Fig 11.12: DTMF Message Flow

11.5.3 REGISTER RECALL
Register recall means to seize a register (with dial tone) to permit input of further
digits or other action. In some markets, this is referred to as hook flash. Register recall
is supported by sending an INFORMATION message with a keypad facility information
element; indicating register recall (value 16H).
126
Amplify Mindware
Bluetooth
Summary
TCS defines how telephone calls should be sent across a Bluetooth link.
The TCS provides: Call Control (CC) used for signaling of speech or data call
establishment and release between Bluetooth devices, Group Management
used for group management signaling thus handling groups of Bluetooth devices,
ConnectionLess TCS (CL) used for signaling information exchange
It uses both point to point and point to multipoint signaling.
127
Amplify Mindware
Bluetooth
WAP, OBEX & IrDA
Chapter Twelve
WAP, OBEX & IrDA
Bluetooth provides the physical medium and link control for technologies like
WAP, OBEX. The characteristics of the Bluetooth and its environment can be used to
provide value added services using WAP or OBEX protocols.
12.1 W IRELESS APPLICATION PROTOCOL

The Wireless Application Protocol is designed by wapforum to connect
Internet and the wireless networks, thus providing Internet access on the wireless
devices like mobile phones. It bridges the gap between wired network and wireless
network. Limited communications bandwidth, memory, processing power, display
capabilities and input devices major factors in the development of WAP applications.
The WAP environment consists of the WAP Client device, the WAP Proxy/gateway
and WAP Server. The WAP Client device is device with the end user. This device
can be as a portable computer, or compact mobile phone. The WAP Proxy/gateway
acts as an interface between the wireless network, and the Internet. The primary
functions of the proxy are to provide DNS name resolution services to WAP client
devices and translation of Internet protocols and content formats to their WAP
protocols. The WAP server is often an HTTP server. The server exists as a storage
location for information that the user can access.
Fig 12.1 WAP Architecture
12.2 WAP
IN
BLUETOOTH
Bluetooth can be used to provide a bearer for transporting data between the
WAP Client and its adjacent WAP Server. Bluetooth medium provides a physical
bearer over which the data can be transferred.
128
Amplify Mindware
Bluetooth
WAP, OBEX & IrDA
12.2.1 INITIATION BY CLIENT DEVICE

When a WAP client is actively listening for available Bluetooth devices, it can
discover the presence of a WAP server using Bluetooths Service Discovery Protocol.
The WAP Client device is moving into range of the WAP Proxy/gateway's piconet.
When the client detects the presence of the WAP proxy/gateway, it can
automatically, or at the clients request, connects to the server.
The client must be able to determine the specific nature of the WAP
proxy/gateway that it has detected. It is expected that the Bluetooth Service
Discovery Protocol will be used to learn the following information about the server:
Server Name this is a user readable descriptive name for the server.
Server Home Page Document Name this is the home page URL for the
server.
Server/Proxy Capability indicates if the device is a WAP content server, a
Proxy or both. If the device is a Proxy, it must be able to resolve URLs that
are not local to the Server/Proxy device.
Fig 12.2: WAP in Bluetooth Piconet
12.2.2 TERMINATION BY CLIENT DEVICE

When the device detects that communication has been lost with the WAP
proxy/gateway, it may optionally decide to resume communications using the
information obtained at discovery.
12.2.3 INITIATION BY SERVER DEVICE
An alternative method of initiating communications between a client and
server is for the server to periodically check for available client devices. When the
129
Amplify Mindware
Bluetooth
WAP, OBEX & IrDA
server device discovers a client that indicates that it has WAP Client capability, the
server may optionally connect and push data to the client, although the client can
reject the pushed data.
Through the Bluetooth Service Discovery Protocol, the server can determine
the following information about the client:
Client Name this is a friendly format name that describes the client device.
Client capabilities this information allows the server to determine basic
information regarding the clients Bluetooth-specific capabilities.
12.3 NETW ORK SUPPORT
FOR
W AP
The following specifies a protocol stack, which may be used below the WAP
components. Support for other protocol stack configurations is optional, and must be
indicated through the Bluetooth Service Discovery Protocol.
PP/RFCOMM
Fig 12.3: Protocol Support for WAP
12.4 INTERPRETABILITY REQUIREMENTS

12.4.1 STAGE 1 BASIC INTEROPERABILITY
Stage 1 interoperability for WAP over Bluetooth (all mandatory):
Provide WAP Class A device compliance.
Provide, through service discovery mechanisms, the network address for
devices that support WAP proxy/gateway functionality.
130
Amplify Mindware
Bluetooth
WAP, OBEX & IrDA
12.4.2 STAGE 2 ADVANCED INTEROPERABILITY

Stage 2 interoperability for WAP over Bluetooth (mandatory):
All Stage 1 interoperability requirements are supported.
Provide Server Name and information about Server/Proxy capabilities through
service discovery.
Provide Client Name and information about Client Capabilities through
service discovery.
Asynchronous Notifications for Server.
Asynchronous Notifications for Client.
12.5 OBEX
AND
IRDA
IrOBEX is a session protocol defined by IrDA. This protocol is now also

utilized by the Bluetooth technology, making it possible for applications to use either
the Bluetooth radio technology or the IrDA IR technology. IrOBEX will be mapped
over the lower layer protocols, which are adopted by Bluetooth. Bluetooth uses only
the connection-oriented OBEX even though IrDA has specified the connectionless
OBEX also. This is because OBEX is mapped over the connection-oriented protocols
in the Bluetooth and most of application profiles using OBEX and Bluetooth need a
connection-oriented OBEX.
Fig 12.4: Bluetooth and OBEX
131
Amplify Mindware
Bluetooth
WAP, OBEX & IrDA
In the Bluetooth system, the purpose of the OBEX protocol is to enable the
exchange of data objects. The protocols can also communicate with the service
discovery DB. The figure above illustrates Bluetooth and OBEX.
Bluetooth Specification includes five separate specifications related to OBEX and
applications using it:
Bluetooth IrDA Interoperability Specification
Defines how the applications can function over both Bluetooth and IrDA
Specifies how OBEX is mapped over RFCOMM and TCP
Defines the application profiles using OBEX over Bluetooth
Bluetooth Generic Object Exchange Profile Specification
Generic interoperability specification for the application profiles using

OBEX
Defines the interoperability requirements of the lower protocol layers for

the application profiles
Bluetooth Synchronization Profile Specification
Application Profile for the Synchronization applications
Defines the interoperability requirements for the applications within the

Synchronization application profile
Does not define the requirements for the Baseband, LMP, L2CAP, or
RFCOMM
Bluetooth File Transfer Profile Specification
Application Profile for the File Transfer applications

File Transfer application profile
RFCOMM
Bluetooth Object Push Profile Specification
Application Profile for the Object Push applications

Object Push application profile
RFCOMM
12.6 OBEX OBJECT
AND
PROTOCOL
The OBEX object model describes how OBEX objects are presented. The
OBEX protocol can transfer an object by using the Put- and Get-operations. One
object can be exchanged in one or more Put-requests or Get-responses.
132
Amplify Mindware
Bluetooth
WAP, OBEX & IrDA
12.6.1 SESSION PROTOCOL

Response-request pairs form the OBEX operations. Requests are issued by
the client and responses by the server. After sending a request, the client waits for a
response from the server before issuing a new request. Each request packet consists
of a one-byte opcode, a two-byte length indicator, and required or optional data
depending on the operation. Each response packet consists of a one-byte response
code, a two-byte length indicator, and required or optional data depending on the
operation.
Connect Operation: An OBEX session is started, when an application asks
the first time to transmit an OBEX object. An OBEX client starts the
establishment of an OBEX connection. Sending a Connect-request starts the
session. The server accepts the connection by sending the successful
response to the client. Sending any other response (i.e. a non-successful
response) back to the client indicates a failure to make a connection. Once a
connection is established it remains alive, and is only disconnected by
requests/responses or by failures
Disconnect Operation: The disconnection of an OBEX session occurs when
an application, which is needed for an OBEX connection, is closed or the
application wants to change the host to which the requests are issued. The
client issues the Disconnect-request. The server cannot refuse the request
and it has to send the response.
Put Operation: When the connection has been established between the client
and server the client is able to push OBEX objects to the server. The Putrequest is used to push an OBEX object. A response packet from the server
is required for every Put-request packet. Thus, one response is not permitted
for several request packets, although they consist of one OBEX object.
Get Operation: When the connection has been established between the client
and server, the client is also able to pull OBEX objects from the server. The
Get-request is used to pull an OBEX object. The client has to send a request
packet for every response packet.
133
Amplify Mindware
Bluetooth
12.7 OBEX
WAP, OBEX & IrDA
OVER
RFCOMM
The Bluetooth specification defines following rules for Bluetooth devices to

handle OBEX over RFCOMM:
Bluetooth device supporting OBEX over RFCOMM must be able to act as
either servers or clients.
If Bluetooth device runs multiple OBEX servers at once, then each must have
its own RFCOMM server channel.
OBEX applications running must register their service record in SD database.
12.8 OBEX
OVER
TCP/IP
The Bluetooth specification defines following rules for Bluetooth devices to

handle OBEX over TCP/IP:
Bluetooth device supporting OBEX over TCP/IP must be able to act as either
servers or clients.
The server must use default port number 650 or a value above 1023.
The client will initiate the socket with the above-defined port.
OBEX applications running must register their service record in SD database.
134
Amplify Mindware
Bluetooth
WAP, OBEX & IrDA
Summary
Bluetooth medium provides a physical bearer over which the data can be
transferred.
The OBEX object model describes how OBEX objects are presented.
OBEX can run over RFCOMM and TCP/IP
135
Amplify Mindware
Bluetooth
WAP, OBEX & IrDA
P A R T T H REE
BLUETOOTH PROFILES
136
Amplify Mindware
Bluetooth
References
Chapter Thirteen
Profiles
13.1 INTRODUCTION
The entire Bluetooth specification must be used in order to implement the enduser applications and this is the main objective of profile. To provide interpretability the
end product developed by various vendors must follow a common standard defined in
the profile. The profile provides procedures and messages (termed as capabilities) that
needs to be implemented in order to provide robust Bluetooth applications in a
standardized ways.
Bluetooth defines various profiles to provide interpretability between various
Bluetooth products. The diagram below shows how various profiles are utilized. Each of
this profile is build over another profile, such that the higher layer profile uses features
from its lower layer profile.
Fig 13.1: Bluetooth profiles

The Bluetooth user should in principle be able to connect a Bluetooth device to
any other Bluetooth device, Even if the two connected device do not share any common
137
Amplify Mindware
Bluetooth
References
application, it should be possible for user to find this out using basic Bluetooth
capabilities.
13.2 GENERIC ACCESS PROFILE (GAP)

The main purpose of this profile is to provide its facilities to the lower layer
profiles. It is the basic profile over which other profiles are built. GAP ensures that all
other profiles are able to establish a baseband link.
GAP defines:
Basic requirements for smooth functioning of devices
Generic procedures for device discovery
Link management
Procedures for security
Device parameters accessible to the user through user interface
13.2.1 OPERATION MODES
GAP defines modes for basic implementation of the Bluetooth devices. The
modes are described in detail below:
Discoverability: This mode defines the basic inquiry and scans procedures for
discovering Bluetooth devices within the RF proximity. This mode is further
divided into three basic types:
Non-discoverable device will not perform any inquiry related procedures

and hence cannot be found by any other device.
Limited discoverable device performs inquiry related procedures using

LIAC Limited Inquiry Access Code and hence will be discovered by
those devices, which perform inquiry procedures using LIAC.
General discoverable device performs inquiry related procedures using

GIAC General Inquiry Access Code and hence will be discovered by
those devices, which perform inquiry procedures using GIAC.
Connectability: This mode defines the basic paging procedures for connecting
Bluetooth devices within the RF proximity. This mode is further divided into two
basic types:
Connectable mode devices perform paging procedures periodically and

allow other devices to connect with it.
138
Amplify Mindware
Bluetooth
References
Non-Connectable mode devices do not perform paging procedures

periodically and are dependent on other devices for establishing the links.
Pairability: This mode provides basic pairing procedures for link establishment for
security and encryption purposes. Pairing is the process in which two devices
pair with each other to exchange the link keys used for security. But before
pairing the device much establish a relationship-based link between them called
as bonding. Thus pairing becomes mandatory if bonding is supported. This
provides two modes pairing and non-pairing mode.
Security: This mode controls security i.e. authentication and encryption after
pairing is done. Three security modes are supported:
o
Non-secure No security exists
Service level enforced security Security initiated by L2CAP channel

establishment.
Link level enforced security Security initiated by baseband ACL link

establishment.
13.3 SERIAL PORT PROFILE (SPP)

The Serial Port Profile defines the protocols and procedures that shall be used by
devices using Bluetooth for RS232 (or similar) serial cable emulation. This helps in
keeping the legacy systems same as before without any modifications treating the
Bluetooth link as a serial cable link This profile supports two types of devices Type 1
devices emulating serial port to support serial port applications and Type 2 devices
forming communication link part that helps to connect serial based applications with the
Bluetooth applications, thus providing an interface between Bluetooth applications and
wired applications.
The SPP uses RFCOMM for the purpose of serial port emulation. The initiator is
a device that sets the RFCOMM connection and the other device, which responds, is
called responder.
Initially this profile has to acquire the Bluetooth address of the device at other
end of the RFCOMM connection. This can be done by inquiry procedures, user input
and pairing. Next a baseband ACL link has to be established with the chosen device.
L2CAP channel is created with the SDP server that retrieves the RFCOMM number of
the serial port in action. L2CAP channel is created in RFCOMM responder. Multiplexing
139
Amplify Mindware
Bluetooth
References
is then performed across the L2CAP channel. Thus a virtual link is created over which
RFCOMM frames can be transferred.
13.4 DIAL
U P N E TW O R K I N G P R O F I LE
This profile is used to establish a dial up connection to allow the computing

device to access the PSTN. This is achieved by using services of communicating
devices like mobile. This connection can be made using RAS Remote Access Server
or the cordless modem. Thus a modem or mobile acts as a gateway to PSTN network.
This connection establishment follows a procedure as follows:
Baseband link is established by paging.
Using this link and L2CAP channel is established.
Using this channel service discovery information can be fetched.
After this further query for other services can be done or the channel can be
dropped.
Second L2CAP channel should be established to actually avail the service
discovered.
RFCOMM connection is established across this channel.
This RFCOMM connection is finally used for dial up networking connection.
Security procedures can occur over the RFCOMM connection before dial up
connection is set up.
The dial up connection can later be controlled using standard AT command set
that allows dialing, echoing, volume control etc.
For audio support SCO link channel has to be established.
13.5 FAX PROFILE

FAX profile is used to exchange FAX messages without the use of cables. This
profile is similar to the dial up profile. The procedure for setting up the FAX connection is
same as that of dial up network. The main difference between the two profiles is security
is compulsory in FAX while it is optional in dial up.
140
Amplify Mindware
Bluetooth
References
13.6 HEADSET PROFILE

This defines the facilities require to make and receive hands-free voice calls from
headset to cellular phone. It can also transfer voice calls to other devices.
This profile defines two major roles:
Audio Gateway (AG)
Headset
The procedure of establishing a call to a Bluetooth headset is as follows:
Audio gateway initiates the process, since it receives the incoming call.
An ACL link is first set up done by paging or by unparking the parked devices
that are already synchronized to the master.
A ring tone is send over this ACL link.
A SCO link is set up for voice transfer once the user accepts the call.
This SCO link is used later for voice transfer.
13.7 LAN ACCESS PROFILE

This profile enables a Bluetooth device to gain access to the fixed network using
LAN Access Point LAP. Such a device can be used as a Personal Work Access Point,
connecting computer peripheral without cables, Shared Access Point in conference
room, Public Access Point allowing fast access to public information and services. PINs
are used to secure the LAPs. This profile defines a PPP over RFCOMM to link the IP
stack.
The connection to LAP is defined as follows:

The connecting device must find the LAP using inquiry and scanning procedures.
The baseband link is established between the data terminal and LAP.
Using this link the L2CAP channel is established and the data terminal queries
the services with LAP giving parameters that are use to connect LAP.
RFCOMM and PPP connections are established across the L2CAP channel.
The data terminal then negotiates an IP address for accessing the LAN.
Authentication and encryption can be implemented over the PPP link.
141
Amplify Mindware
Bluetooth
References
13.8 GENERIC OBJECT EXCHANGE PROFILE (GOEP)

The Generic Object Exchange profile defines the protocols and procedures that
shall be used by the applications providing the usage models, which need the object
exchange capabilities. The usage model can be, for example, Synchronization, File
Transfer, or Object Push model.
GOEP uses IrDAs OBEX objects to transfer the data between Bluetooth devices.
To implement this two roles are define server device and client device. Information is
transferred using OBEX objects with the help of header that contains count, name, type
etc. Authentication process is mandatory.
13.9 FILE TRANSFER PROFILE

This profile transfers data between any numbers of Bluetooth devices. It uses the
capabilities provided by OBEX. This profiles pulls or pushes the OBEX objects thus
transferring the information. The file transfer profile provides various operations required
for this purpose. This operations can be file copy, delete etc. In addition to this, browsing
capabilities using OBEX objects are provided. Various OBEX operations are used to
implement the file transfer profile.
13.10 OBJECT PUSH PROFILE

This provides facilities to transfer business cards between client and server. This
is implemented using Push and Pull operations with the help of OBEX objects. All
devices support for authentication and encryption over baseband links. This makes the
transfer more secured. Before the exchange can occur, the server must be discovered.
The client inquires about the server in its RF proximity. Using service discovery
procedures it finds which devices acts as a server and supports object push profile. After
this the client offers the user for the services available for business cards transfer.
13.11 SYNCHRONIZATION PROFILE

This profile provides capabilities to synchronize two Bluetooth devices for reliable
data transfer. The synchronization can occur when two Bluetooth devices supporting this
profile come into range of each other. This process occurs automatically without user
intervention. Consider an example where the user having the phone book in his mobile
wants to synchronize this data with the laptop phone book. The mobile in this case use
the service discovery procedures to discover the laptops in its range. It provides with list
142
Amplify Mindware
Bluetooth
References
of laptops to the user, who selects the required laptop for synchronization to proceed.
However, before the synchronization could occur, PIN is exchange for security. The
devices are bonded using the authentication process. After the link is secured the
synchronization is completed.
13.12 INTERCOM PROFILE

This profile provided point to point connection to be established between
Bluetooth devices or Bluetooth headset for voice transfer. The TCS layer of Bluetooth
supports control facilities to implement this profile. This signaling is carried across ACL
link, which routes through L2CAP channel. The Calling device must set baseband ACL
link to the devices it wishes to call. Using this link L2CAP channel is set that is used to
carry TCS signaling. Once this signaling is done intercom link is set up for voice transfer.
13.13 CORDLESS TELEPHONY PROFILE

This profile helps the Bluetooth device to connect to any base station of the
wireless network. Two roles are defined in this profile gateway connecting the external
network and receive incoming calls and the terminal that receives the calls from the
gateway thus providing access of external network to the end user. The gateway acts as
a master of piconet. The gateway passes the calls to the terminal thus allowing the
Bluetooth device to gain access to the services like telephony etc.
143
Amplify Mindware
Bluetooth
References
Summary
The profile provides procedures and messages (termed as capabilities) that
needs to be implemented to provide Bluetooth applications in a standardized
ways.
The main purpose of GAP profile is to provide its facilities to the lower layer
profiles.
GAP operates in different modes like Discoverability, Connectability, Pairability,
and Security.
The Serial Port Profile defines the protocols and procedures that shall be used by
devices using Bluetooth for RS232 (or similar) serial cable emulation.
Dial up networking profile is used to establish a dial up connection to allow the
computing device to access the PSTN.
FAX profile is used to exchange FAX messages without the use of cables.
Headset profile defines the facilities require to make and receive hands-free
voice calls from headset to cellular phone.
LAN Access profile enables a Bluetooth device to gain access to the fixed
network using LAN Access Point LAP.
GOEP defines the protocols and procedures that shall be used by the
applications providing the usage models
Object push profile provides facilities to transfer business cards between client
and server.
Synchronization profile provides capabilities to synchronize two Bluetooth
devices for reliable data transfer.
Intercomm profile provided point to point connection to be established between
Bluetooth devices or Bluetooth headset for voice transfer
Cordless telephony profile helps the Bluetooth device to connect to any base
station of the wireless network
144
Amplify Mindware
Bluetooth
References
References
Jennifer Bray, Charles.F.Sturman, Bluetooth, Connect without cables Pearson

Education, Inc., 2001.
Brent A.Miller, Chatschik Bisdikian, Bluetooth Revealed Pearson Education, Inc, 2001.
Bluetooth: The Basics BPB Publications, 2001.
145
Amplify Mindware
Bluetooth
Further Reading/Information Resources
Further Reading/Information Resources
www.bluetooth.org
www.bluetoothnews.com
www.infotooth.com
www.palowireless.com
146
Amplify Mindware

Bluetooth

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Bluetooth

Caricato da

Copyright:

Formati disponibili

Bluetooth

Bluetooth Protocol and Network Aspects

Baseband / Link Controller

Link Manager Protocol

Host Controller Interface

Logical Link Control and Adaptation Protocol

Service Discovery Protocol

Telephony Control Protocol

WAP, OBEX and IrDA

Voice and data

Anywhere in the world

The Bluetooth Special Interest Group

Technology and SIG Origins

The Bluetooth Name and History

The Aim of Bluetooth

Bluetooth comparisons with other wireless technologies

Bluetooth Protocol and Network Aspects

Maximum Usable Level

Receiver Signal Strength Indicator

Baseband / Link Controller

1/3 rate FEC

2/3 rate FEC

Data Whitening or bit randomization

LOG PCM Codec

Link Manager Protocol

The Procedure Rules and PDUs

General Response Messages

Change Link Key

Change the Current Link Key

Clock Offset Request

Slot Offset Information

Time Accuracy Information Request

Switch of Master-Slave Role

Power Control Mode

Channel Quality-Driven Change between DM & DH

Host Controller Interface

Bluetooth Hardware Block Diagram

HCI Packet Types

Commands and Events

Link Control Commands

Link Policy Commands

Host Controller and Baseband Commands

Host Controller Transport Layer

USB Transport Layer

Serial Transport Layer

UART Transport Layer

RS232 Transport Layer

Logical Link Control and Adaptation Protocol

L2CAP Functional Requirements

Channels and channel Identifiers

Operation between Devices

L2CAP State Machines

Some Service Primitives

RS232 Control Signals

Null Modem Emulation

Multiple Emulated Serial Ports between two devices

Multiple Emulated Serial Ports between more devices

Service Definition Model

TS 07.10 Subset Support by RFCOMM and its Adaptation

Basic Option Frame

TS 07.10 Multiplexer Startup & Closedown Procedure

L2CAP Flow Control

Wired Serial Port Flow Control

RFCOMM Flow Control