Bluetooth Revealed , By Brent A.

Miller, Chatschik Bisdikian

Foreword
My work with the Bluetooth wireless technology, which began long before it became Bluetooth,
has been a privilege and an extremely rewarding experience. In 1997, when a few major players
in the telecommunications and portable computing industries engaged in some initial discussions,
no one could even dream of the unprecedented success the program was to enjoy a few years
down the road. We all knew that there was a great need for a low-power, low-cost, short-range
cable replacement, but from there to the overwhelmingly favorable industry and media response
was a quantum leap.

The Bluetooth SIG managed from the beginning to focus on consumer requirements rather than
just designing the technically best possible radio. A zero-cost license, good marketing (of course)
and a bit of luck with the timing are always useful, too, when you want to establish a worldwide
de facto standard.

Predictions from many independent sources, such as Frost & Sullivan, Cahners In-Stat, Merrill
Lynch and many other research institutes, indicate that indeed the Bluetooth wireless technology
will become a smashing success, with as many as 1.5 billion or more devices being equipped with
Bluetooth wireless technology in the year 2005.

With tens of thousands of engineers around the world working on implementations and perhaps
even hundreds of thousands of other people such as students and professionals becoming
interested in this technology, it is easy to understand the need for the publication you have in
your hands.

Written by people involved from the beginning in key roles to develop the Bluetooth specification,
you will find the book to be most authoritative. Perhaps even more importantly, it is written in an
easy-to-understand way, explaining a lot of the thinking behind the development of many
chapters in the specification.

In short, Bluetooth Revealed: The Insider's Guide to an Open Specification for Global Wireless
Communications provides an important source of easy-to-access information about this new and
exciting technology.

I look forward to seeing you in my "piconet" soon!

Anders Edlund
Marketing Director, Bluetooth Product Unit
Ericsson Mobile Communication

1
Preface
The convergence of computing and communications has been predicted for many years. Today's
explosion of a myriad of new types of personal computing and communications devices—
notebook computers, personal digital assistants, "smart" phones, two-way pagers, digital
cameras and so on—has resulted in new ways for people to communicate and gain access to
data. The advent of this pervasive computing, especially via wireless communications, enables
these devices to be used in new settings: not only can people make voice calls from their
automobile using a mobile phone, but also they can access the World Wide Web from a wireless
notebook or handheld computer while at the airport or a shopping mall. We are rapidly moving
toward a world where computing and communications become ubiquitous—not only at work but
also in the home, in public places and in personal surroundings.

Until recently, enabling all of these devices to communicate with each other has been
cumbersome, often involving the use of special cables to connect the devices together along with
device-specific software that might use proprietary protocols. To exchange information among all
of her personal devices, a person might need to carry as many cables as devices and still lack
assurance that all the devices could interconnect. The inability to share information among
devices or the difficulty in doing so limits their usefulness.

The Bluetooth™ technology enables devices to communicate seamlessly without wires. While
Bluetooth wireless communication is first and foremost a means for cable replacement, it also
enables many new applications—the use of a single mobile telephone as a cellular phone,
cordless phone or intercom and the use of a notebook computer as a speakerphone, just to name
two. The Bluetooth Special Interest Group (SIG) was formed in early 1998 by Ericsson®, Intel®,
IBM®, Nokia® and Toshiba® to develop an open specification for globally available short-range
wireless radio frequency communications. The SIG has published a specification for the Bluetooth
radio and baseband along with a set of communication protocols comprising a software stack
used with the Bluetooth radio hardware. The Bluetooth radio module design is optimized for very
low power consumption, low cost, small footprint and use anywhere in the world. In addition to
the core specification, the SIG has also published Bluetooth profiles that describe how to use the
software protocols such that interoperability among all kinds of devices can be achieved,
regardless of who manufactures these devices. Version 1.0 of the specification was published in
July 1999. Today the Bluetooth Special Interest Group consists of nine promoter companies
(joining the five founding companies noted above in the SIG's core group are 3Com®, Lucent®,
Microsoft® and Motorola®) and well over 1,800 adopter companies from around the world,
representing a diverse set of industries.

The specification and profiles continue to evolve as the SIG develops new ways to use the
Bluetooth technology. The first products with Bluetooth wireless communications arrived in 2000
led by development tools, mobile telephones, audio headsets, notebook computers, handheld
computers and network access points.

A great deal of interest, talent and energy has marshaled around this exciting new technology.
Until now most of the information available about Bluetooth wireless communications has been
from the SIG's official web site (http://www.bluetooth.com) or from brief press articles or
newsletters. This book aims to be at once authoritative and accessible. Besides discussing
background, history and potential future developments, Bluetooth Revealed: The Insider's Guide
to an Open Specification for Global Wireless Communications delivers practical explanations of
the specification by people who helped to develop it. It is a broad discussion of the topic,
containing information that should be of value to industry practitioners, professionals, students
and any others who are interested in this topic. No matter what your particular interest is,
Bluetooth Revealed is intended to give you the information you need to become a "Bluetooth
Insider."

2
Acknowledgements
We already knew that developing the Bluetooth technology was a tremendous undertaking, and
we now have discovered that writing a book is a lot of work. The fun part is being able to include
a short list of people who supported, encouraged or otherwise aided in the development of this
book or of the Bluetooth technology that makes this book relevant.

At the risk of omitting those who deserve mention, both authors acknowledge all of the members
of the Bluetooth SIG who worked passionately and tirelessly as a team to make the technology
possible, especially our Air and Software Working Group colleagues who made a major
difference: Jon Inouye of Intel; Thomas Muller, Stephane Bouet and Riku Mettälä of Nokia;
Johannes Elg, Jaap Haartsen and Tobias Melin of Ericsson; Dale Farnsworth of Motorola; Shaun
Astarabadi of Toshiba; Paul Moran and Ned Plasson of 3Com; and most of all our IBM colleagues
around the globe who worked to advance the Bluetooth technology, most notably our teammates
Peter Lee, Mahmoud Naghshineh, Nathan Lee, Parviz Kermani, Brian Gaucher and Toru Aihara
and former IBM colleague Pravin Bhagwat. We are also indebted to Bouet, Elg and Aihara-san,
along with Gabriel Montenegro of Sun Microsystems, for their exemplary and valuable technical
review of the book. We also acknowledge Mary Franz and her team at Prentice Hall PTR, whose
support, expertise and responsiveness made it possible to carry out this project.

Brent Miller thanks Sandeep Singhal for his experienced author advice; his co-author Chatschik
Bisdikian, who wrote all the hard parts; his wife Laurie and sons Benjamin and Andrew for their
encouragement and support; and God who makes this and all things possible.

Dr. Chatschik Bisdikian thanks co-author Brent for inviting him to contribute to this project and
patiently rewriting in plain English what he wrote; his manager Mahmoud Naghshineh for
encouraging him (rather strongly and persistently) to get involved with the Bluetooth wireless
technology from the outset; and last but not least his wife Teresa and sons Eugene and Theodore
for their unconditional encouragement and support through long nights and weekends of working
on this project.

Trademark List
• Bluetooth is a trademark owned by Telefonaktiebolaget L M Ericsson, Sweden and licensed
to promoters and adopters of the Bluetooth Special Interest Group.
• Ericsson is the trademark or registered trademark of Telefonaktiebolaget LM Ericsson.
• Intel is a registered trademark of Intel Corporation.
• Microsoft, Windows and Universal Plug and Play are trademarks or registered trademarks
of Microsoft Corporation in the United States and/or other countries.
• Motorola is a registered trademark of Motorola Incorporated.
• IrDA is a registered trademark of the Infrared Data Association.
• Linux is a registered trademark of Linus Torvalds.
• Symbian is a trademark of Symbian, Ltd.
• Jini is a registered trademark of Sun Microsystems Incorporated in the United States,
other countries, or both.
• Salutation is a registered trademark of the Salutation Consortium, Incorporated.
• PUMATECH is a trademark or registered trademark of Puma Technology, Incorporated,
also dba PUMATECH, Inc.
• Extended Systems is a trademark of Extended Systems Incorporated.
• HomeRF is a trademark of the HomeRF Working Group
• Hewlett-Packard is a trademark or registered trademark of Hewlett-Packard Company in
the United States and/or other countries.
• Philips is a trademark or registered trademark of Koninklijke Philips Electronics N.V.

3
4
Part 1: Introduction to Bluetooth Wireless
Communication
This book begins with background information about Bluetooth wireless
communication. The technology is described at the highest level and its origins and
history are explored, including the story of how this technology came to be named
Bluetooth. The Bluetooth Special Interest Group is described from the authors' own
perspective as participating members. Chapter 1 contains a reader's guide for the
remainder of the book. In Chapter 2 the basics of wireless communications are
covered, including spread spectrum radio frequency communications in the 2.4
gigahertz spectrum and infrared communications, both of which influence the
Bluetooth specification. The fundamental principles of Bluetooth communication,
including master and slave roles, baseband modes and communication topology
are presented. Chapter 3 describes most of the well-known usage models in which
Bluetooth wireless communication can be employed. In these usage scenarios the
end user's viewpoint and derived benefits are emphasized. Finally Chapter 4
provides an introduction to the Bluetooth core specification and profiles that are
explored in detail in Parts 2 and 3 of the book, respectively.

Part 1 is designed to aid readers who are not already familiar with Bluetooth
wireless communication in understanding the fundamentals of the technology and
how that technology came to be. At the same time, readers already familiar with
Bluetooth wireless communication may discover new information or perspectives
that will further their understanding of this important new technology.

Chapter 1. What Is Bluetooth?

The term Bluetooth™[1] 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[2] includes several points that are key to its
understanding:
[1]
Bluetooth is a trademark owned by Telefonaktiebolaget L M Ericsson, Sweden and licensed to promoters and adopters of the
Bluetooth Special Interest Group.

[2]
The Bluetooth Brand Book contains guidelines for the use of the term Bluetooth. To be consistent with those guidelines, we
will henceforth use the term as an adjective, not as a standalone noun.

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.

Short-range wireless: There are many instances of short-range digital communication among
computing and communications devices; today much of that communication takes place over
cables. These cables connect to a multitude of devices using a wide variety of connectors with
many combinations of shapes, sizes and number of pins; this plethora of cables 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

5
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.

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 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.

Anywhere in the world: 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 (with certain limitations and restrictions that
are discussed later in the book). 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 today's pervasive devices. The Bluetooth specification ([BTSIG99], hereafter
referred to as the 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 a plethora of fixed and mobile devices can enable many other new and
exciting usage scenarios beyond simple cable replacement. In this book we explore various
applications of the technology.

Important characteristics and applications of Bluetooth wireless communications are examined in

detail in this book. The Bluetooth specification is explained in easy-to-understand terms with the
benefit of the authors' experiences gained while participating in its development. If Bluetooth
wireless technology succeeds in the marketplace to the extent predicted by many analysts, it has
the potential to change people's lives and the way that people think about and interact with
computing and communication devices. Understanding this emerging technology can benefit not
only industry professionals but also consumers who can use and obtain value from it.

The Bluetooth Special Interest Group

As described above, 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
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 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.

6
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 today's computing and communications industries, proprietary new technologies rarely

succeed; customers clearly prefer to purchase and deploy technologies based upon industry
standards. By creating a level playing field, standards give customers greater freedom to choose
from among competing platforms and solutions, to protect their investments as technologies
evolve and to leverage (and in some cases, also influence) multicompany skills and organizations
devoted to developing the standards.

In this industry environment, the Ericsson inventors understood that the technology was more
likely to be widely accepted, and thus could be more powerful, if it was adopted and refined by an
industry group that could produce an open, common specification. 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.

While open standards can be quite advantageous, one potential disadvantage of standards
bodies, consortia, special interest groups and similar organizations is that they tend toward
inherent inefficiencies as compared to single-company efforts. Within a single company there is
often one overriding objective for developing new technology; in a multi-company effort each
participant may have different, perhaps even competing goals. Even with modern ways to
exchange information, such as electronic mail, group interactions are still likely to be more
efficient within a single organization than throughout a group composed of many organizations
(especially when those organizations are geographically diverse, as is the case for the members
of the SIG—telephone calls, for example, have to take into account the fact that the people
involved reside in time zones with little or no overlap of typical working [or even waking] hours).
To overcome some of these potential drawbacks, the SIG intentionally was created with a small
number of companies committed to the rapid development of the specification who were willing
to expend the resources necessary to accomplish this.

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
SIG's 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 exchanges,
the SIG produced a thorough specification (together, the volume 1 core specification and volume
2 profiles number over 1,500 pages) in about one and one-half years (version 1.0 of the
specification, including profiles, was published in July 1999).

7
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.

During the one and one-half years that the SIG was developing the specification, working groups
and task forces met and conducted their business both together and separately. Full working
group (and sometimes complete SIG) meetings were held every few weeks, often hosted by
promoter companies in locations where many of their involved personnel worked—these included
Ericsson's Lund, Sweden facility; Intel's Chandler, Arizona software laboratory; IBM's sites in
Research Triangle Park, North Carolina and Hawthorne, New York; and Nokia's Tampere, Finland
location. Most working groups and task forces also held weekly conference calls. In addition, e-
mail distribution lists were used liberally and in fact were a primary method for conducting
working group business. Because of the geographic diversity of the people involved, it was
difficult to find mutually convenient times for frequent voice conversations;[3] thus electronic mail
quickly became a convenient and heavily used means of communication (in many respects it
allowed specification development around the clock). Indeed, the official ratification of the final
versions of the specification, profiles and errata was conducted using the e-mail reflectors.
[3]
When it was 9:00 a.m. on the west coast of the United States, where many involved parties worked and lived, it often
(depending upon daylight-saving time observance) was 7:00 p.m. in Finland and 2:00 a.m. the following morning in Japan).

In December 1999, four new promoter companies (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. This work is discussed in further detail in Part 4 of this book.

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 year's time. For many in the SIG this became their full-time
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. A spirit of
cooperation, fostered by the common objective of producing an open specification for this
important new technology, usually carried the day (at least in the authors' experience in the
software and interoperability working groups).

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

8
associated technology or its application and often they quickly become known by an acronym
describing the full name. Why wasn't the technology called, for example, "Short-Range Wireless
Radio," or SRWR, or some other descriptive name? The answer lies in the heritage (and perhaps
the whimsy) 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 Blåtand 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 "Blåtand" 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 (some histories say that the name is attributed to Harald's dark complexion;
some accounts even indicate that King Harald was known for teeth of a bluish hue resulting from
his fondness for blueberries, although this is probably folklore). 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 (see footnote 1 on page 3) 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. The Bluetooth logo, a trademark owned by

Telefonaktiebolaget L M Ericsson, Sweden and licensed to promoters and
adopters of the Bluetooth Special Interest Group.

Bluetooth wireless communication has engendered tremendous interest since the SIG's 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. Between November 1998 and June 2000 at least
nine major Bluetooth developers conferences were held in cities including Atlanta, Tokyo, London,
Amsterdam, Geneva, Los Angeles and Monte Carlo. The SIG-sponsored conference in December
1999 in Los Angeles attracted over 2,000 developers from diverse geographies and industries.

Reader's Guide to This Book

This chapter has introduced the Bluetooth Special Interest Group, the technology, its chief
characteristics and the history of its development. The remaining chapters of Part 1 provide
additional background intended to aid in understanding the technology and what it can do.

Chapter 2 discusses wireless communication technologies in general and the Bluetooth radio
frequency wireless solution in particular, including requirements and design choices for use of the

9
2.4-gigahertz spectrum, radio power consumption, "master/slave" radio relationship, adaptive
audio range, "piconet" and "scatternet" topologies and global radio use.

Chapter 3 describes the significance of developing usage models for Bluetooth wireless
communication and how these usage models relate to Bluetooth profiles. Each of the usage
models is described, focusing on the benefits and value for a product's end user. Distinctions are
drawn between those usage models enabled with version 1.0 of the specification and those
intended for future use.

Chapter 4 briefly explains the purpose, scope, structure and relationships of the Bluetooth
specification and profiles, serving as an introduction to Parts 2 and 3 where these topics are
covered in detail.

"Part 2: The Bluetooth Specification Examined" introduces the Bluetooth protocol stack in
Chapter 5, partitioning the stack into transport, middleware and application protocol groups. In
Chapter 5 the relationships among the various layers of the stack are examined, and each of the
remaining chapters in Part 2 then covers one or more of these layers in detail. The intent is not
just to reiterate information already available in the specification but rather to provide
information that supplements the specification and aids in its understanding. Wherever possible
we include information about the history, rationale and justification of the technical contents of
the specification based upon our participation in its development.

Chapter 6 describes the radio hardware, link controller, baseband, and link manager layers of
the protocol stack. Together these layers comprise the lower layers of the transport group of the
protocol stack. Topics covered include the motivation and design tradeoffs behind the radio and
baseband specifications, including the choice of the 2.4 gigahertz ISM frequency band; the
reasons behind some of the radio and baseband parameters; the choice of the master/slave
baseband model; the basis for the piconet and scatternet topologies; and the motivation and
design tradeoffs for security features such as pairing and encryption.

Chapter 7 describes the logical link control and adaptation protocol (L2CAP) and host controller
interface (HCI) layers of the protocol stack. We call these the upper layers of the transport group
of the protocol stack, and they form the basis for the remainder of the software stack, including
any new protocols that may be introduced in the future. Topics covered include the motivation
and design tradeoffs leading to the development of the HCI and the situations in which this layer
is relevant; issues with flow control and its architectural placement within the stack; and how
higher-layer elements of the stack can use and benefit from L2CAP.

Chapter 8 presents the RFCOMM and service discovery protocol (SDP) layers of the protocol
stack. These are middleware layers that provide abstractions in the form of logical interfaces and
message transactions that can be used by application layers. Topics covered include the
motivation and design tradeoffs for specifying a logical serial interface and its resulting benefits;
how legacy applications could use Bluetooth wireless communication via RFCOMM; the motivation
and design tradeoffs for specifying a new discovery protocol; and how SDP maps to other
discovery protocols.

Chapter 9 describes the IrDA® Interoperability layers of the protocol stack. These are layers of
the protocol stack that incorporate protocols and object formats specified by the Infrared Data
Association (IrDA) into the Bluetooth specification. Topics covered include the motivation and
design tradeoffs for reusing existing IrDA protocols and object formats; how existing IrDA
applications could use Bluetooth wireless communications; and similarities and differences
between IrDA and Bluetooth wireless communications.

Chapter 10 discusses the telephony control specification (TCS) layer of the protocol stack and
also describes how voice and audio communications are managed. Together audio and TCS
10
provide full telephony support for both voice and data calls. Topics covered include the motivation
and design tradeoffs for specifying separate voice and data channels; reasons for the selection of
voice encoding techniques, including tradeoffs of quality and efficiency; and alternative forms of
telephony control protocols and why TCS was chosen.

In "Part 3. The Bluetooth Profiles Examined" we look into volume 2 of the Bluetooth
specification, commonly known as the Bluetooth profiles, in the same manner in which we
covered the core specification in Part 2. Chapter 11 examines the motivation for, development
of and relationships among the various profiles, which define how to use the protocol stack to
achieve interoperable solutions. Each of the remaining chapters in Part 3 then covers one or more
of these profiles in detail. Just as in Part 2, the intent of these chapters is not simply to reiterate
information already available in the profile specification but rather to provide information to
supplement the specification and aid in its understanding.

Chapter 12 describes the generic access profile (GAP) and the service discovery application
profile (SDAP). These profiles define fundamental principles used to establish connections among
devices with Bluetooth wireless communication capability and provide a basis upon which the
remaining profiles are built. Topics covered include the motivation and design tradeoffs for
security features such as pairing and encryption; the various possibilities for devices to be
discovered; and how applications could access and make use of the service discovery protocol for
service location and browsing.

Chapter 13 discusses the telephony class of profiles, including cordless telephony, intercom and
headset. These profiles define various ways to use voice communication and call control for
telephony applications. Topics covered include the motivation and design tradeoffs for selection of
the version 1.0 telephony profiles; 10-meter versus 100-meter radio range with respect to the
intercom profile; and current and future applications for voice headsets developed according to
the headset profile.

Chapter 14 presents the serial port-based class of profiles, including generic object exchange,
object push, file transfer and synchronization in addition to the common serial port profile itself.
These profiles all define ways to use the RFCOMM virtual serial port to exchange and synchronize
data between two peer devices. Topics covered include the serial port profile "family tree";
configuration of the serial port profile and the relevance of typical serial parameters in Bluetooth
wireless communications; why the distinction between object exchange, object push and file
transfer is important; and current and future possibilities for data synchronization.

Chapter 15 describes the networking class of profiles that includes dial-up networking, LAN
access and fax. These profiles all deal with some variation on data networking between two or
more peer devices. Topics covered include limitations of Bluetooth wireless communications
relative to some fax requirements; the relevance and value of audio feedback for dial-up
networking; and the many possibilities for networking with Bluetooth wireless communications
and why LAN Access using PPP was chosen for version 1.0.

"Part 4. The Future of Bluetooth Wireless Communications" looks at where the technology
is headed. Chapter 16 discusses future possibilities for the technology, including those that the
SIG is currently developing: automotive, imaging, printing, extended service discovery,
association with the IEEE 802.15 standards organization and others. This chapter discusses how
new usage cases might be realized using Bluetooth wireless communication and how industry
innovators might go about developing new Bluetooth wireless communication solutions. In
addition, the product landscape for Bluetooth wireless technology is explored, including the
current and projected marketplace. Chapter 17 summarizes the book and offers concluding
remarks about the future of Bluetooth wireless communication, including a short discussion of
interoperability and the opportunities that the technology presents.

11
Chapter 2. Technology Basics
Communication can take many forms—audio, visual, written, electronic and so on. In the realm
of electronics, analog and digital communications are so pervasive in modern society that they
are largely taken for granted. The exchange of data using these forms of communication has led
to the use of terms such as "the information industry" and "the information age." From
telephones to computers to televisions, communication in many respects "makes the world go
around." Bluetooth wireless technology is one form of electronic communication, and in this
chapter we examine some of its fundamental and specific characteristics, including relationships
to other forms of communication. We begin with a brief general discussion of wireless
communications and then progress through more specific forms relevant to the Bluetooth
technology. There are many other types of wireless communication; our intent here is to touch
upon those that provide background for the Bluetooth technology rather than to provide a primer
on wireless technologies in general.

Wired and Wireless Communications

A great deal of data is carried over wired networks—many telephones, coaxial cable systems,
local area networks and parts of the Internet communicate via wires and cables. Many televisions
are connected to cable systems, most networked computers are connected to telephone lines or
wired networks such as Ethernet networks, and even cordless and mobile telephones rely on
wired "landline" telephone systems to carry and route calls between endpoints.

Communicating without wires is not a new concept. Broadcast radio and television are two
common examples of wireless communications; others include satellites, cordless and cellular
telephones and remotely controlled televisions, garage door openers and automobile door locks.
While most of these examples employ communication via radio waves, the use of infrared, a
nonvisible spectrum of light, is also relatively common. Bluetooth wireless communication
employs radio frequency (or RF) technology, using radio waves to communicate through the air
in a manner fundamentally similar to broadcast radio or television.

Radio Frequency Wireless Communications

RF technologies employ transmitters and receivers tuned to produce and consume, respectively,
radio waves of a given frequency range. The transmitter's power and the receiver's sensitivity
help to determine the distance over which they can communicate. High transmission power
output is used for long-range communications such as broadcast television while short-range
communications generally require much less power; thus technologies that are designed to
communicate across only a few meters could be employed in small, mobile battery powered
devices. Another characteristic that is relevant for communication applications is the ability of
radio waves to penetrate many objects. Obstacles reflect light waves used in technologies such
as infrared, but radio waves used in RF technologies in general can (with certain limitations)
penetrate many obstacles (although in some cases radio waves can diffract or go around objects
too). Thus RF technologies can permeate many obstacles such as clothing, bodies, walls, doors
and the like. This means that there is no requirement for a "line of sight" between the transmitter
and the receiver.

RF technologies use frequency modulation to generate radio waves within a certain frequency
spectrum, which encode information and can be intercepted by receivers tuned to the
corresponding frequency. FM radio broadcasts, for example, operate in the 88 megahertz (MHz)
to 108 MHz frequency spectrum; some cordless telephones operate in the 900 MHz frequency
spectrum; Bluetooth wireless communications and other technologies operate in the 2.4

12
gigahertz (or GHz; one gigahertz equals one billion cycles per second) spectrum. Because the
usable radio frequency space is finite, most governments regulate its use, partitioning frequency
ranges and granting licenses to transmit at those frequencies at specified power levels. In the
United States, for example, a federal license is required to transmit in the FM radio frequency
spectrum except at extremely low power levels that limit the range to no more than about 30
meters. Some frequencies are reserved for use without a license under certain conditions. For
example, in the United States unlicensed operation is permitted, with some restrictions, in the
900 MHz and 2.4 GHz frequency ranges (the latter being where Bluetooth wireless
communication operates). In fact, through multinational agreement, the 2.4 GHz spectrum
requires no license for its use anywhere in the world.[1] The SIG together with other organizations
such as the IEEE 802.11 standards body is working with regulatory authorities in some countries
to pursue harmonization of the frequency assignments for unlicensed use within the 2.4 GHz
spectrum and of the approval process for wireless communications. In general the chosen
frequency spectrum can be used globally without license so long as the rules for operating within
this spectrum are followed.
[1]
In some countries there are restrictions and only part of this spectrum is available for unlicensed use; these restrictions are
discussed elsewhere in the book, notably in Chapter 6.

RF Communications in the 2.4 GHz Frequency Spectrum

While the 2.4 GHz spectrum is globally unlicensed, there are regulatory requirements and other
considerations for its use. These include:

• The spectrum is divided into 79 channels (although in some countries, notably Spain and
France, only 23 channels were available for use in the year 2000. Japan began using all 79
channels in 2000).
• Bandwidth is limited to 1 MHz per channel.
• Frequency hopping spread spectrum communications (described below) must be
employed.
• Interference must be anticipated and appropriately handled.

Other RF communications technologies also use this spectrum; notable among them are
HomeRF™ (an open industry specification for RF communications in home environments; see
http://www.homerf.org) and the Institute of Electrical and Electronics Engineers (IEEE) 802.11
specification for wireless local area networks (see http://www.ieee.org). Microwave ovens also
operate within this frequency range. Because this spectrum is unlicensed, new uses for it are to
be expected (for example, a new generation of cordless telephones also uses the 2.4 GHz
frequency) and as the spectrum becomes more widely used, radio interference is more likely.
Thus the requirement to anticipate and address interference in the 2.4 GHz range is important for
all technologies that operate in it.

Each technology using this spectrum has made design choices within the spectrum's constraints
that optimize that technology for particular applications or domains. Bluetooth wireless
communication is designed to take maximum advantage of the available channel bandwidth and
to minimize RF interference and its effects while operating at very low power.

Spread Spectrum RF Communications

Within RF communications, spread spectrum refers to dividing the available spectrum based upon
frequency, time, a coding scheme or some other method. Messages to be sent are then divided
into various parts (packets) that are transmitted across the divided spectrum. Frequency division
spread spectrum (or frequency hopping), which is the method employed with Bluetooth wireless
communication, divides the spectrum into different frequencies, or channels.[2] A single message
packet is transmitted on a selected channel, then the radio selects a new channel (a process
13
called hopping to a new frequency) to transmit the next packet, and the process repeats, thereby
spreading the message across the available frequency spectrum. Each technology specifies its
own method for establishing the frequency hopping pattern. Obviously the receiver(s) of the
message must know the hopping pattern to tune to the correct channels in succession to receive
each packet and assemble the complete message. This process is called frequency hopping
spread spectrum, or FHSS.
[2]
Contrast frequency hopping spread spectrum with direct sequence spread spectrum, which is not examined here. Direct
sequence is another form of spread spectrum RF communication employed in other technologies such as wireless LANs and is
outside the scope of this book.

FHSS introduces additional complexity as compared to using a single statically selected

frequency, yet it also supplies some benefits. First, RF interference can be reduced since all
radios hop (often randomly or at least pseudorandomly, and often rapidly) from one frequency to
another. When all of the participants in the spectrum employ FHSS, interference caused by
colliding transmissions on the same frequency is less likely than it would be if each radio used a
single channel for a long duration. In addition, when collisions do occur, their effects are
lessened, since only a single packet is lost and that packet could be retransmitted at a new
frequency, where again it is less likely to encounter interference. Second, FHSS can provide a
degree of security for communications in that only a receiver that knows the frequency hopping
pattern can receive and assemble all the packets of a message. Because the hopping pattern for
a given spectrum could be constructed in a number of ways, it could be difficult to deduce and
follow an unknown hopping pattern, especially when the spectrum is heavily utilized with many
radios. Thus FHSS can be employed to hinder eavesdropping. In fact, this latter characteristic led
to the invention of FHSS, usually attributed to George Antheil and Hedy Lamarr (the latter is
more famous as an American actress). Their 1942 patent of the frequency hopping concept was
motivated by an attempt to find a "secret communication system" using radio waves to control
torpedoes during World War II.[3]
[3]
The complete story of this invention is fascinating but is outside the scope of this book. Interested readers are referred to, for
example, [IAL99] or other accounts easily found via World Wide Web search engines. Furthermore, any rationale or
implications of the choice of naming the Bluetooth technology after a Danish king rather than an American actress are not
explored here.

As previously noted, the use of spread spectrum is required in the 2.4 GHz range, largely to
minimize interference problems because the spectrum is unlicensed. The design for Bluetooth
wireless communication employs relatively rapid frequency hopping (nominally 1,600 times per
second) and is described more fully below and in Chapter 6.

Infrared Wireless Communication

RF is not the only form of wireless communication. Infrared technology is used with devices such
as notebook computers, personal digital assistants and electronic remote controls. Infrared
wireless communication makes use of the invisible spectrum of light just beyond red in the visible
spectrum.

In particular, one standard method for infrared communication is specified by the Infrared Data
Association (IrDA; see http://www.irda.org); this method is commonly used with mobile phones
and notebook and handheld computers. IrDA technology is relevant when discussing Bluetooth
technology because IrDA is also designed for short-range, low-power unlicensed communications.
IrDA also defines a physical layer and a software protocol stack designed to promote
interoperable communications, as does the Bluetooth specification.

Despite the differences between IrDA and Bluetooth wireless communications, such as data
transmission speeds and signal paths (infrared largely requires line-of-sight paths while RF can
penetrate many objects), the similarities are such that the SIG worked with the IrDA in

14
developing the specification. Because there is overlap in the application spaces of IrDA and
Bluetooth wireless communications, the specification includes an IrDA interoperability layer in
which some protocols defined by IrDA are incorporated. This helps to promote interoperability
among wireless applications no matter which communications transport is being used. IrDA
interoperability in the Bluetooth specification is further detailed in Chapter 9.

The Bluetooth RF Communications Solution

The preceding discussion forms the basis for understanding the Bluetooth design, which:

• in the lower layers centers around wireless RF communications in the 2.4 GHz spectrum;
• is optimized for short-range communication, low power consumption and low cost; and
• in the higher layers reuses transport and application protocols already developed for
similar domains such as those used with infrared wireless communication.

The result is a wireless communication technology that is especially appropriate for cable
replacement and for use with portable devices in pervasive computing applications. Some of the
fundamental principles for Bluetooth RF communication are described here; details of the radio
and baseband operation are given in Chapter 6.

Master and Slave Roles

At the baseband level, when two devices establish a Bluetooth link, one acts in the role of master
and the other in the role of slave. The specification permits any Bluetooth radio to assume either
role, and a device may act as a master for one communication link and as a slave for another
link.[4] The role of master does not imply special privileges or authority; instead it governs the
synchronization of the FHSS communications between the devices. The master device determines
the frequency hopping pattern (based upon its Bluetooth device address) and the phase for the
hopping sequence (based upon its clock). All slaves communicating with a given master hop
together in unison with the master. The master role generally is assumed by the device that
initiates the communication.[5] Part 2 of this book provides more details about establishing
communications links.
[4]
Some devices might be configured to act in only one role, but most Bluetooth devices are expected to include radios that can
assume either role, depending upon the usage case being performed.

[5]
The device initiating communication assumes the master role at the outset, although the master and slave roles can be
switched, as detailed in Chapter 6.

A given master may communicate with multiple slaves—up to 7 active slaves and up to 255
parked slaves[6] (active and parked slaves are described more fully below); all slaves
communicating with a single master form what the specification calls a piconet (also described
more fully below). There can be only one master in a single piconet.
[6]
Actually more than 255 parked slaves are possible. The Bluetooth specification defines "direct" addressing for up to 255
parked slaves via a parked slave address but also permits "indirect" addressing of parked slaves by their specific Bluetooth
device address, thus effectively allowing any number of parked slaves, although from a practical perspective it would be
unusual to have more than 256 devices in a single piconet. This topic is explored more fully in Chapter 6.

The master-slave relationship is necessary in Bluetooth low level communications but in general
devices operate as peers. When one device establishes a point-to-point link with another device,
the role that each device assumes (master or slave) is often unimportant and is irrelevant to
higher-level protocols and to the user of the device. In some usage scenarios it may be
advantageous or even necessary for a given device to assume a particular role, but in many
cases it is not critical to establish a single specific role for each device; some scenarios work

15
equally well with device roles reversed. It is important to understand the master-slave
relationship for low-level communications while at the same time understanding that in general
devices operate as peers to each other. Figure 2.1 shows the master and slave roles in a simple
piconet.

Figure 2.1. Master and slave roles in a simple piconet.

Baseband Modes and Energy-Conserving Features

As noted above, a piconet can include up to seven active slaves and many more parked slaves.
The specification includes a definition for this parked baseband mode, as well as for other modes
called sniff and hold. The various baseband modes facilitate energy conservation by allowing the
radios to enter low-power states. These low-power modes are really just three different methods
for entering and exiting a low-power state, and the mode applies to a given Bluetooth connection
(rather than to the device as a whole). These baseband modes also permit a greater number of
devices to be co-located in the same proximity sphere, since not all devices need to have active
communication links at the same time. All four of these baseband modes (active, sniff, hold and
park) apply when the baseband is in a connection state; when not connected, the baseband is in
a standby state, which should not be confused with any of the connected state modes. That is,
the baseband states are connected and standby; within the connected state there are four modes
(active, sniff, hold and parked). These states and modes are described in more detail in Chapter
6.

In active mode a slave essentially always listens for transmissions from the master. Active slaves
receive packets that enable them to remain synchronized with the master and that inform them
when they can transmit packets back to the master. An active slave must listen for all packets
coming from the master, although one optimization is permitted in which active slaves need not
16
listen for entire packets (rather, just the packet headers) coming from the master when it is
known that some other active slave is communicating with the master during that time. The
active state typically provides the fastest response time but also typically consumes the most
power, since it is always receiving packets and is always prepared to transmit packets.

Sniff mode is one method for reducing power consumption. In sniff mode a slave essentially
becomes active periodically. The master agrees to transmit packets destined for a particular slave
only at certain regular intervals (although it may not transmit packets at every interval). The
slave then needs to listen for packets from the master only at the start of each interval (subject
to some timing tolerances). If the slave receives packets at the start of the interval it continues
to listen and receive packets; otherwise it can "sleep" until the next interval. Sniff mode could
permit reduced power consumption by reducing the average duty cycle of the radio but is likely
to be less responsive than active mode. The power consumption and responsiveness in sniff
mode depend upon the length of the sniff interval.

In hold mode a slave may stop listening for packets entirely for a specified time interval.[7] The
master and slave agree upon a hold time, and the communication link is quiesced for that
amount of time. During the hold time the slave need not listen for packets from the master and
could be doing other things such as establishing links to other devices, or the slave could just
sleep during the hold time. At the end of the hold period the slave resumes listening for packets
from the master. Hold mode may be less responsive than sniff mode and could permit greater
power savings than sniff mode, although this depends upon the hold time duration and upon
what the slave does during the hold time (sleeps versus communicates on other links).
[7]
Or at least certain types of packets. Since packet types have not yet been introduced, this section describes the fundamental
concept of hold mode. A more complete description can be found in Chapter 6.

In parked mode a slave maintains synchronization with the master but is no longer considered
active (slaves in active, sniff and hold modes are considered active). Since there can be only
seven active slaves in a piconet at one time, the use of parked mode allows the master to
orchestrate communications within a piconet of more than seven devices by exchanging active
and parked slaves to maintain up to seven active connections while the remaining slaves in the
piconet are parked. A parked slave still needs to maintain synchronization with the master and
does so by listening to the master periodically, using a beaconing scheme described in Chapter 6.
Parked mode is typically the least responsive of the connected modes, since the slave must make
the transition to become an active member of the piconet before resuming general
communications, but parked mode may permit greater power conservation.

Figure 2.2 shows a typical relationship of the connected state modes in terms of their relative
responsiveness versus power consumption. However, both power consumption and
responsiveness in these modes is highly dependent upon factors such as the amount of
communications traffic and the hold and sniff periods, which can affect the duty cycle of the
radios. As a general rule, active slaves will consume the most power but will be the most
responsive, while parked slaves will typically be the least responsive. The figure illustrates the
general trend, although these relationships may vary in specific cases.

17
 Figure 2.2. Typical relative responsiveness versus power consumption
for connected state baseband modes (generalized; may not apply in all
cases).

In addition to the baseband modes which permit energy conservation, another power-saving
feature is adaptive transmission power. This feature allows slaves to inform the master when the
master's transmission power is not appropriate, so that the master can adjust its transmission
power. This is accomplished through the use of a received signal strength indicator (RSSI). When
the RSSI value is outside some determined boundaries, the slave can ask the master to adjust
the power. This is especially useful when two devices are in close proximity and maximum
transmission power is not required (analogous to two people standing next to each other, with
one person shouting and the second person asking the shouter to speak more quietly). Of course
the converse is also true: transmission power increases also could be requested when the RSSI
value indicates too weak a signal but the primary motivation for adaptive transmission power is
to reduce power consumption when a lower transmission power is sufficient. The master
maintains transmission power settings for each slave so that a change in transmission power for
one slave does not affect other slaves in the piconet. Like other energy-conservation features,
adaptive transmission power could also allow a greater number of devices to be co-located in the
same proximity sphere, since it could further reduce the possibility of RF interference with other
devices.

Communications Topology
The Bluetooth network model is one of peer-to-peer communications based upon proximity
networking. When two devices come within range of each other,[8] they could automatically
establish a communications link. Devices will not necessarily begin to communicate
spontaneously when they encounter each other, as the baseband could be configured to accept
only certain connections, or even none at all. The process of initiating communications links is
explored in detail in Chapters 6 and 7.
[8]
Nominal range for the standard 0 dBm Bluetooth radio is approximately 10 meters; power-amplified 20 dBm radios with a
range of about 100 meters are also possible. The Bluetooth version 1.0 specification focuses primarily on the standard radio
and thus deals mostly with communication within a 10-meter range.

Proximity networking without wires enables the formation of personal area networks, or
federations of personal devices such as mobile telephones, pagers, notebook computers and
personal digital assistants. When these devices can communicate seamlessly, their overall utility
is enhanced. Another application for proximity networking is the interaction of mobile devices
with fixed devices such as kiosks, printers, network access points and vending machines—a
person could establish communication between his personal device and a fixed device just by
approaching it. This topology enables other usage models, too; these are explored more fully in
Chapter 3.

18
Piconet topology, introduced earlier, can now be further explored given the foregoing discussion
of master and slave roles and baseband modes. A piconet consists of a single master and all
slaves in proximity that are connected to (in communication with) that master. The slaves may
be in active, sniff, hold or park modes at any given time. All of the devices in the piconet are
synchronized, all hopping together. There may be other devices in proximity that are not
connected to (not in communication with) the master and thus are not part of the piconet,
including devices in standby state. Figure 2.3 shows this more general view of a piconet; note
that there could be up to seven active slaves and any number of parked slaves and standby
devices (although most typical piconets, especially those that are formed to support the version
1.0 profiles, are expected to have only a few devices).

Figure 2.3. General Bluetooth piconet including active and parked slaves.
Standby devices which are in proximity but are not part of the piconet
are also illustrated.

As described and illustrated above, a device may be an active or parked participant in a piconet
or it may not be part of any piconet. In addition, it is possible for a device to take part in more
than one piconet. When two or more piconets at least partially overlap in time and space a
scatternet is formed. All of the same principles of piconets also apply for scatternets; each
piconet has a single master and a set of slaves which may be active or parked. Each piconet has
its own hopping pattern determined by its master. A slave could participate in multiple piconets
by in turn establishing connections with and synchronizing to different masters in proximity. In
fact, a single device might act as a slave in one piconet but assume the master role in another
piconet. The scatternet topology provides a flexible method by which devices could maintain
multiple connections. This could be especially useful for mobile devices which frequently move
into and out of proximity to other devices. Figure 2.4 shows one example of a scatternet using
the same representations as in Figure 2.3; other examples of scatternets are possible. In this
example slave A2/B3 is a member of both piconet A and piconet B as an active slave.

19
Figure 2.4. Scatternet example. Slave A2/B3 participates as an active
slave in both piconet A and piconet B.

20
Chapter 3. Bluetooth Usage Models
While much of the focus of Bluetooth wireless communication is on the specification of the
technology-which is explored in depth in Part 2 of this book-the specification is actually rooted in
a set of usage models (sometimes also called usage scenarios or usage cases). Long before there
was a specification, the official Bluetooth web site included descriptions of several of these usage
models that the technology makes possible. The specification itself was preceded by a marketing
requirements document(internal to the SIG); included in those marketing requirements were
usage scenarios that were an integral part of the objectives that the initial specification was to
address. These scenarios were not intended to cover all possible functions achievable with the
technology but rather to set the initial focus for the version 1.0 specification.

Bluetooth usage models are formally specified in profiles, which are examined in Part 3. This
chapter focuses on describing the usage models in a general fashion, emphasizing an end user's
view of the scenarios and the benefits that Bluetooth wireless communication offers in those
scenarios. Not all of the usage cases described in this chapter have a corresponding profile,
although all of the scenarios have at one time or another been discussed, presented or published
by the SIG, and they are representative of those usage cases that drove the development of the
specification. If a usage model described here has no corresponding profile, it simply means that
the SIG has not formally specified that scenario with version 1.0 of the specification. In many
instances such usage scenarios could be realized with Bluetooth technology as defined in the
current specification, but the SIG has not (yet) formalized an interoperable definition for doing
so.

The usage models described here are just an initial set of scenarios that could be accomplished
with Bluetooth wireless communication.[1] New applications of the technology will undoubtedly
continue to be invented, and it is expected that new scenarios and new profiles will emerge from
the SIG over time (Part 4 discusses some future possibilities).
[1]
Some scenarios could also be accomplished with other technologies, and the usage models are not necessarily unique to
Bluetooth wireless communication.

The Cordless Computer

At its heart, Bluetooth wireless communication is all about replacing cables. One place where
many cables exist, and where these cables are sometimes unwieldy, is the typical desktop
computer. The cordless computer usage model is not specifically addressed in version 1.0 of the
specification, but it is expected that this scenario could be realized in a straightforward manner in
the future. As depicted in Figure 3.1, many of the cables associated with computer peripherals
could be replaced by wireless links. Keyboards, mice, joysticks, speakers, printers, scanners and
the like might all employ Bluetooth wireless communications. While not shown in the figure, other
computer-related wires such as personal digital assistant cradles, digital camera cables and
network connection cables could also be replaced by wireless connections (these three examples
are discussed below in "The Automatic Synchronizer," The Instant Postcard and The Internet
Bridge usage models, respectively).

21
 Figure 3.1. The Bluetooth cordless computer usage model.

In addition to the directly evident benefits of not having to deal with cables during installation
and operation of the computer, wireless devices offer more freedom in placement and use.
Speakers, printers and scanners, for example, could be placed in the most appropriate location
for the environment, unrestricted by connectors and cable length. User interface devices such as
keyboards, mice and joysticks could be used wherever it is convenient to do so and could move
with the user rather than being fixed in a certain location where they would be constrained by a
cable.

Device sharing is much easier in this configuration than in a cabled environment. A joystick, for
example, need not be used exclusively with the computer but might also be used with a video
game. Even more important for many people, though, is the capability to share peripherals such
as printers or scanners. Today sharing these devices often requires a networked environment
where the computer that hosts the peripheral acts as a server; if other devices need to use the
peripheral they do so via the hosting computer which is cabled to the peripheral. With the
cordless computer, other devices using Bluetooth wireless communication could directly access
peripherals in peer-to-peer fashion.

The Ultimate Headset

Support for voice in Bluetooth wireless communication fosters this usage model. Telephone
headsets are increasingly common for use with both fixed and mobile telephones. In
environments such as call centers (help desks, centralized reservations offices, and so on)
headsets might be used with standard telephones to keep a person's hands free to use a
computer. Headsets are also available for use with many mobile telephones, also for hands-free

22
operation for situations such as driving or walking while carrying items. Bluetooth wireless
communication removes the cable between the headset and the telephone. A call could be placed
using the telephone keypad, with the audio portion of the call being carried through the headset's
microphone and speaker. Figure 3.2 illustrates various instances of the ultimate headset usage
model, including the use of the headset with nontelephony devices, described more fully below.

Figure 3.2. The Bluetooth ultimate headset usage model.

One advantage of the ultimate headset is that it supports mobility. The user of the headset is not
physically tied to the audio device and thus is free to roam about the area while keeping the
connection intact. Another advantage is the ability to use the same headset with multiple devices.
Because the specification offers a standard interface, the same headset used with a telephone
might also be used with a fixed voice access point, such as a cordless telephone base station, and
could also be used for audio interaction with computers. In the future it also may be possible to
use such a headset with stereos, portable CD players and recording devices. As with the cordless
computer, the ultimate headset allows devices to be placed wherever it may be convenient,
which for mobile devices might be in a pocket or briefcase. With appropriate speech technologies
it indeed may be possible, through the use of voice recognition, to place telephone calls using
only the headset as the user interface.

The Three-in-One Phone

Today many people use multiple telephones: a phone in the office, one or more telephones at
home (some wired, some cordless), a mobile (cellular) telephone, public telephones, and so on. A
single phone using Bluetooth wireless communication could be used in place of many of these
other telephones. The three-in-one phone usage model allows a mobile telephone to be used as a
cellular phone in the standard manner, as a cordless phone connecting to a voice access point
(cordless phone base station), and as an intercom or "walkie-talkie" for direct phone-to-phone
communications with another device in proximity. Figure 3.3 shows all three uses of the three-in-
one phone.

23
 Figure 3.3. The Bluetooth three-in-one phone usage model.

A key benefit of the three-in-one phone is that a single telephone could become the only one that
a person needs. If multiple voice access points using Bluetooth wireless communication become
available in environments such as the home, office and public areas, a single personal telephone
that is usable almost anywhere becomes realistic. The need for separate telephones and separate
telephone numbers in the office, at home and while traveling could be reduced. Another benefit
that derives from the use of such voice access points is the possibility for reduced cellular airtime
charges. When the handset is used as a cordless phone, communicating with a standard
"landline" telephone service via an access point, no cellular airtime charges need be incurred.

The direct telephone-to-telephone, or "walkie-talkie" function of the three-in-one phone usage

model is most useful with the 20 dBm power amplified radio, with its range of 100 meters. When
two parties are within range of each other using standard Bluetooth radios (10 meters), it is likely
that they could shout at each other rather than use telephone radio communication (aside from
situations where a physical obstacle might separate the parties). Because a direct phone-to-
phone communication scenario across only a 10-meter range might have limited utility, the SIG
indeed debated whether or not this walkie-talkie function should be included in the usage model,
since the focus of the version 1.0 specification is on a standard 0 dBm Bluetooth radio (there was
some discussion of removing this use of the telephone and calling this usage model the two-in-
one phone). However, even with the standard radio with its 10-meter range there are situations
where the direct phone-to-phone communication might be useful. These might include cases such
as people communicating across different floors of a building, from within confined spaces or
when nonintrusive communication is desired even when both parties might be able to see each
other (for example, video and sound control workers in a crowded auditorium).

24
The Interactive Conference (File Transfer)
One of the most fundamental and useful applications for any type of data networking, including
simple point-to-point links (like those of Bluetooth wireless communication), is to exchange files
and other data objects. File transfer using floppy disks or cables is common; wireless
communication removes the need for cables, making it much easier to form temporary links
between devices to quickly exchange files and other data objects. For example, as infrared data
ports become more widely used with notebook computers, mobile telephones and personal digital
assistants, it is not uncommon for users to establish a temporary infrared link to exchange
electronic business cards and other data. This same sort of file and object transfer is possible
with Bluetooth wireless communication. In an interactive conference room scenario, business
cards and files could be exchanged among the participants of the meeting. Figure 3.4 illustrates
the Bluetooth file transfer usage case; as shown, not only could files be transferred between two
computers but objects also could be transferred between any two devices using Bluetooth
wireless communications.Chapter 14 discusses the details of the various modes and types of file
and object transfer.

Figure 3.4. The Bluetooth interactive conference (file and object

transfer) usage case.

A primary benefit of wireless file transfer is the convenience that it offers. Data could be
exchanged easily between two or more devices without the use of cables (which, as pointed out
in the introduction, are likely to be cumbersome, proprietary and incompatible between two given
devices) and without the need to set up and configure a full-blown network among the devices.
Files and other objects could be exchanged immediately in a conference room setting, rather than
deferring the transmission of the files until after a meeting is over when a computer or other
device can be connected to a network.

25
 The Internet Bridge
There are two similar yet different methods for using Bluetooth communication as a wireless
"bridge"[2] to established networks like the Internet or campus or corporate intranets. The first
method is dial-up networking using a telephone as a wireless data modem; the second is direct
local area network (LAN) access using a data access point.
[2]
The term bridge is used here since it is consistent with the nomenclature used by the SIG. The function described here is
similar to a traditional network bridge, which is distinct from a router. While no Bluetooth "Internet router" usage case exists in
version 1.0, such a function is not beyond the realm of possibility.

Dial-Up Networking
This form of the Internet bridge is no different from the method many people use to access the
Internet today. A conventional arrangement involves connecting a computer to the Internet using
a telephone to dial an Internet service provider through a modem. What Bluetooth
communication adds to this scenario is the ability to accomplish this usage model entirely without
wires. Today's usage models for dial-up networking typically require a cable between the
computer and the telephone; even when a mobile telephone is used, a cable between the
computer and the mobile telephone is usually required. With a computer and a telephone that
both support the dial-up networking profile, the end-to-end connection to the Internet (or other
network) could be wireless, as illustrated in Figure 3.5.

Figure 3.5. The internet bridge usage case 1: wireless dial-up

networking.

Direct Network Access

While dial-up networking is a popular way to access the Internet, especially from homes or other
environments where telephone lines (or in some cases, cable or high-speed data connections) are
the primary communications bridge, direct access to LANs is common in enterprises, on
campuses, and in other similar environments. The directly accessed local area network often

26
provides a gateway to the Internet, enabling the Internet to be accessed from the LAN without a
dial-up connection.

Direct network access via Bluetooth wireless communication is possible using data access points.
A data access point allows devices to connect to it wirelessly; the data access point in turn
connects to the local area network. Once again this is not functionally different from the same
sort of connection in a wired environment, such as a traditional Ethernet network where
computers connect to network access points using cables. A data access point with Bluetooth
wireless communication simply provides a "wireless plug" to connect to the network as illustrated
in Figure 3.6.

Figure 3.6. The Bluetooth internet bridge usage case 2: direct local area
network access through a data access point.

The Internet bridge is one case where Bluetooth wireless communication can be used to replace
cables, making a common task easier and more convenient. Dial-up networking, for example, is
common today with wired modems and telephones. Many business travelers have experienced
searching a hotel room for the telephone jack so as to plug in their notebook computer's modem
for dial-up networking. With Bluetooth wireless communication, no cable connection is required;
a hotel room telephone or a person's own mobile phone could be used as a wireless data modem.
The use of a mobile telephone as a wireless data modem is not uncommon today, but in most
cases the mobile phone still needs to be cabled to the notebook computer; Bluetooth wireless
communications could further improve upon this scenario by removing the cable between the
computer and the phone.

Direct network access using Bluetooth wireless communication offers advantages over the
equivalent wired scenario. In addition to obviating the need to provide an in-building wired
infrastructure with endpoint connections at every access point, a wireless data access point also
offers the possibility for devices to share the access point. Multiple devices in proximity of a
single data access point could access the network wirelessly rather than requiring each device to
have a separate cabled connection to its own access point. Moreover, data access points could be
designed such that they could plug into existing network wiring infrastructure and thus allow "the
last hop" to be wireless, with its associated conveniences, while making use of and protecting the
investment in the existing wired network.

27
The Speaking Laptop
The speaking laptop is one of the usage models that is not advertised in version 1.0 of the
specification, perhaps because it could be considered a straightforward extension of the headset
profile already described.[3] The concept behind it is that a laptop (or notebook) computer's
microphone and speaker could be used as the audio input and output for a voice call placed on a
mobile telephone. As an example, suppose someone places a call on a mobile phone during a
meeting. As the conversation progresses, it becomes evident that others in the meeting would
benefit from taking part in the call. Bluetooth wireless communication could be used to route the
voice traffic to a notebook computer in the conference room, allowing the computer to be used as
a speakerphone. The call is still being carried over the mobile phone's wide area voice network
but the audio source and sink are now at the notebook computer. Figure 3.7 illustrates the
speaking laptop scenario.
[3]
The technical underpinnings of routing voice traffic between a telephone and another device are similar, although the
speaking laptop has some distinct end-user considerations that merit its independent discussion here.

Figure 3.7. The Bluetooth speaking laptop usage model.

The speaking laptop usage model is an example of extending the functions of one device by
allowing it to "borrow" the capabilities of some other device. Speakerphone capability becomes
available, using the speaker and microphone of the notebook computer, even if the mobile phone
does not have its own speakerphone capability. Extensions to the speaking laptop scenario might
enable other similar usage models where existing audio input and output could be used to
supplement that of a mobile telephone. For example, the audio portion of a call could also be
routed to a car's audio system in a vehicle with Bluetooth wireless communications.

The Automatic Synchronizer

The automatic synchronizer is an example of using proximity networking to add value by making
an existing task easier to do. Personal portable devices empower people to have quick and easy
access to information they can use in their daily lives. For that information to be most useful it
needs to be kept up to date, but this personal information management data might be distributed
across the many devices that a person could use. For example, new calendar entries or to-do list
items might be entered on any of a notebook computer, personal digital assistant or smart
phone; or these entries might be entered on a desktop computer and stored on a server in a

28
network. Synchronization is the process of merging the data from two different sources based
upon some set of rules such that the resulting data sets are identical (or at least reflect identical
information). A common example is synchronizing a personal digital assistant with a desktop or
notebook computer. Today this often is performed using special serial cables and software that
may be unique to the device. Standard protocols and object formats in the specification allow
data on one device to be synchronized with data on any other device, whether they be PDAs,
notebook computers, smart phones or even networked data accessed through a data access
point.

The "automatic" part of this usage model is enabled by proximity networking. Today
synchronization is almost always a conscious effort-it involves connecting a serial cable and
pushing a button, or pointing two infrared-capable devices at each other and launching an
application. With Bluetooth wireless communications it is possible for two devices to automatically
synchronize whenever they come within range of each other. For example, a personal digital
assistant carried in a person's pocket could automatically synchronize with that person's desktop
computer whenever she walked into her office. Clearly it should be possible to configure the
devices as to when and how to automatically synchronize, and to ensure that devices synchronize
only with other known devices and data sources and not with just any random device; the
specification does offer mechanisms that could be used to do this. Figure 3.8 shows examples of
the automatic synchronizer. The figure illustrates how different devices in a personal area
network (such as the mobile telephone and PDA shown) might automatically synchronize. The
figure also shows how one of those devices (here, the PDA in the briefcase) might also
synchronize with a desktop computer when those devices come within range of each other (in
this case, when the PDA's owner walks into her office).

Figure 3.8. The Bluetooth automatic synchronizer usage model.

In addition to the convenience afforded by automatic synchronization, Bluetooth wireless

communication removes the requirement for cables. By specifying a standard protocol and object
formats for synchronization (these are adopted from IrDA, as detailed in Chapters 9 and 14),
Bluetooth wireless communication makes it easier for any device to synchronize with any other
device. This multidevice synchronization enables a person to use any convenient device to enter
new appointments, to-do list items or other data.

The Instant Postcard

The instant postcard is another usage model that was discussed early in the development of the
specification but is not formally part of the version 1.0 profiles. This is one of the few scenarios
that involves a device other than a mobile phone or computing platform, although it is expected

29
that over time many new usage models and profiles will be developed for additional device
classes. The underlying concept is that of having a digital camera which can wirelessly transfer a
photo image to some other device which could then e-mail the image to a recipient, thus creating
a digital "postcard." Today many digital cameras use a serial cable to transfer photo images to a
computer where they can be stored, catalogued, manipulated and distributed. As with the other
version 1.0 usage models, Bluetooth wireless communication removes the need for a cable which
in turn presents new ways to use a device, as pointed out below. Figure 3.9 shows how the
instant postcard might be realized.

Figure 3.9. The instant postcard.

This scenario is useful not only for sending "postcard" type pictures to friends and relatives but
also for commercial applications, such as real estate (transferring photos of newly listed homes to
a central database), law enforcement (transferring photos of suspects or stolen vehicles, for
example) and insurance (transferring photos of automobile damage resulting from accidents). In
addition to replacing cables, Bluetooth technology also could change the way a digital camera is
used, since photos need not necessarily be transferred to a computer. Many photos might be
transferred directly from the camera to a mobile phone and then sent as an e-mail attachment
without using a computer as an intermediary. In addition, the transfer of photos from the camera
to a database or library could be accomplished in more of a real-time fashion, since no cabling is
required.

Ad Hoc Networking
This usage model could be considered to be an extension of the interactive conference (file
transfer) scenario. It is not specifically addressed in the version 1.0 specification but it does
provide an illustration of usage cases that could be enabled in the future. Ad hoc networks are
networks that form spontaneously; Bluetooth wireless communication is an enabling technology
for these sorts of applications. The interactive conference usage model showed how objects such
as electronic business cards or files could be exchanged in a conference room setting. When ad
hoc networks can be formed among the meeting participants, additional applications become
possible. Among these are collaborative applications such as real-time viewing and group editing
of presentations and instant messaging among the meeting participants.

30
Ad hoc networks consisting of diverse types of devices present many new and exciting
possibilities for usage scenarios. While more work is required to establish interoperable methods
for general networking,[4] Bluetooth wireless communication is positioned to be an enabling
technology for ad hoc networking scenarios.
[4]
For example, issues with routing, name serving, address assignment and other topics all need to be addressed for effective
ad hoc networking. Such issues are also relevant in forming Bluetooth scatternets, discussed inChapter 6.

Hidden Computing
Hidden computing (sometimes called unconscious computing) is one of the most exciting future
applications for Bluetooth technology. While not directly addressed in the version 1.0
specification, hidden computing has been discussed at SIG events in the past and is an area ripe
for future exploration. The fundamental elements required for some forms of hidden computing
already exist in the current specification, although the SIG has not developed profiles that
describe how the various hidden computing applications might be accomplished in a standard and
interoperable manner.

Hidden computing involves a class of applications in which devices that are not overtly being used
by a person can still perform tasks on that person's behalf. We have already seen one example
that could be considered a hidden computing application: the automatic synchronizer. In that
usage model, a PDA "hidden" in a pocket or purse could synchronize with another device without
user intervention. Several other examples have been described in the context of Bluetooth
wireless communication. Among these are:

• A notebook computer "hidden" in a briefcase in a "sleeping" mode could be configured to

awake periodically, receive new e-mail and send information such as new e-mail alerts
(and possibly a short clip of the e-mail content) to a mobile phone. The user might then
decide to browse e-mail using the mobile phone or process e-mail on the notebook
computer.
• A mobile telephone "hidden" in a pocket or purse could be used by an appropriately
configured notebook computer "hidden" in a briefcase to access a network in the manner
described for the Internet bridge (dial-up networking) scenario. Once the computer is
connected to a network in this fashion, network synchronization or transmission and
reception of e-mail could be initiated, all without conscious user interaction with either
device.

In early stages of the development of the specification, such applications were called "the
briefcase trick." With proximity networking enabled by Bluetooth wireless communication, hidden
computing applications abound. Other future possibilities might include the use of a hidden device
that controls environmental settings (such as home climate and lighting, music, automobile
driver's seat and mirror adjustments and so on) based upon the personal preferences of the user,
automatic customer discounts applied at points of sale based upon a device tucked away in a
pocket or suitcase, and automated identification and authentication when a person checks in with
an airline or a hotel.

These sorts of scenarios are almost limitless. While hidden computing applications may not be
fully realized for some time, the Bluetooth technology does offer a basis upon which industry
innovators could build them.

31
Chapter 4. Introduction to the Bluetooth
Specification
Any good technical specification should answer several questions of "what?" for its readers. Some
topics that a specification ought to address are:

• what is the product or technology?

• what is it designed to do?
• what is it composed of?
• what standards and metrics must an implementer meet?

Questions of "how?" typically are not addressed in a specification but rather are left to the
judgment and ingenuity of the implementers. A specification usually does not address exactly
how an instance of the technology or product is constructed using hardware or software modules
or describe the precise methods used to ensure that standards and requirements are met.

The Bluetooth specification is no different from others in this respect. Even in its great magnitude
(over 1,500 total pages in version 1.0B) the specification still focuses primarily on what an
implementer needs to know to create products that use Bluetooth technology. One reason for the
enormity of the specification is the breadth of the topics that it covers. The specification is not
one that addresses only a radio or just a single layer of a software stack or a solitary interface;
rather it addresses a combination of hardware and software that includes all of these facets and
more, with broad applications and a diverse audience. The SIG deemed this approach necessary,
given the many new concepts introduced with Bluetooth technology. However, the SIG adopted
existing protocols where feasible; large portions of the specification deal with adapting these
protocols to Bluetooth environments.

The SIG involved dozens, if not hundreds of people who spent over a year developing the first
version of the specification. Rather than publish a first edition that was informational only, the
SIG chose to ensure that the version 1.0 specification was sufficiently correct and complete to
enable implementations to begin. While the initial publication was unsurprisingly
imperfect(numerous errata have been published) and arguably can never be truly complete(since
new applications of the technology will continue to evolve), this approach to producing a
comprehensive first version of the specification was appreciated by many Bluetooth adopter
companies.

This chapter explains the purpose, scope and structure of the specification and the relationships
among its constituent parts. Because the specification is so broad and voluminous it seems
unlikely that all readers will read it from cover to cover with equal interest in all of its diverse
parts. Since the main body (Parts 2 and 3) of this book deals with the specification, its structure
logically mirrors the specification's structure to a great extent. By explaining how the specification
is organized, this chapter is designed to direct readers toward the chapters of this book, and
hence toward the chapters of the specification, that are likely to be of most interest and
relevance based upon the tasks they wish to accomplish or the knowledge they hope to gain.

Purpose of the Specification

Like most technical specifications, the Bluetooth specification is a response to marketing
requirements. As previously noted, the SIG's Marketing working group originally generated a
marketing requirements document (MRD), which is internal to the SIG and includes objectives
and usage models which were the genesis of the specification. A core purpose of the specification

32
is to define components that can be used to develop solutions that address these marketing
requirements.

Among the objectives set forth in the MRD were those that now are key attributes of Bluetooth
wireless communications: an open specification, unlicensed global use, low cost and interoperable
solutions regardless of device manufacturer. In fact, each of the fundamental characteristics of
the technology in the list in Chapter 1 has some basis in the marketing requirements document.
In many cases, portions of the specification can be traced back to an MRD objective. For
example, the objective of an open specification is realized with its public availability and royalty-
free license; unlicensed global communications are achieved through the use of the 2.4 GHz
spectrum; many of the radio's parameters (described in more detail in Chapter 6) are a result of
design tradeoffs to specify a robust radio while meeting the objective of low cost; and the
objective of interoperability is directly addressed in the more than 400 pages of profiles (volume
2 of the specification).

Many of the usage models and technical characteristics reviewed in Chapter 3 also were recorded
first as marketing requirements. Most of these scenarios are described in the MRD and many of
these survive largely unchanged today, although they have been refined and expanded. Initial
outlines for the interactive conference (file transfer), synchronization, Internet bridge, three-in-
one phone, ultimate headset and others all are included within the original MRD, although some
of these scenarios originally were known by different names.

Scope
The SIG intentionally began the specification development by focusing first on cable replacement
usage models and a basic protocol framework to support them. This philosophy resulted in the
specification version 1.0, which defines a protocol stack that enables many important profiles, but
the SIG has not stopped there. There is interest in many new applications and profiles; these will
continue to be developed by the SIG and are likely to be published in future editions of the
specification. Part4 explores these possibilities further. By starting with the simplest and most
fundamental usage models, the SIG was able to bound the version 1.0 specification scope.

The specification does not simply describe some existing implementation. Great care was taken
during its development to ensure that anyone who has or can obtain sufficient skills and
resources should be able to implement the specification. Recall that the specification was
developed by a multicompany special interest group with a shared and stated objective to
produce a truly open specification. The elements of the specification were developed to meet the
objectives for the technology in a practical manner, not to match preconceived ideas nor a single
company's viewpoint, experience or implementations. In fact, for most portions of the
specification quite the opposite was true: the process was to draw upon the collective wisdom
and experience of the company representatives to produce an initial version of some part of the
specification. Hypotheses in the draft specification could then be tested at one or more companies
via prototyping or some other means, with the results then fed back into the refinement process.

The many independent implementations of Bluetooth hardware and software by multitudes of

vendors, many of whom were not part of the SIG's promoter group, seem to indicate that the
SIG has performed well in producing a sufficiently complete specification. It is encouraging that
many products with Bluetooth wireless communication are being produced on the basis of the
version 1.0 specification.

In any work this large, of course, some errors and opportunities for misinterpretation are likely to
arise. The Bluetooth specification is no exception. Following publication of the version 1.0 (or
more properly, 1.0A) specification, numerous comments from adopters and others were received.
Many of these comments dealt with portions of the specification that were unclear or for which

33
multiple interpretations could reasonably be construed. In addition, minor errors that had slipped
through even the diligent review of the SIG members were discovered. For each of these items-
and there were dozens if not hundreds-the responsible working group within the SIG considered
the comment and, if accepted, prepared an erratum document and corrected the error or clarified
the wording in a corresponding change to the specification. The result was the publication in
December 1999 of the specification version 1.0B, which is what most people mean when they
refer to version 1.0 of the specification (and indeed this is what is meant by such references
throughout this book). Of course even as new versions of the specification are generated,
document maintenance must continue, and the SIG still deals with errata to the initial
specification while developing new material for new versions.

The Specification's Structure

At the highest level the specification is split into two volumes: volume 1 is the core specification,
which deals primarily with the protocol stack but also includes descriptions of related items such
as testing and compliance; volume 2 is the profile specification. In this book these two volumes
are examined in Parts 2 and 3, respectively.

For version 1.0, the core specification is by far the larger of the two volumes, weighing in at
nearly 1,100 total pages. Volume 2, the profiles, is about 440 pages in version 1.0. The set of
profiles is expected to grow more rapidly though, as new usage cases are formalized. A major
portion of the SIG's work following release of the version 1.0 specification is focused on creating
new profiles. So as Bluetooth wireless technology becomes more widely used in new industries
with new applications, the continued creation of additional profiles is expected.

Volume One Structure

Within volume 1 the protocols are presented largely in a bottom-to-top organization. The
specification begins with a short discussion of the radio followed by the baseband, link manager
and L2CAP layers. Next are the higher layers: RFCOMM, SDP, TCS and IrDA interoperability
protocols. The Host Controller Interface (HCI) is an interface to the baseband controller and link
manager, but in the specification the HCI is discussed after all of the higher-level protocol
sections (the HCI is a command interface rather than a protocol per se and its use may differ
depending upon an implementation's design; thus it is discussed separately in the specification).
Additional chapters that do not deal specifically with protocols include WAP interoperability, test
mode, test control and compliance discussions. Finally the miscellaneous material is included in
the appendices, although much of this material is important for many implementers and should
not be overlooked. Among the topics covered in the appendices of volume 1 of the specification
are audio (also discussed Chapter 10 of this book) and Bluetooth assigned numbers.

Appendix VIII of volume 1 of the specification, Bluetooth Assigned Numbers, is a central area in
which values defined by the SIG are recorded. This important part of the specification is not
detailed elsewhere in this book, so we briefly discuss it here. The Bluetooth Assigned Numbers
section of the specification defines values that are expected to change or evolve over time and
must be relied upon and therefore registered. Included are the particular values assigned to key
fields or structures that must be well known in several protocols. Examples include inquiry access
codes and bit definitions for fields that describe device and service classes, used when
establishing connections; channel and protocol values used in L2CAP; and several specific values
defined for use with SDP. In this latter case these values represent particular services and
attributes associated with those services that are required to accomplish the usage models (as
described in the profiles) for version 1.0. This list is expected to grow over time as new usage
models are adopted. Because it is difficult to predict what new services will be available, it is
difficult to pre-assign values for all services; thus the values are isolated in the assigned numbers

34
registry so that the protocol specification itself need not be modified when instances of new
services are developed.

Volume Two Structure

The organization of the profiles in volume 2 of the specification is quite straightforward. Each
chapter is a single profile. For the most part, related profiles are grouped together, although the
serial port profile seems to be oddly inserted in the middle of the telephony-based profiles. As in
volume 1, the profile specification begins straightaway without any introductory or background
material to set the stage. In Part 3 of this book we provide some context for the profile
specification.

Part 3 of this book mostly follows the structure of volume 2 of the specification, grouping
together the GAP and SDAP profiles, telephony-related profiles, serial port-related profiles and
networking-related profiles. Although these profiles are not formally grouped this way in the
specification, this approach is intended to aid understanding and is discussed further in Chapter
11.

Relationships
While initially it may not be evident that there is some coupling between the two volumes of the
specification, there is in fact a correspondence between many layers of the protocol stack and
one or more profiles. Because the profiles are intended to inform the reader about how to apply
the protocols defined in volume 1 to realize an interoperable implementation of a particular usage
case, these profiles tend to map to protocol layers in some fashion, although it is not always a
one-to-one mapping. Each profile describes the associated protocol stack that it requires, as well
as how to use and configure the appropriate protocol layers. Many profiles are somewhat attuned
to certain protocols. For example, the generic access profile primarily defines how to use the
baseband, link manager and L2CAP layers of the protocol stack. The service discovery application
profile is tightly coupled with the SDP layer of the stack; the telephony-based profiles (intercom,
headset[1] and cordless telephony) principally relate to the TCS protocol and audio traffic. The
serial port-based profiles[2] (including object and file transfer and the serial port profile itself) and
networking-based profiles (LAN access, fax and dial-up networking) have some affinity with the
RFCOMM layer of the stack, with the serial port-based profiles also being tightly coupled to the
IrDA interoperability protocols.
[1]
The headset profile does not directly use TCS; see the discussion in Chapter 13.

[2]
We group the serial port profiles as listed here; Chapter 11 further describes profile family grouping.

So while there is not a direct mapping of the chapters of volume 1 of the specification to those of
volume 2, the subject matter of corresponding parts of these two volumes does include related
material. Therefore it is usually insufficient to read or write about just one portion of the
specification in isolation. This is why this book covers both volumes of the specification in its main
body; this is also why this book strives to explain the motivation for and relationships among the
various parts of the specification. The following section suggests some methods that might aid in
understanding those portions of the specification that are of most interest; if using this book as a
guide to the specification, these same methods may be used to determine the focus areas herein,
since the structure of Parts 2 and 3 of the book largely mirrors that of version 1.0 of the
specification.

35
Guide to Understanding the Specification
The specification version 1.0 does not include any introductory information about its purpose,
scope, structure or component relationships (aside from a table of contents). Its readers will find
a title page, some notices and a master table of contents abruptly followed by the radio
specification and remaining chapters. Readers will find no preface, no foreword and no organized
background information. This is not necessarily a bad thing;[3] it primarily results from the
specification's technical nature and direct approach to its subject matter. This chapter is intended
to supply some of the information that is not found (or at least not explicitly called out) in the
specification, thus making the specification more accessible and better preparing its readers to
get the most from it.
[3]
After all, it helps to create a market for books such as this one.

While the most straightforward way to read the specification is to start with page 1 of volume 1
and continue reading all the way to the last page of volume 2, and while it is not our intent to
discourage this method of reading, this may be impractical in many cases. We expect that many
readers would have difficulty absorbing the tremendous detail contained in the more than 1,500
pages of the complete version 1.0 specification. Furthermore, many people probably do not need
to learn all of the details of every protocol and profile, and even those who do may find it helpful
to digest these details in logical groupings, one at a time. The specification is quite broad,
covering everything from low-level radio details to application software considerations. The
projected Bluetooth marketplace is expected to be just as broad, offering opportunities for many
specialized products and skills as well as for general-purpose ones. Thus, depending upon
interest, it may be beneficial to develop an individualized plan for delving into the specification
(and into the main body of this book). The suggestions offered here are intended to aid in doing
just that.

As partial remedy to the lack of introductory material in the specification, the SIG has published
several white papers in addition to the specification. One of those white papers, Bluetooth
Protocol Architecture [Mettälä99], is a useful overview of the contents of the specification and we
recommend it as supplemental reading. This paper covers some of the same topics as Chapters 5
and 11 of this book and may serve as a good companion to that material.

Once introductory material (such as Part 1 and Chapters 5 and 11 of this book along with the
cited white paper) is understood, many readers may wish to branch out to particular sections of
the specification depending upon their interests and objectives. It is unrealistic to devise a
reading plan to fit every audience's need, but this section suggests some general guidelines. It is
hoped that most readers will be able to use one or more of these general classifications to
achieve an understanding of Bluetooth wireless technology that is appropriate for their own
situation.

For General Knowledge

Many readers, perhaps including students, teachers, consultants and others who have general
interest in the Bluetooth technology and who wish to understand that technology in the context
of their profession, may wish to read this book and the specification to gain general knowledge.
Such readers may not need to read the specification from cover to cover since they do not need
to learn every detail of the specification that might be required by someone implementing the
specification.

Our suggested reading plan for general knowledge is to study the profiles after a general
overview of the protocol stack as outlined below.

36
 1. Read Part 1 and Chapter 5 of this book and the SIG protocol architecture white paper
(cited above). This material helps to put the protocol stack in context.
2. Review or skim volume 1 of the specification using Chapters 6 through 10 of this book as
an explanatory guide to the corresponding specification sections.
3. After reading Chapter 11 as an introduction to the profiles, study each profile in volume 2
of the specification, using Chapters 12 through 15 as an aid in understanding the r elated
profiles.

From a Device Perspective

A great deal of the interest in the Bluetooth technology comes from those who are concerned
primarily with implementing that technology in devices. Device manufacturers, software
developers and original equipment manufacturers who build device components need to
understand the details of the protocol stack. Readers who plan to implement Bluetooth wireless
communication in devices, in whole or in part, should be prepared to study the core specification.

For these readers we suggest studying the core specification (volume 1) after becoming familiar
with the technology basics, and then reviewing those profiles that are most relevant for the class
of device being considered. An outline for this reading plan is:

1. Become familiar with the technology basics by reading Part 1 and Chapter 5 of this book
and the SIG white paper already cited, along with other available Bluetooth technology
overviews.
2. Read Chapters 6 though 10 of this book as a group in preparation for studying the core
specification.
3. Thoroughly read all of volume 1 of the specification (or at least all of those sections that
pertain to the implementation at hand).
4. Read Chapter 11 of this book to determine which profiles are relevant to the device or
devices being created and then review those corresponding profiles in volume 2 of the
specification in tandem with the corresponding chapters of Part 3 of this book. Software
developers in particular may need to understand one or more profiles for use in
certification and testing. The generic access profile and the service discovery application
profile may be of interest to all implementers; other profiles may apply only for certain
implementations.[4]

[4]
For example, camera or keyboard developers are unlikely to be interested in telephony profiles,
and developers of a simple pager may not be interested in fax or dial-up networking profiles.

From a Solutions Perspective

Bluetooth wireless technology presents opportunities for many new solutions-not only those
described by existing or planned usage models and profiles but also many sorts of new
applications of the technology which will undoubtedly be invented in the future. Innovators who
are driving these new solutions (especially, although not exclusively software developers and
system architects) may need the fullest understanding of the Bluetooth technology. Those who
are developing Bluetooth applications and solutions often will need to understand the details of
existing profiles and also are likely to require a thorough understanding of the protocol stack.
Knowing the capabilities and limitations of protocols is important for anyone setting out to invent
new usage models.

While the reading plan for those who wish to be thoroughly immersed in the Bluetooth
technology, including solutions developers, might be summarized simply as "read everything," a
more practical outline may be:

37
 1. Start with the typical background information already noted, namely Part 1 and Chapter 5
of this book, the SIG protocol architecture white paper and any other authoritative
overview information.
2. Read the remainder of Part 2 of this book as a prelude to a study of volume 1 of the
specification.
3. Thoroughly read and understand the core specification, referring back to the
corresponding chapters of this book where necessary.
4. Read all of Part 3 of this book in preparation for scrutinizing volume 2 of the specification.
5. Study the profile specifications (volume 2) with Part 3 of this book at hand.

Solutions developers especially will want to keep abreast of new developments in Bluetooth
wireless communication. For these people, continued reading of current articles in trade and
professional journals is advisable, as is taking advantage of additional learning opportunities such
as developers conferences.

38
Part 2: The Bluetooth Specification
Examined
This book continues with an exploration of volume 1 of the Bluetooth specification,
called the core specification. Chapter 5 presents the overall Bluetooth protocol
stack and describes the relationships among its layers. The remaining chapters of
Part 2 examine each layer of the stack in turn, from the lowest layers to the higher
layers. Chapter 6 discusses the Bluetooth radio, baseband, link controller and link
manager layers. Chapter 7 explores the logical link control and adaptation protocol
(L2CAP) layer and host controller interface (HCI). Chapter 8 discusses the RFCOMM
and Service Discovery Protocol (SDP) layers, while Chapter 9 examines the
protocols associated with application interoperability with the Infrared Data
Association (IrDA) standard. Finally Chapter 10 describes the telephony control and
audio protocols.

Part 2 is intended to make important information from the Bluetooth specification

more accessible and understandable while explaining the motivation and rationale
for key elements of the specification. Drawing upon our experience in helping to
develop the specification, we attempt here to reveal its important elements rather
than simply echoing information already available to specification readers.

Chapter 5. The Bluetooth Protocol Stack

The core portion of the Bluetooth specification contains the protocol stack. This stack allows
devices to locate, connect to and exchange data with each other and to execute interoperable,
interactive applications against each other. In this section we present the major components of
the Bluetooth protocol stack, highlighting the relationships among the various layers. The
protocols are presented in more detail in following chapters.

The Protocol Stack Components

Figure 5.1 depicts the high-level components of the Bluetooth protocol stack. The elements of the
stack (protocols, layers, applications, and so on) are logically partitioned into three groups:

• the transport protocol group;

• the middleware protocol group; and
• the application group.

Figure 5.1. A high-level view of the Bluetooth stack.

39
Transport protocol group: This group is composed of the protocols designed to allow Bluetooth
devices to locate each other and to create, configure and manage both physical and logical links
that allow higher layer protocols and applications to pass data through these transport protocols.
The protocols in this group include the radio, baseband, link manager, logical link and adaptation
and the host controller interface.[1]
[1]
Strictly speaking, the host controller interface is not a communications protocol. However, the host controller interface specification
defines formats for packets that cross a host interface and associations between these packets. For example, when packet A is transmitted,
then packet B is expected in return. These formats and associations of packets are key elements of a protocol specification; hence, we group
HCI with the transport protocols.

Middleware protocol group: Additional transport protocols needed for existing and new
applications to operate over Bluetooth links comprise this group. The middleware protocol group
includes both third-party and industry standard protocols and protocols developed by the SIG
specifically for Bluetooth wireless communication. The former includes Internet-related protocols
(PPP, IP, TCP, and so on), wireless application protocols, object exchange protocols adopted from
IrDA and the like. The latter includes three protocols with a designed awareness of Bluetooth
communications that facilitate a large number of other applications to run over Bluetooth links. A
serial port emulator protocol called RFCOMM enables legacy applications that normally would
interface with a serial port to operate seamlessly over Bluetooth transport protocols. A packet-
based telephony control signaling protocol provides for advanced control of telephony operations,
such as group management and mobility support for cordless handsets and base stations. Finally,
a service discovery protocol permits devices to discover each other's services and to obtain
information on how to access those services.

Application group: This group consists of the actual applications that make use of Bluetooth
links. These applications could be legacy applications that are unaware of Bluetooth transports,
such as a modem dialer application or a web-browsing client; or they might be aware of
Bluetooth wireless communication, for instance, applications that use the telephony control
protocol for controlling telephony equipment.

Chapters 6 and 7 present in more detail the protocols in the transport protocol group. Chapters 8
through 10 discuss the middleware protocols developed and adopted by the SIG. Finally all of
Part 3 of this book is dedicated to the various applications that the profiles define.

Before moving to the details of the various protocols and applications, we first discuss the key
protocols in the transport and middleware groups and their relationships to each other.

The Transport Protocol Group

Figure 5.2 shows the organization of the protocols in the transport group. These are the transport
protocols developed by the SIG to carry audio and data traffic between devices. In this chapter,
the presentation of these protocols is made in "top-down" order, or from the point of view of a
transmitting device where traffic passes from the upper transport layers to the lower layers.
Clearly, traffic follows the reverse path in receiving devices. This illustrates an end-to-end data
flow through the protocols of the transport group. In subsequent chapters, these protocols are
presented in a "bottom-up" order, or from the point of view of a receiving device; this is the
order followed in the specification as well.

40
 Figure 5.2. The transport protocol group stack.

The transport protocols support both asynchronous transmissions, for data communications, and
synchronous (or periodic) transmissions, for telephony-grade (64 Kbps) voice communications.
To maintain the high quality of service expected for audio applications, the audio traffic is treated
with high priority. Audio traffic bypasses all of the intermediary protocol layers and is funneled
directly from the audio application to the baseband layer, which then transmits it in small packets
directly over the Bluetooth air-interface.

Before continuing our discussion of the transport protocol group, we observe that the protocols in
the transport protocol group do not belong to the transport layer (layer 4) of the seven-layer OSI
protocol model! With respect to the latter model, the protocols in the transport protocol group
would fit best within the data link layer (layer 2) and the physical layer (layer 1). Collectively, the
set of protocols in the "transport protocol group" form a virtual pipe that is used to transport data
from one device to another across the Bluetooth air-interface. These protocols in principle define
transports between communicating devices; hence, the naming choice for this protocol group.
The term "group of Bluetooth transport protocols" is also used to further emphasize that
reference is made to the transport protocols developed by the Bluetooth SIG rather than to a
transport layer (OSI layer 4) protocol. Note that all of the protocols in this group are always
needed to support the communication between Bluetooth devices. This is not true for any other
protocol outside this group, even the ones that have been developed by the SIG, like RFCOMM.

The L2CAP Layer

Traffic from data applications is first routed through the logical link control and adaptation
protocol (L2CAP) layer. The L2CAP layer shields higher-layer protocols and applications from the
details of the lower-layer transport protocols. Thus, higher layers need not be aware of the
frequency hops occurring at the radio and baseband level nor the specific packet formats used for
transmission over the Bluetooth air-interface. L2CAP supports protocol multiplexing, allowing
multiple protocols and applications to share the air-interface. It also enables segmentation of
large packets used by higher layers into smaller packets for baseband transmission and the
corresponding reassembly of those packets by the receiving device. Furthermore, the L2CAP
layers in two peer devices facilitate the maintenance of the desired grade of service by
negotiating an acceptable level of service. Based on the requested level of service, an L2CAP
41
layer implementation may then exercise admission control for new incoming traffic and
coordinate with lower layers to maintain the desired level of service. The L2CAP layer and its
over-the-air protocol are described in more detail in Chapter 7.

The Link Manager Layer

Link managers in each device negotiate the properties of the Bluetooth air-interface between
them using the link manager protocol (LMP). These properties include bandwidth allocation to
support a desired grade of service for data (L2CAP) traffic and periodic bandwidth reservation to
support audio traffic. Bluetooth link managers in communicating devices use a challenge-
response approach for authenticating the devices. They supervise device pairing (creation of a
trust relationship between the devices by generating and storing an authentication key for future
device authentication) and encryption of the data flowing over the air-interface between the
devices whenever needed. If authentication fails, the link managers may sever the link between
the devices, thus prohibiting any communication between the devices. Link managers also
support power control by negotiating low activity baseband modes of operation (introduced in
Chapter 2 and detailed in Chapter 6) through the exchange of information about parameters such
as the duration of the low-activity baseband mode. Link managers may request adjustments to
the transmission power level for further power conservation as described in Chapters 2 and 6.
The link manager layer and its over-the-air protocol are described in more detail in Chapter 6.

The Baseband and Radio Layers

The baseband layer determines and instantiates the Bluetooth air-interface.[2] It defines the
process by which devices search for other devices and how they connect to them. The baseband
layer defines the master and slave roles (described in Chapter 2) for devices—the device that
initiates a connection process becomes the master of the link, while the other device becomes a
slave. The baseband also defines how the frequency hopping sequences used by communicating
devices are formed. It defines the rules for sharing the air-interface among several devices;
these rules are based upon a time division duplex (TDD), packet-based polling scheme. It further
defines how synchronous and asynchronous traffic can share the air-interface. For example, in
synchronous transmissions, the master transmits to and/or polls a slave device periodically. The
baseband defines the various packet types supported for synchronous and asynchronous traffic,
as well as various packet processing procedures including error detection and correction, signal
whitening,[3] encryption, packet transmission and retransmissions. The baseband layer and its
over-the-air protocol are described in more detail in Chapter 6.
[2]
To make an analogy to a cabled environment, it might be said that the baseband determines the "shape" and "pin
configuration" of the interface.

[3]
Whitening refers to signal scrambling and is discussed more fully in Chapter 6.

Note that the concept of master and slave devices does not propagate higher than the link
manager. At the L2CAP layer and above, communication is based upon a peer-to-peer model and
no special provisions are made for different actions in a master device or in a slave device.

Over-the-air packet transmissions are meaningless unless properly matched radio transmitters
and receivers, or transceivers, are employed. The Bluetooth radio design includes several
parameters designed to make it optimal for use with the Bluetooth protocol stack in short range
wireless communications. The radio section of Chapter 6 gives details of the Bluetooth radio.

HCI Layer

42
The radio, baseband and link manager may be packaged together into a Bluetooth module. The
module then attaches to a host device, enabling that device with Bluetooth wireless
communication. In this configuration, the host contains the L2CAP layer and any appropriate
portions of the higher layers of the stack. The module attaches to the host via some physical
interface, called the host transport, such as Universal Serial Bus (USB), an RS-232 port or a
UART. To enable the development of interoperable Bluetooth modules by different vendors, the
specification defines a common interface for accessing the lower layers of the stack that reside in
the module, independently of the particular physical interface that connects the host to the
module. The host controller interface (HCI) allows higher layers of the stack, including
applications, to access the baseband, link manager and other hardware registers through a single
standard interface. Through HCI commands the module may enter certain modes of operation in
which, say, an authentication operation or a device paging state may be performed. Through HCI
events, higher layers of the stack can be informed of the results of a device inquiry operation,
read the settings for the audio codec residing in the baseband, read the signal strength of
incoming transmissions, and so on. Of course traffic, both synchronous and asynchronous, passes
through the HCI as it is transmitted or received by the host, as well.

While the HCI layer typically resides below the L2CAP layer, it is not a required part of the
specification. It has been developed for the sole purpose of enabling interoperability among host
devices and Bluetooth modules, either of which could come from a variety of developers. Product
implementations need not comply with the HCI specification to support a fully compliant
Bluetooth air-interface. For example, in a tightly integrated, embedded system, an HCI may not
exist at all or it may exist at a different point of the stack, perhaps above L2CAP, and it might
have a form other than the one described in the specification. The HCI and the various host
transport protocols are presented in more detail in Chapter 7.

The control path shown in Figure 5.2 is used to communicate control information between layers.
For example, the L2CAP layer might notify the link manager of its quality of service expectations,
or an application could communicate an end user's request for a lower power consumption mode.
Typically, although not exclusively, the controls that are exposed to the higher layers (including
to an end user) are for setting a mode of operation for the device that persists until that mode is
again explicitly altered through an action that originates at a higher layer. For example, one may
manually enable or disable authentication or encryption for a given device. A high-layer entity,
like an application or a user, could place a device in a reduced power consumption mode, which
would be translated to a control signal that a link manager understands and supports so it can
act accordingly. Similarly, a device could also be placed in a discoverable mode, where the device
responds to inquiries sent by other devices, or the device could be set to a private mode, in
which the device responds only to connection requests from specific known devices, which also
must be authenticated.

The control path is not explicitly described in the specification, but it is interwoven among the
various protocols in the stack. Nevertheless, the HCI specification includes the bulk of the
information that the control path carries. We honor this same approach, discussing the control
signals carried through the control path via the HCI and the various protocols and modes of
operation that these signals affect.

The Middleware Protocol Group

Figure 5.3 depicts the middleware protocol group. The middleware protocols make use of the
underlying transport protocols and present to the application layers standard interfaces that may
be used for communicating across the transports. Each of the middleware layers defines a
standard protocol that allows applications to use a higher level of abstraction than would direct
communications with the lower-layer transport protocols. The middleware protocols consist of:

43
 • RFCOMM, a serial port abstraction;
• Service discovery protocol (SDP), used to describe available services and to locate needed
services;
• a set of IrDA interoperability protocols adopted from the IrDA standard that enables
interoperable use of IrDA-enabled applications; and
• a telephony control protocol (TCS), used for controlling telephone calls that might be used
either for audio or for data.

Each of these protocols, along with Bluetooth audio communication (which is not a protocol per
se but is considered part of the software stack) is described separately below and in detail in the
corresponding chapters that follow.

Figure 5.3. The middle protocol group stack.

RFCOMM Layer
Serial ports are one of the most common communications interfaces used with computing and
communications devices today. Most serial communication involves a cable for transferring data
across serial ports. Since Bluetooth wireless communication is aimed at replacing cables, support
for serial communications and related applications is an important feature for the initial set of
cable-replacement usage models. Peer-to-peer file and object transfer, data synchronization and
dial-up networking are some applications that commonly use serial communications (and
associated cables).

To facilitate the use of serial communications over Bluetooth wireless links, the protocol stack
defines a serial port abstraction called RFCOMM. RFCOMM presents a virtual serial port to
applications; this facilitates the easy migration of applications modeled for cabled serial
communications to the realm of wireless serial communications. An application can use RFCOMM
very much like a standard wired serial port to accomplish scenarios such as synchronization, dial-
up networking and others without significant changes (if any) to the application. Thus the intent
of the RFCOMM protocol is to enable legacy, serial port-based applications to use Bluetooth
transports.

RFCOMM is modeled on the European Telecommunications Standards Institute (ETSI) TS 07.10

standard. This standard defines multiplexed serial communications over a single serial link. The
Bluetooth specification adopts a subset of the ETSI 07.10 standard and also defines some
adaptations designed specifically for Bluetooth communication.
44
Because serial communications are so prevalent in digital devices, the serial port capabilities that
RFCOMM provides to applications make it an important part of the protocol stack, especially for
enabling legacy applications based upon version 1.0 of the specification. Details of the RFCOMM
layer can be found in Chapter 8.

SDP Layer
In some respects, instantiating any of the Bluetooth usage models might be viewed as making
use of some set of services. A primary motivation for forming networks of devices is to allow
those devices to communicate with each other and thus avail themselves of each other's services.
In traditional networks such as Ethernet LANs, services such as file serving, print serving, name
serving, bridges and gateways are provided by some set of devices (usually considered "servers")
in the network so that other devices (usually considered "clients") can use them. In many cases
the clients locate these network services through some static configuration; this configuration is
often established and maintained by a system administrator who configures the client devices (or
gives the necessary configuration information to the users of those devices, who in turn configure
them).

For dynamic ad hoc networks such as those that could be enabled by Bluetooth wireless
communications, though, this sort of static configuration is insufficient. Any two or more devices
might begin communicating over Bluetooth links on the spur of the moment, and if these devices
are to be able to make use of each other's services they require a more dynamic means of
locating those services. Once a communication channel has been established, a next logical step
in device communications might be to find out about services that are available to the device.
This is what the Bluetooth service discovery protocol (SDP) addresses. SDP defines a standard
method for Bluetooth devices to discover and learn about the services offered by other devices;
symmetrically, it defines a way for devices to describe those services offered to other devices.

Service discovery is a key component in enabling end-user value in dynamic networks. The
Bluetooth service discovery protocol is designed specifically to enable this function in an efficient
and optimized manner within environments that exploit Bluetooth wireless communication. SDP is
described in detail in Chapter 8.

IrDA Interoperability Protocols

Chapter 2 described infrared wireless communication and its resemblance in some respects to
Bluetooth wireless communication. The Infrared Data Association (IrDA) has defined protocols for
exchanging and synchronizing data in wireless environments. The SIG has chosen to adopt
several of the IrDA protocols and data models because IrDA and Bluetooth wireless
communication share some important attributes, usage scenarios and applications.

A fundamental requirement for exchanging data among devices is to define the format, both
syntax and semantics, of that data. The infrared object exchange (IrOBEX or often, just OBEX)
protocol developed by the IrDA is a session protocol for peer-to-peer communication. Among the
applications in which OBEX can be used is the exchange of well-defined objects. Data objects
such as electronic business cards (vCard format), e-mail or other messages (vMessage format),
calendar entries (vCal format) and others can all be exchanged using the OBEX protocol. OBEX is
the fundamental building block upon which the usage models of file transfer (object exchange)
and object push are built. Additionally, infrared mobile communications (IrMC), another IrDA-
defined protocol, enables the synchronization of these same objects.

The IrDA interoperability layers of the protocol stack are intended to promote interoperability at
the application layer. They are described more fully in Chapter 9.

45
Networking Layers
Bluetooth wireless communication uses a peer-to-peer network topology rather than a LAN style
topology. Nevertheless, the technology does make allowances for networking, in particular
connecting to larger networks through a dial-up connection or via a network access point. The
specification also discusses interoperability with the Wireless Application Protocol (WAP), a
specification for wireless networking used by devices such as mobile telephones.

Dial-up networking uses the AT command layer of the middleware protocol stack, which is
discussed below, to establish a connection to a network. In many cases, the network being
accessed is one that uses the Internet Protocol, referred to as an IP network. Once a dial-up
connection to an IP network is established, standard Internet protocols (such as TCP, UDP, HTTP
and so on) can be used by the device (perhaps a notebook or handheld computer) that initiated
the network connection to interact with the network.

A device might also connect to an IP network via a network access point as described in the LAN
Access Using PPP Profile. In this case, a Bluetooth link connects the device to a network access
point; the network access point is in turn connected to the larger (most likely, but not necessarily
wired) network. The Internet point-to-point protocol (PPP) is used over the Bluetooth link to
connect to the access point. As with dial-up networking, once the PPP connection is established,
standard Internet protocols can be used to interact with the network. Access to a WAP network
using a WAP gateway works similarly; the same sort of PPP connection is established to an IP
network access point over which standard WAP protocols can be used to interact with the
network.

It is worth noting that release 1.0 of the specification does not define a profile or an instance of
the protocol stack that supports the use of Internet protocols such as TCP/IP directly over
Bluetooth links. The only means of IP network access defined in version 1.0 of the specification is
through the use of PPP as described above. While it certainly should be possible to directly
operate an IP protocol stack using Bluetooth wireless communication as the bearer, the SIG has
not defined an interoperable manner (that is, a profile) for such operation. In all likelihood, future
revisions to the specification will address the direct use of Internet protocols with Bluetooth
wireless communication.

TCS Layer and Audio

As previously noted, one key advantage of Bluetooth wireless communications is its ability to
carry voice traffic as well as data. While the protocol layers discussed to this point exist primarily
for use with data traffic, the Bluetooth telephony control specification (TCS) layer is designed to
support telephony functions, including call control and group management. These operations are
often associated with voice calls in which TCS is used to set up the call parameters; once a call is
established, a Bluetooth audio channel can carry the call's voice content. TCS might also be used
to set up data calls, such as would be used with the dial-up networking profile; in this case, the
call content is then carried as standard data packets over L2CAP.

The TCS protocols are compatible with the International Telecommunications Union -
Telecommunication (ITU-T) Q.931 specification. Because they use a binary encoding, these
protocols are referred to in the specification as TCS-BIN. During development of the specification,
the SIG also considered a second TCS protocol called TCS-AT. TCS-AT defined a modem control
protocol (often called AT commands) that flowed through the RFCOMM layer. While AT commands
over RFCOMM are indeed used for some applications, the specification does not define a separate
protocol for TCS-AT. TCS-BIN is appropriate for some of the release 1.0 telephony-based profiles;
applications that need to use AT commands over the RFCOMM serial interface are free to do so
(as shown in Figure 5.3), but the specification does not define these AT commands as a separate

46
protocol. Several of the version 1.0 profiles, including headset, fax, and dial-up networking, all
use AT commands over RFCOMM rather than the TCS-BIN protocol.

The TCS-BIN protocol includes call control functions, group management functions and a method
for devices to exchange call signaling information without actually placing a call or having a call
connection established. Each of these facets of TCS is detailed in Chapter 10.

Audio, especially voice audio, is treated uniquely in Bluetooth communication. Because audio
traffic is isochronous, meaning that it has a time element associated with it, voice audio traffic
typically is routed directly to and from the baseband layer; it does not go through upper layers
such as L2CAP.[4] Special baseband packet structures, called synchronous connection-oriented (or
SCO) packets are defined for use with typical audio traffic. Bluetooth communication allows for up
to three audio channels at one time (with some bandwidth left over for data traffic).
[4]
Packetized digital audio could be carried as standard data packets using L2CAP, but this case would be treated as data
traffic. In general, when we refer to voice or audio throughout this book we are speaking of the Bluetooth audio traffic carried
directly over the baseband link in SCO packets.

Bluetooth audio communication takes place at a rate of 64 kilobits per second (Kbps) using one
of two data encoding schemes: 8-bit logarithmic pulse code modulation (PCM) or continuous
variable slope delta (CVSD) modulation. Compression techniques called A-law and µ-law are
applied for PCM audio.

Since voice is a primary application of audio communication (especially in devices such as smart
phones that use Bluetooth wireless communication), audio is often equated with voice. Of course,
voice is not the only sort of audio traffic that can be carried by the Bluetooth baseband. So long
as the audio stream can be sufficiently rendered at 64 Kbps, it can be transmitted and received
over Bluetooth links. Thus, in addition to voice, Bluetooth audio channels could carry other forms
of audio, such as some music[5] or short audio clips.
[5]
Bluetooth audio, being optimized for voice traffic, is not designed to carry music of high quality, such as CD-quality music.
Support of music is likely to require the use of compression techniques.

Because voice is an integral part and key attribute of Bluetooth wireless communication, it may
be somewhat surprising that only a few pages of the specification deal directly with audio. This is
not because audio is unimportant; rather it is mostly because audio traffic is carried directly over
the baseband in packets designed for that purpose. Thus it is not necessary to include lengthy
explanations of audio traffic - the format of the audio data is specified using existing standards -
and that, for the most part, is that. It is, however, quite important to understand the baseband
SCO packet structure and usage to achieve a fuller understanding of Bluetooth audio
communication. Thus, while audio is explained in more detail in Chapter 10, it is also indirectly
detailed in the baseband discussion of Chapter 6.

The Application Group

While some of the protocols that we refer to here as middleware protocols (especially IrDA
interoperability protocols like IrOBEX or IrMC) might be considered by some to be application-
level protocols, this is not what we mean when we write about the application group. The
application group here refers to software that resides above the protocol stack as defined by the
SIG. This is software that is supplied by device manufacturers, independent software vendors or
others which exercises the protocol stack to accomplish some function that benefits the user of a
Bluetooth device. Application software as defined here is depicted in Figure 5.4, which illustrates
several possibilities for the organization of Bluetooth application software.

47
 Figure 5.4. General view of the application group, with possible
application organization, including adaptation layer and common
application services.

Of most interest within the application group are those applications that instantiate the Bluetooth
profiles. That is, given a Bluetooth protocol stack in a device, someone still needs to write
application software to drive that stack to accomplish functions such as dial-up networking, file
transfer, headset communications and so on. The SIG defines only the middleware and transport
protocols for the stack; it does not define application protocols per se nor does it define
application programming interfaces (APIs). Yet applications clearly are needed to accomplish the
usage scenarios that are envisioned for Bluetooth wireless communications. To realize a
Bluetooth profile, it is the added application code that uses the underlying protocol stack to
supply value to an end user. While a profile defines how interoperable applications that address
various usage cases are to be built, the look and feel of these applications is not defined in the
specification. Application software developers have sufficient latitude to differentiate their
products with added features or user interfaces, without violating the interoperability guidelines
spelled out in the profiles.

It might be the case that some existing ("legacy") software that was designed for use with
transports other than Bluetooth wireless communication can be employed using Bluetooth links.
Because the SIG has defined layers of the protocol stack, such as the IrDA interoperability and
RFCOMM layers, to support such legacy software, it could be possible for these existing
applications to take advantage of Bluetooth links with little or no change. Examples include
existing IrDA applications for object exchange or synchronization and dial-up networking
applications. These applications all use existing protocols which are supported in Bluetooth
environments, and typically they are designed to work over a serial port. Since the protocol stack
includes the RFCOMM serial port abstraction, many existing applications of these and other types
should be able to be mapped from IrDA or serial cable environments to Bluetooth environments
in a straightforward manner, with minor (if any) changes to those applications. One way to
accomplish this on some platforms might be to develop a thin layer of Bluetooth adaptation
software that maps existing serial and other communications for the platform to the
corresponding Bluetooth communications stack, as illustrated in Figure 5.4.

48
Another option is to develop new applications specifically designed to operate in Bluetooth
environments. In cases where no existing application accomplishes a Bluetooth usage case, or
when it is desirable to include application features that exploit unique capabilities in the protocol
stack, a new application may be a good approach. When applications are developed specifically to
leverage Bluetooth wireless communication for some platform, often it may be advantageous to
develop common services for those applications. Such common services might include security
services, connection management services, SDP services, and so on. These common application
services might be realized with application-level code such as a security manager (see [Muller99]
for a discussion of this topic), a Bluetooth management console (perhaps with associated user
interface that allows a user to select devices and services in a piconet with which he wishes to
interact), a common SDP client and server (again perhaps with a user interface for service
searching and browsing), and so on. Figure 5.4 includes a representation of these common
application services.

If the specification does not define APIs, how can standard applications for Bluetooth usage cases
be developed? The answer lies in the profiles. Recall that profiles are developed to establish a
base point for use of the protocol stack to accomplish a given usage case in an interoperable
manner. Because Bluetooth wireless communication is expected to be supported in a plethora of
device types, on various platforms, the specification of a single standard API that would be
appropriate for the full range of devices and platforms could be quite difficult, to say the least.
But since the SIG has chosen profiles as the means to establish interoperability among all of
these devices, it seems that these same profiles can provide guidance for developing applications
on the many platforms that are relevant for Bluetooth technology. As noted above, both legacy
applications and applications developed specifically to use Bluetooth links could realize Bluetooth
profiles.

When a technology is incorporated into a platform and results in the need for new APIs, those
APIs are often best developed by experts on that platform rather than by experts on the
technology. Thus the SIG has chosen not to specify Linux® APIs, Windows® APIs, Symbian™
APIs or any other APIs; instead the profiles define the necessary function to enable platform
experts to develop appropriate APIs for use with Bluetooth applications on relevant platforms. So,
even though APIs are not included in the specification, the profiles do indeed give direction to
application developers. Some profiles do this more directly than others. The service discovery
application profile, for example, describes potential application programming models and defines
service discovery primitives that could in a straightforward manner map to APIs on a given
platform.

Application development is not limited to software that instantiates profiles. As with devices, the
landscape for applications is broad, perhaps even virtually unlimited. While the release 1.0
profiles define a base set of interoperable applications, and while new profiles will undoubtedly
continue to be developed, these are not the only usage cases for which applications are expected
to be written. Industry innovators are likely to develop many new uses for the Bluetooth
technology and to create the application software to support these new usage scenarios. As more
software continues to be developed to enable the existing profiles on multiple platforms, the APIs
developed for and experience gained in that software development should provide a foundation
for new applications. The opportunity for these new applications is tremendous.

49
Chapter 6. The Lower Protocols of the Transport Group
This chapter and the following one present the protocols in the transport protocol group, from the
radio up to and including L2CAP. In the Bluetooth specification, these protocols are detailed in
over 600 pages. It is not within the scope of this book to recreate the algorithmic and
implementation details of the specification. Instead, the key components of the protocols are
highlighted. Readers who may want to learn about the protocols in more detail should
supplement this reading with the study of the corresponding parts of the specification.

This chapter focuses on the lower-level functions (including the over-the-air protocols and
information processing) in a Bluetooth system, which typically are performed within the Bluetooth
hardware/firmware module as shown in Figure 6.1. The host I/O portion is covered in the next
chapter in the presentation of the host controller interface.

Figure 6.1. High-level functional composition of a Bluetooth module.

As shown in Figure 6.1, a Bluetooth device [1] represents the complete physical entity (such as a
notebook computer, a digital phone, an information appliance, and so on) that contains
applications that can communicate using the Bluetooth wireless technology incorporated in that
device. Here we assume that a device is associated with one and only one transport protocol
group implementation and air-interface. However, as mentioned in the previous chapter and
further elaborated in the next one, the L2CAP layer supports the multiplexing of several higher-
layer protocols, like RFCOMM, SDP, and so on, and hence middleware protocol stacks and
applications, as well.
[1]
The terms unit, node, station, and so on may (and have) also been used instead of the term device. Insofar as possible,
however, the use of these other terms is avoided. The reason for this choice will become apparent later.

The design point of the Bluetooth transport protocols is dictated primarily by low manufacturing
complexity, associated low cost and fast time to market. For this reason, a low-cost, easy-to-
implement, frequency-hopping spread-spectrum radio solution was selected. In addition, the
selection of a master/slave architecture for the baseband transmission was dictated by the ad hoc
nature of the systems considered. In particular, Bluetooth piconets can form spontaneously
among disparate devices with vastly different power and computing capabilities, unlike wireless
LAN systems which are designed primarily to support a wireless extension of LAN connectivity
services to relatively "power-unconscious" personal computers.

To support ad hoc connectivity with minimal (if any) state maintained by the Bluetooth devices,
piconets are dynamically formed in isolation without the support of third-party (infrastructure)
control signaling. For as long as needed, the master of a piconet serves as the control point for
the communications on the piconet. For the duration of the existence of a piconet, the operation

50
of a master resembles that of a base station of a picocellular system. Thus, the Bluetooth
technology permits the spontaneous creation of a temporary picocellular system, where traffic is
regulated by a spontaneously created base station, the master, that regulates the traffic to and
from the other member of the picocell, the slaves. Recall from previous chapters that the
Bluetooth technology permits the creation of multiple, ad hoc picocellular systems that remain
operational even in cases of temporal and spatial overlapping. The use of master and slaves
reduces the complexity of the design and thus the cost of deploying the Bluetooth technologies.

The rest of this chapter highlights the Bluetooth radio; the link controller and the baseband
functions it controls, like piconet creation and the medium access protocol; and the link manager
that configures and manages the links between devices. In the reference implementation of a
Bluetooth module, the radio and the link controller typically are implemented in hardware while
the link manager is in firmware. As such, the radio and the link controller (with its baseband
functions) were the first parts of the specification to mature, providing a stable enough hardware
specification for chip designers to use in designing their early Bluetooth chipsets. The link
manager specification originally was focused primarily on security-related transactions. The SIG's
further work on the link manager specification has enriched it over time to take full advantage of
the capabilities available in the baseband specification.

The Bluetooth Radio

The Bluetooth system operates in the 2.4 GHz industrial, scientific, and medical (ISM) band. The
ISM bands are license-free bands set aside for use by industrial, scientific and medical wireless
equipment. Regulatory authorities around the world have opened the ISM bands for use by low-
power systems that can be operated without the need for a license but nevertheless under strict
regulations. In the United States, these regulations are set by the Federal Communications
Commission (FCC) and are detailed in the Code of Federal Regulations part 15 [FCC99]; section
15.247 of the FCC regulations deals with the operational rules of intentional radiators operating in
the various ISM bands including the 2.4 GHz band.

The 2.4 GHz ISM band is a globally available radio band, albeit not frequency harmonized. Table
6.1 shows the ISM frequency availability in the majority of countries around the globe.

Table 6.1. License-free frequency allocation in the 2.4 GHz band.

2.4 GHz ISM band Frequency channels (MHz) k = 0, 1, LGB [1] UGB[2]
(MHz) …, m -1 (MHz) (MHz)
2,400.0 – 2,483.5 2,402 + k; m = 79 2.0 3.5

[1]
1. "LGB" stands for "lower guard band."

[2]
2. "UGB" stands for "upper guard band"

The radio part of the specification consists mostly of a series of design specifications for Bluetooth
transceivers, like in-band and out-of-band spurious emissions, frequency accuracy, co-channel
and adjacent-channel interference, out-of-band blocking, intermodulation characteristics, and so
on. The selection of the radio design specifications is driven by the requirement to allow the
development of high-quality, low-cost transceivers that comply with the various 2.4 GHz ISM
band regulations around the world.

The numerous design parameters plus the radio testing conditions are not repeated here.
Readers interested in the Bluetooth radio design can find an abundance of information in the
corresponding part of the specification. Since no new data-exchange protocols nor data-

51
processing algorithms were developed for the Bluetooth radio, the radio part of the specification
was the first to be completed. The errata to this portion of the specification are minimal, and the
few that surface pertain mostly to the accommodation of new regulations or refinement of the
radio testing procedures.

The Bluetooth transceiver is a frequency-hopping spread-spectrum (FHSS) radio system

operating over a number m of 1 MHz-wide channels. While for the majority of countries m = 79,
as shown in Table 6.1, regulations in certain countries may further constrain the license-free
frequency spectrum for the 2.4 GHz ISM band. Thus, the Bluetooth radio (and the baseband
described in the next section) design can accommodate two alternatives that operate over 79 or
23 channels, each one of which is 1 MHz wide. For frequency-hopping systems operating in the
2.4 GHz ISM band, the FCC part 15.247 regulations restrict the maximum peak output power of
the radiator to no more than 1 watt (30 dBm). Moreover, at least 75 out of the 79 frequency
channels must be used pseudo-randomly with a total residence time in each of the frequencies
not to exceed 0.4 seconds within a 30-second period. A Bluetooth radio utilizes the maximum
number of channels available, 79 in the United States, and it hops at a high rate, 1,600 hops per
second, pseudo-randomly across all these frequencies to achieve high noise resilience. The use of
direct-sequence spread-spectrum (DSSS) systems, which are also permitted in the 2.4 GHz ISM
band, may be prohibitively costly for the low-cost requirement of Bluetooth radios.

Figure 6.2 summarizes the key operations in the Bluetooth radio. The figure also shows a pair of
logical interfaces for carrying data and control information between the radio and the rest of the
Bluetooth system. Here data relates to all information that is transmitted or received over the air.
The control information controls the behavior of the radio. On the transmit side, this includes the
carrier frequency to which the transmitter needs to tune prior to transmission of a bit stream of
information over the air and the power level that is to be used for this transmission. On the
receive side, this includes the carrier frequency to which the receiver must tune for receiving a bit
stream of information and (optionally) the strength of the signal being received. Power-supply
and time-signaling lines are not shown in the figure. A standardized set of interfaces for the data
and control information is not provided in the specification. Thus, chip designers and
manufacturers can choose to integrate the radio component with the rest of the components of a
Bluetooth module in the way they believe is best for a low-cost, power-efficient system. Table 6.2
summarizes some of the key operational parameters of the Bluetooth radio.

Figure 6.2. The Bluetooth radio operations.

52
 Table 6.2. Key operational parameters of the Bluetooth radio specification.
Modulation Gaussian frequency-shift keying BT product[3] 0.5; modulation index:
(GFSK) 0.28 – 0.35
Symbol rate 1 Msymbol per second using the binary GFSK, this translates
into 1 Mbps raw link speed;bit
transmission time:1 µsec
Frequency- 1,600 hops per second, typical residence time: 625 µsec per hop
hopping rate
3,200 hops per second for inquiries residence time: 312.5 µsec per hop
and pages
Transmit Class 3: 0 dBm (1 mW) a typical Bluetooth radio; optional
power power control to below –30 dBm
Class 2: 4 dBm (2.5 mW) optional power control as above

Class 1: 20 dBm (100 mW) required power control to at least 4

dBm; optional power control as above
Receiver a Bluetooth receiver must attain a the –70 dBm sensitivity level shall be
sensitivity raw bit error rate (BER)of 0.1% with attained for any input signal generated
an input signal level of –70 dBm or by any compliant Bluetooth transmitter
lower

[3]
The term "BT product" is not short for "Bluetooth product." It is a parameter describing the quality of transmitted waveforms
expressed as the product of the bandwidth of the modulation filter and the bit time.

The transmit power and receiver sensitivity values are examples of design decisions that were
made to reduce cost and power requirements for the Bluetooth radio. An IEEE 802.11 wireless
local area network (WLAN) may use up to 30 dBm (1000 mW) of transmit power in the United
States (lower power-levels in other parts of the world) and not less than 0 dBm (1 mW). Hence,
an 802.11 wireless solution may not be suitable for many power-constrained personal, portable
devices. The sensitivity level is also much lower than that of an 802.11 radio receiver[2]. This
means that a simpler Bluetooth radio can be built at a reduced cost as compared to an 802.11
radio.
[2]
The receiver sensitivity for an IEEE 802.11b radio receiver, which uses DSSS, is specified to be –80 dBm for a frame error
rate of 8% for a 1024-byte MAC protocol data unit when a 2 Mbps DQPSK modulation is used. For more information on the
IEEE 802.11 WLANs see [IEEE99]

The Link Controller and Baseband

As discussed in the previous section, the radio deals with the acts of sending and receiving data
over the air. Outside the scope of the radio's responsibilities are considerations such as what data
to transmit and when, what data to wait for and when, and which carrier frequency and transmit
power to use. These are the responsibilities of the Bluetooth link controller, described later in this
chapter, that executes the baseband communication protocol and related processes.

Figure 6.3 summarizes the key functions of the Bluetooth baseband. These include piconet and
device control functions like connection creation, frequency-hopping sequence selection and
timing; modes of operation such as power control and secure operation; and medium access
functions like polling, packet types, packet processing and link types. These items are detailed
later in the chapter as we proceed through the operational phases of a Bluetooth device. The
figure also shows a set of logical interfaces for carrying data and control information between the

53
baseband and the rest of the Bluetooth system. For the same reasons mentioned in the radio
section, the specification avoids specifying any standardized set of interfaces for the data and
control information. Nevertheless, their presence, even on a "logical" plane, aids this
presentation, since it allows us to concentrate on the baseband operations in isolation from the
rest of the Bluetooth system.

Figure 6.3. The baseband functions.

Due to the vast and diverse areas covered by the baseband specification, the remainder of this
section tries to combine the information flow in the specification with that of more traditional
communication protocol standards and related articles. The discussion progresses stepwise,
identifying the key components over which Bluetooth communications actually occur. We begin
with the definition of a piconet over which Bluetooth devices can exchange information packets.
We then describe fundamental helper elements that assist in the creation and maintenance of the
piconet, such as the Bluetooth clock and frequency-hopping selection process. Using these helper
elements, the presentation continues with the description of the procedures that Bluetooth
devices follow to create and join a piconet. Finally, with a piconet in place, we focus on protocols
and processes like medium access control, error control, security, power-saving operation and so
on, that are exercised on the Bluetooth devices and on information packets sent and received
over the piconet.

The Piconet
For devices to communicate with each other using Bluetooth wireless technology, they need to be
part of a piconet. Simply stated, a piconet comprises a shared communications channel through
which members of the piconet communicate. In the FHSS space in which Bluetooth radios
operate, this communication channel consists of a well-defined sequence of frequency hops
pseudo-randomly selected from the set of frequencies in Table 6.1 at a nominal rate of 1,600
hops per second. The members of the piconet are able to follow the successive hops of the
frequency-hopping sequence in a synchronized manner. Piconets are formed as needed and

54
endure for as long as participating devices need to communicate. The baseband operations define
how a frequency-hopping sequence for a piconet is created, how devices learn how to follow it
and hence join the piconet, and how to send and receive information packets communicated in a
coordinated manner between devices in the piconet.

Bluetooth piconets are formed in a rather ad hoc manner. They are formed on demand among
devices that want to communicate with each other without relying on the services of a dedicated
support entity, such as a base station in a cellular network or a corporate or home WLAN. The
baseband protocol establishes the rules according to which these ad hoc connections are
established such that devices communicate in a coordinated and efficient manner.

The frequency-hopping sequences that define the communication channels in piconets are highly
uncoordinated, or, to be more precise, they are created in a manner that makes them appear
highly uncoordinated. Thus, owing to the frequency-hopping nature of transmissions in a piconet,
multiple piconets may exist in time and space with minimal interference among themselves.
Multiple piconets overlapping, at least partially, in time and space are referred to as scatternets.
This opens the possibility of interpiconet communications when devices become members of
multiple piconets.

Each piconet has one and only one master and one or more slaves. These roles are temporary
ones and they are meaningful only while Bluetooth devices are members of a piconet. Certainly,
Bluetooth devices may be built to operate only as masters or only as slaves, but this is a host
application and usage scenario issue rather than a Bluetooth specification issue. The specification
generally assumes that a Bluetooth device is capable of acting both as a master and as a slave,
depending upon the role required to accomplish a given usage case. In the case of a scatternet, a
device that participates in more than one piconet can be the master of at most one of these
piconets, while it can be a slave in several of them. Through a detailed process, described later in
this chapter, a master and a slave may exchange their roles. It is also possible for an "old"
piconet based around an original master to be migrated to a new piconet with a new master.
Piconet migration as well as communication across scatternets are not discussed in detail here,
because they are not very mature processes in the version 1.0 specification, which does not
define any usage scenarios that address communication across piconets. Nevertheless, the
specification contains necessary considerations that could allow these processes to be
accomplished.

The primary role of a master for a piconet is to define:

• which frequency-hopping sequence the members of this piconet shall follow;

• when frequency hops shall occur, thus defining the timing foundation for timed events in
the piconet;
• which particular frequency is the "current" frequency; and
• which slave will be transmitted to and/or which slave will be permitted to transmit next
(recall that transmission on the Bluetooth air-interface is through polling of the slaves).

The first three items are strongly associated with how a piconet is formed and maintained and
how devices join it. The last item is associated with how transmissions occur in a piconet.

Figure 6.4 shows the operational states for a Bluetooth device. In the connected state, the device
is a member of a piconet. On the other hand, when a device is not associated with any piconet or
participates in no action that could result in its forming or joining a piconet, it is said to be in the
standby state. The standby state is the default operational state for a Bluetooth device. In this
state, a device typically idles with only its native clock operating in a low-power mode.

To move to the connected state, a device goes through the inquiry and page states, which are
instantiated differently but in a complementary manner within a potential master and a potential
55
slave. In the inquiry state, a device learns about the identity of other devices in its vicinity; these
other devices must be in an inquiry scan state to listen for and subsequently respond to inquiries.
In the page state, a device explicitly invites another device to join the piconet whose master is
the inviting device; the other device must be in the page scan state to listen for and subsequently
respond to pages. As Figure 6.4 shows, a device may bypass the inquiry state if the identity of a
device to be paged is already known. The figure also implies that while a device is a member of a
piconet, it may still perform inquiries and pages for additional devices to join this or some other
piconet. In the latter case, a scatternet (multiple piconets overlapping in time and space as
discussed in Chapter 2) eventually could be created.

Figure 6.4. Operational states of a Bluetooth device.

To become a member of a piconet, a Bluetooth device needs to know how to recreate the
frequency-hopping sequence that defines that piconet and which frequencies from this sequence
will be visited and when. Also, to participate in communications over the piconet, the device
needs to know how to formulate, read and write information packets on the piconet. All of these
operations, as well as nearly every other operation in a Bluetooth device, are related to the
following two fundamental elements:

• the Bluetooth device address

• the Bluetooth device (or native) clock

Any process in the Bluetooth baseband is intimately related to these two elements. Two baseband
processes are notable and we refer to them as the fundamental processes, which are those that
generate:

• the frequency-hopping sequence, and

• the access code.

These fundamental elements and fundamental processes are detailed below.

The Bluetooth Device Address (BD_ADDR)

The Bluetooth device address (BD_ADDR)[3] is the most static entity of a Bluetooth device. The
BD_ADDR is a single 48-bit address electronically "engraved" on each device. A device's
BD_ADDR is globally unique among Bluetooth devices. To guarantee uniqueness, a numbering
authority assigns BD_ADDRs. The BD_ADDR is an IEEE 48-bit address, similar to the medium
access control (MAC) address of IEEE 802.xx LAN devices.
[3]
The use of the notation BD_ADDR in the specification is the main reason for choosing the term "device" in Figure 6.1 over
any of the other legitimate alternatives identified in footnote 1 of this chapter.

56
The 48-bit address field, shown in Figure 6.5 from the least significant bit (LSB) to the most
significant bit (MSB), is partitioned into three parts: the lower address part (LAP), the upper
address part (UAP), and the non-significant address part (NAP). The 24 bits of the UAP and the
NAP constitute the organization unique identifier (OUI) part of the address that is assigned by the
numbering authority to different organizations. The LAP is assigned internally by various
organizations. The various parts of the BD_ADDR are involved in nearly every operation of the
baseband from piconet identification, to packet header error checking, to authentication and
encryption key generation. These items are discussed in more detail later in this chapter.

Figure 6.5. The Bluetooth 48-bit device address (BD_ADDR).

The Bluetooth Clock

Each Bluetooth device has a free-running 28-bit (native) Bluetooth clock. The Bluetooth clock is
never adjusted and is never turned off. The clock ticks 3,200 times per second or once every
312.5 µsec, representing a clock rate of 3.2 KHz. Notice that this is twice the nominal frequency-
hopping rate of 1,600 hops per second. The clock has an accuracy of ± 20 ppm[4] In low-power
modes like standby, hold, and park (introduced in Chapter 2 and detailed later in this chapter),
lower power consumption can be achieved by using a low-power oscillator to drive the clock at a
reduced accuracy of ±250 ppm. The Bluetooth clock is illustrated in Figure 6.6.
[4]
The abbreviation "ppm" stands for "parts per million" and it is a metric of clock accuracy, where the smaller the value the
more accurate the clock.

Figure 6.6. The Bluetooth native clock.

The Bluetooth clock wraps around just short of once per day. The Bluetooth clock plays a
fundamental role in deciding when a device can or cannot transmit or listen for a transmission,
and at which frequency and for what types of information packets it transmits or listens. A slave
device uses the value of the Bluetooth clock of a master to accomplish piconet communications
as discussed below. The significance of the time intervals shown in Figure 6.6 will become
apparent as we proceed through the rest of this chapter.

The Frequency-Hopping Sequences

For devices to communicate with each other, they must transmit and receive on the same
frequency at the same time. The frequency-selection module (FSM) contains the procedure for
selecting the next frequency to be used under various operating conditions. The algorithmic and
implementation details of FSM are beyond the scope of this book. They are covered extensively in
chapter 11 of the Baseband part of the specification.

57
 Figure 6.7. The frequency-selection module (FSM).

In Figure 6.7, the notation (x y) means that there are two permissible alternatives, x or y, only
one of which is entered into the module based upon the circumstances. The notation V[m:n], m
n, denotes the use of bits m through n of the bit field V; m is the least significant bit (LSB) of
the two.

Depending upon the country of use, the FSM is set by the manufacturer to operate in a 23- or
79-channel frequency hop mode as explained in the radio section of this chapter.

Given the country frequency-hop mode, the clock input determines which frequency from the
current frequency-hopping sequence is to be used, and when. In other words, the clock input
determines the phase of the frequency-hopping sequence. The actual frequency-hopping
sequence is determined through the address input. In each of the three active operational states
shown in Figure 6.4, a different combination of clock and address inputs is supplied to the FSM,
as explained immediately below.

Normal Piconet Operation

During normal piconet operation, the channel-hopping sequence is used. For the channel-hopping
sequence, the address input to the FSM for all devices in the piconet consists of the 28 least
significant bits, BD_ADDR[0:27], of the master's Bluetooth device address. The channel-hopping
sequence has a very long period, but the (23 or 79) hop frequencies are distributed equally over
short periods of time to satisfy the regulatory requirements for the frequency-hopping sequence
described earlier in this chapter.

During normal piconet operation, a new frequency from the channel-hopping sequence is selected
every 625 µsec. This interval is the period for bit c 1 of the Bluetooth clock shown in Figure 6.6; in
this case, the LSB of the clock, c 0, is not used. The time, 625 µsec, between two successive ticks
of bit c1 of the clock is referred to as a slot. For devices in the connected state, the slot
boundaries coincide with the ticks of bit c1 of the master's clock. Furthermore, all the devices in
the piconet utilize the current value of the master's clock to drive their FSMs.

During the residence time at a frequency, a device may transmit a single packetized piece of
information, referred to as a baseband packet data unit (BB_PDU)[5] BB_PDUs are strictly
constrained within the residence time at a frequency. However, the residence time at a frequency
may occupy multiple slots, thus permitting multi-slot BB_PDU transmissions to occur as discussed
below. Following a multi-slot transmission, the next frequency selected is the one that would
have been used if single-slot transmissions had occurred instead. That is, the frequencies from
the channel-hopping sequence are selected on a slot basis, although the frequency hops
themselves occur on a BB_PDU basis.

58
 [5]
The specification refers to the baseband PDUs as such or simply as packets. The BB_PDU nomenclature is introduced here
for consistency with use of the terms PDU and packet elsewhere. Nevertheless, the term packet is used whenever appropriate
for ease of reading.

Page Operation

One device "invites" another device to join its piconet through the use of a page. The device
issuing the page is called a paging device, and the device listening (or scanning) for pages is
called the paged device. A paging device selects a new frequency at which to transmit a page
every 312.5 µsec, which is the period of bit c0 of a Bluetooth clock. During page scans, when a
device listens for transmitted pages, a new listening frequency is selected every 1.28 seconds,
which is the period of bit c12 of the clock. Note that a paging device changes frequencies at a
much higher rate than a paged device. While the paged device uses its own clock to drive its
FSM, the paging device uses its best estimate of the clock of the paged device to drive its own
FSM. The paging device estimates the clock value of the paged device based upon the most
recent communication between the devices. In the worst case, the paging device could use its
own clock.

During the page operation, the page-hopping sequence is used. To generate this sequence, the
paging and paged devices use the 28 least significant bits of the address of the paged device—
that is, the LAP and part of the UAP of the address shown in Figure 6.5—as the address input to
their respective FSMs. For each device, its page-hopping sequence is a well-defined, periodic
sequence composed of 32 (resp.[6] 16) frequencies uniformly distributed over the 79 (resp. 23)
frequency channels permissible in the 2.4 GHz band in various countries. The period of the page-
hopping sequence is 32 (resp. 16) hops.
[6]
The abbreviation "resp." stands for "respectively."

Inquiry Operation

Through inquiries a device "searches" for other devices in its vicinity. Just as in page operation,
an inquiring device selects a new frequency at which to transmit an inquiry every 312.5 µsec.
Inquired devices, executing inquiry scans, select a new listening frequency every 1.28 seconds.
Note that an inquiring device changes frequencies at a much higher rate than an inquired device.
Both the inquiring and inquired devices use their own clock to drive their FSMs.

During the inquiry operation, the inquiry-hopping sequence is used. To generate this sequence,
the inquiring and inquired devices use the 28 least significant bits of the "inquiry address,"
referred to as the general inquiry access code (GIAC) LAP, as the address input to their
respective FSMs. The inquiry address is a known, reserved 24-bit field equivalent to the 24-bit
LAP of a Bluetooth address. The remaining four bits of the inquiry address (UAP[0:3]) are equal
to hexadecimal '0x0'. The GIAC LAP is '0x9E8B33' and no Bluetooth device is allowed to have an
address whose LAP coincides with the GIAC LAP. The inquiry-hopping sequence is a well-defined
periodic sequence composed of 32 (resp. 16) frequencies uniformly distributed over the 79 (resp.
23) frequency channels permissible in the 2.4 GHz band in various countries. The period of the
inquiry-hopping sequence is 32 (resp. 16) hops.

The Access Code

The access code is a 68- or 72-bit field prepended to each BB_PDU prior to its transmission over
the Bluetooth air-interface. The access code serves a multitude of purposes including identifying
the piconet, synchronizing on the incoming bit stream, aiding in establishing the proper DC-
offset, and others. The focus here is the role of the access codes in identifying the state
classification (inquiry, page, or connected) of transmitted BB_PDUs. The algorithmic and
implementation details of the access code generator are beyond scope of this book. They are

59
covered extensively in chapter 13 of the Baseband part of the specification. Figure 6.8 depicts an
overview of the functions related to the access code.

Figure 6.8. The access code functions; the "+" symbol above implies the prefixing of the access
code in front of the transmitted packet.

To receive a transmission, a device uses a correlator, as shown in Figure 6.8, at its receiving end.
The correlator can be tuned to particular access codes. If the correlator matches the access code
of an incoming transmission sufficiently well, the receiver will continue receiving the incoming bit
stream and pass it to higher layers for processing. Note that to conserve power, these higher
layers may not be fully powered until the correlator informs them of an incoming message that
has the proper access code prefixed to it.

As before, there are three classes of access codes that the device utilizes; each is described
below.

Normal Piconet Operation

During normal piconet operation, each transmission on a given frequency of the channel-hopping
sequence is preceded by the channel access code (CAC) generated using the LAP of the address
of the piconet master. Only transmissions that contain the proper channel access code are
received by a device.

Page Operation

During page operation, each paging transmission on a given frequency of the page-hopping
sequence and each response to it are preceded by the device access code(DAC) generated using
the LAP of the paged device's address.

Inquiry Operation

During inquiry operation, each inquiry transmission on a given frequency of the inquiry-hopping
sequence and each response to it are preceded by an inquiry access code(IAC). There are 64
IACs, including the GIAC, associated with 64 reserved LAPs. Excluding the GIAC, the remaining
63 IACs are referred to as dedicated IACs (DIACs). The IAC LAPs belong to the set {'0x9E8B00',
…, '0x9E8B3F'}. No device can have an address whose LAP matches any of these reserved LAPs.
Note that no matter which IAC is used, the inquiry-hopping sequence over which this IAC is
transmitted is generated using the GIAC. This is done to allow devices with multiple receiver

60
correlators, as highlighted in Figure 6.8, to follow a single inquiry-hopping sequence but still be
able to listen to multiple classes of inquiries simultaneously.

While the specification does not define how IACs are to be used, they are intended to be used
primarily as a filtering mechanism for identifying well-defined subsets of the devices that may
receive inquiries. While all devices that execute inquiry scans use the GIAC to generate the
inquiry-hopping frequency, only those devices whose receiver correlators are tuned to a
particular IAC will receive and respond to inquiries that contain that particular IAC.

Table 6.3 summarizes the various parameters related to the fundamental processes for each of
the three operational states of a Bluetooth device.

Table 6.3. The FSM inputs and the access codes used during the various active states of a device.
Device Frequency-hop module Access code
state
Connected clock: master's; address: master's channel access code (CAC); it coincides with
the master's device access code (DAC)
Inquiry clock: own; address: GIAC general or dedicated inquiry access code
(GIAC or DIAC)
Page clock: (estimate of) paged device's; paged device's device access code (DAC)
address: paged device's

As discussed earlier, the Bluetooth clock and the BD_ADDR of the master of a piconet fully
identify the frequency-hopping sequence and phase of the channel used in the piconet. Since
communication between a slave and a master can occur only within a piconet, it follows that each
slave in a piconet must know the master's clock and BD_ADDR. Alternatively, for a potential
master to efficiently invite a potential slave, it needs to know the slave's clock and address. The
exchange of address and clock information between devices occurs during inquiries, when the
master collects operational information about the prospective slaves, and during pages, when the
master communicates to a slave its own operational information. The operational information of a
device, which includes its BD_ADDR and clock value, is sent in a frequency-hopping sequence
(FHS) BB_PDU described in detail later in this chapter.

Assuming that the fundamental elements (address and clock) of the devices involved are known,
the connected state is highlighted first in the next section. The inquiry and page states are
presented afterward.

The Connected State

While in the connected state, devices can exchange data under the control of the master that
defines which device transmits when. To maintain piconet synchronization, each slave adds an
offset to its native clock that accounts for the difference of its own clock from that of the master.
Thus, the clock of the master becomes the regulator of timed events in the piconet. In addition,
the LAP of the master is used for the access code generation.

With a common clock reference among all devices in a piconet, the transmission time on the
piconet is divided into master and slave transmission slots. A master starts its transmissions on
even-numbered slots (c 1 = 0) exclusively. Likewise, a slave starts its transmissions on odd-
numbered slots (c 1 = 1) exclusively. A particular slave transmits if and only if the last master
transmission was destined exclusively to this slave. Thus, the medium access protocol for
Bluetooth communications is a packet-based, time-division duplex (TDD)[7] polling scheme.

61
Typically, master and slave transmit slots alternate every 625 µsec, the residence time at a
frequency, although as mentioned earlier, multi-slot transmissions are possible. However, multi-
slot transmissions are limited to an odd number of slots (one, three or five), which guarantees
that master transmissions always start on even slots and slave transmissions on odd slots.
[7]
TDD refers to a time-division multiplexing technique where the transmission time on a single communication channel is
divided into successive, non-overlapping intervals, every other of which is used for transmissions in one of two opposing
directions. The transmission direction alternates between the two directions with each successive interval.

Figure 6.9. The BB_PDU format.

Baseband BB_PDU Types

Figure 6.9 depicts the general format of a BB_PDU transmitted on a piconet. No frequency hops
occur during a BB_PDU transmission and at most one BB_PDU is transmitted during the residence
time at a frequency. Over-the-air transmissions start with the LSB and proceed to the MSB (little-
endian transmission ordering). Every BB_PDU transmitted starts with the access code that, for
the discussion here, serves as the piconet identifier, thus filtering out transmissions that might be
received from other piconets (see Figure 6.8). The access code typically is 72 bits long, which
includes a 4-bit trailer field. If the BB_PDU does not contain a header (and hence a payload), the
trailer is not used and the BB_PDU consists of the 68-bit access code only. The 68-bit BB_PDUs
are used exclusively for transmitting inquiries or pages as described in the corresponding sections
later in this chapter.

The header of the BB_PDU contains link control data to aid medium access control. The header
contains a mere 18 bits of information for low overhead, but it is encoded with a forward error-
correcting(FEC) code with rate 1/3 for high transmission reliability. In particular, every bit of the
header is transmitted three times in sequence. Table 6.4 summarizes the fields of BB_PDU
header.

Table 6.4. The baseband BB_PDU header.

Field Size Comments
name
AM_ADDR 3 active member address assigned to an active slave when devices exchange
bits paging information, such as during the paging of a device
TYPE 4 defines 16 BB_PDU/payload types
bits
FLOW 1 bit stop/go flow control switch set by a receiving device in its response to the
sender
ARQN 1 bit used for acknowledging successfully transmitted BB_PDUs; BB_PDUs for which
an acknowledgement is not received are retransmitted
SEQN 1 bit simple (odd/even) sequence number for filtering duplicate transmissions
HEC 8 header error check (HEC) generated by the generator polynomial G HEC(x) =x
8
bits +x7+x5+x2+x+1

62
During the paging process, the master assigns a 3-bit active member address (AM_ADDR) to the
new slave. AM_ADDR takes on the values 1 through 7 and it is unique for each active slave in a
piconet. The reserved value of AM_ADDR = 'b000' is used to signify broadcast transmissions from
the master to all the slaves in a piconet.[8] The AM_ADDR is included in the same FHS BB_PDU
sent by the master to the slave that also contains the master's address and clock information.
[8]
Due to the TDD polling scheme used for medium access control in a piconet, only the master can directly broadcast data to
the other piconet members (its slaves). Slaves in a piconet can only unicast (a point-to-point transmission) to the master of the
piconet.

The various BB_PDU types are distinguished by their roles: purely signaling or payload-carrying
packets; their link designation: asynchronous connectionless (ACL) data or synchronous
connection-oriented (SCO) data; their size: 1, 3 or 5 slots; and their FEC encoding: no FEC, 2/3
rate FEC encoding, and 1/3 rate FEC encoding. The 2/3 rate FEC is a (15,10) shortened Hamming
code generated by the generator polynomial G FEC(x) = x 5 + x 4 + x 2 + 1.

The HEC is implemented through an 8-bit linear feedback shift register (LFSR) circuit whose initial
value is UAP[0:7] of the master of the piconet. Hence, even in the case where transmissions from
multiple masters with overlapping LAPs (thus generating the identical access code as shown in
Figure 6.8) were accepted, the corresponding BB_PDU would be rejected because the BB_PDU
header would fail its header error check. In other words, both the LAP and the UAP of the master
of a piconet are needed to fully identify and accept a BB_PDU transmission on the piconet.

The link control packets include:

• the ID packet, used in inquiries and pages, that consists of only the access code;
• the NULL packet that is used primarily for slave acknowledgment and flow control
information transmission when the slave does not have anything else to transmit (NULL
packets themselves are not acknowledged);
• the POLL packet that is sent from a master to a slave to poll it for a transmission when the
master does not have any payload information to send to the slave (the POLL packet
requires a response); and
• the FHS packet used in inquiries and pages.

The ACL packets are designated as D(M H)(1 3 5), where "DM" stands for medium speed data
that use a 2/3 FEC encoding for the payload; "DH" stands for high speed data where no FEC is
used for the payload. The size qualifier 1, 3 or 5 refers to the number of slots occupied by the
packet. For multi-slot packets, the frequency does not change until the packet finishes its
transmission. The next frequency to be used is the one that would have been used if single-slot
transmissions were used in the meantime instead. Note that the size of an ACL packet is odd
because a master's transmission must always start at even-numbered slots while slave
transmissions must start at odd-numbered slots. Using five-slot packets in one direction and one-
slot packets in the opposing direction, the maximum achievable rate for ACL traffic is 723.2 Kbps
in the first direction and 57.6 Kbps in the opposite direction.

Knowledge of the type of a BB_PDU and hence its size facilitates power conservation in a slave.
In particular, as a slave in a piconet inspects an incoming transmission and finds that the
transmission is not intended for that slave (that is, its AM_ADDR does not match the address in
the BB_PDU header), the slave could go to "sleep" for a duration of time dictated by the packet
type field.

The SCO packets are one slot long and are designated as HV(1 2 3). All three variants can
support 64 Kbps in each direction over periodically reserved slots using different encoding for the
payload data. In particular, HV stands for high-quality voice, and the encoding qualifier 1, 2 or 3
refers to the encoding used for the payload data:

63
 • 1 is for 1/3 rate FEC; a device transmits a single-slot packet every 2 slots
• 2 is for 2/3 rate FEC; a device transmits a single-slot packet every 4 slots
• 3 is for no FEC; a device transmits a single-slot packet every 6 slots

In addition to the above packet types there is a DV packet that combines both ACL, with 2/3 FEC,
and SCO, with no FEC, data in a single-slot packet. A device could transmit a DV packet every 2
slots.

Figure 6.10 depicts the low-level baseband operations that occur during the transmission and
reception of baseband packets. Note that different operations take place for the packet header
versus the payload; the operations for the header and the payload occur serially rather than in
parallel as the figure might imply. In the figure, whitening refers to the process of scrambling the
transmitted data to randomize them and to reduce the DC bias in the transmitted data. The data
are whitened through the use of the whitening word generated by the polynomial G WHITE (x) = x 7
+ x 4+1. Security features in Bluetooth piconets, including device authentication and link
encryption, are discussed in the following LMP section. The CRC operation pertains only to ACL
packets, detailed immediately below.

Figure 6.10. Low-level baseband operations during transmission and reception of

baseband packets.

Asynchronous Connectionless (ACL) Packets

The payload portion of the DM packets and the ACL portion of a DV packet is further structured
with its own ACL packet header and payload along with a two-byte cyclic redundancy check(CRC)
field. Table 6.5 summarizes the fields of the ACL packets, from the LSB to MSB.

Table 6.5. The ACL packet format.

Field Size Comments
name
L_CH 2 bits 'b00': not defined
(logical
channel)

64
 Table 6.5. The ACL packet format.
Field Size Comments
name
'b01': continuation
segment of an
L2CAP PDU
'b10': start of an
L2CAP PDU
'b11': LMP PDU

FLOW 1 bit for flow control on the ACL link

LENGTH (5 9) length of ACL payload in octets (excludes header and
bits CRC) for either single- or multi-slot packets in the case
of a 9-bit length field, a 4-bit undefined padding is used
to make the header an integer multiple of bytes (2
bytes total)
Payload 0–339 ACL packet payload spanning 1 to 5 slots
bytes
CRC 2 the cyclic redundancy check protects the payload and is
bytes generated by the CRC-CCITT generator polynomial G
16
CRC(x) = x + x 12 + x 5 +1

There is one extra one-slot ACL packet, AUX1, which does not contain a CRC. The use of this
packet is not defined in the specification. Possibly, it could be used for testing and development
purposes; however, it is outside the scope of the version 1.0 specification and this discussion.

The Baseband Link Types

As mentioned earlier, the Bluetooth baseband supports two types of links over a piconet. ACL
links are used for carrying asynchronous data. The master schedules asynchronous transmissions
in slots not already reserved for synchronous (SCO) transmissions. In other words, SCO traffic is
of high priority and cannot be preempted for asynchronous transmissions. For each and every
slave in its piconet, a master establishes exactly one ACL link that represents a physical pipe
between the master-slave pair over which ACL data are exchanged. Point-to-point ACL BB_PDU
exchanges are all acknowledged and retransmitted as appropriate. Broadcast (AM_ADDR =
'b000') ACL transmissions from a master to its slaves are not acknowledged but may be repeated
several, N BC, times for increased reliability. Note that, since it is impossible for multiple slaves to
acknowledge a transmission simultaneously, it is also impossible to acknowledge a broadcast
transmission. In particular, there exists no simple and reliable method to dynamically designate a
single slave to acknowledge on behalf of all slaves in the piconet that the broadcast transmission
has been successfully received by all slaves.

SCO links carry telephony-grade voice audio through a priori periodically reserved pairs of slots.
In a piconet, following a request from a slave or the master, a master may establish up to three
SCO links in total between it and all of its slaves. Each SCO link represents a physical pipe
between the master and one of its slaves over which SCO data are exchanged. To maintain the
high quality of service expected for SCO traffic, the length of the baseband slot, 625 µsec, is
selected to minimize the packetization delay for audio traffic and the effects of noise interference.
For example, an HV1 BB_PDU carries the equivalent of 10 bytes of audio information, which at
8,000 samples per second and 8 bits per sample takes 1.25 msec (=2*625 µsec) to accumulate.

65
This is the same as the period of transmissions of HV1 BB_PDUs from a device. Unlike ACL
transmissions, SCO BB_PDUs are not acknowledged. Note that prior to establishing an SCO link,
an ACL link must already exist to carry, at a minimum, the SCO connection control information.

Bluetooth links between devices can be authenticated, encrypted, operated in low-power mode,
and in general, qualified based upon application or user requirements. The operation of the
baseband in these cases is highlighted in the following link manager protocol section since it is
link manager involvement that initiates these sorts of changes in link behavior.

For communication in a piconet to occur, a slave needs to know its master's clock and address.
The following sections discuss the inquiry and page mechanisms by which this information is
acquired. As Figure 6.4 shows, this two-step process can be trimmed to one step when
connecting to known devices.

Inquiry State
The purpose of device inquiries is to collect information about other Bluetooth devices in
proximity. This primarily involves obtaining their fundamental elements: BD_ADDR and clock
value. The inquiry state is composed of several substates executed by "potential" masters and
slaves. These are the inquiry substate executed by a potential master and the inquiry scan and
inquiry response substates executed by a potential slave. In the inquiry substate, a master[9]
transmits inquiry packets, which are received by slaves in the inquiry scan substate. The latter
devices then enter the inquiry response substate and schedule the transmission of their
fundamental elements to the master.
[9]
For brevity, the qualifier "potential" for masters and slaves will be omitted unless it is required for clarifying the context.

While in the various inquiry substates, devices utilize the inquiry-hopping sequence to transmit
and receive packets. The inquiry packet sent by an inquiring master is a BB_PDU that contains
only an appropriate IAC, typically the GIAC, as described in the preceding section on access
codes. This packet is referred to as the inquiry ID packet. The inquiry ID packet simply notifies
slaves that a master is looking for slaves.

In responding to an inquiry, a slave transmits an FHS packet containing, among other

information, the slave's BD_ADDR and clock value at the time of transmission of the FHS packet.
Table 6.6 depicts the contents of the FHS packet. Since either a master or a slave can send an
FHS packet,[10] the fields in the FHS packet are interpreted with respect to the device that sent
the packet. The fields and the bits within them are provided in the transmission order from the
LSB to the MSB.
[10]
A master sends an FHS packet during a page operation as described in the following section.

Table 6.6. The FHS packet.

Field name Size Comments
parity bits 34 used for building the device access code (DAC) for paging the device
bits sending this packet
LAP 24 the lower address part of the BD_ADDR of the device sending this
bits packet
Reserved 2 set to 'b00'
bits
Paging interval 4 two 2-bit subfields defining the period of the successive page scans and

66
 Table 6.6. The FHS packet.
Field name Size Comments
parameters bits the duration of the mandatory page scan period for the device sending
this packet
UAP 8 the upper address part of the BD_ADDR of the device sending this
bits packet
NAP 16 the non-significant address part of the BD_ADDR of the device sending
bits this packet
CoD 24 class of device field containing information regarding the device
bits sending this packet
AM_ADDR 3 for inquiry responses, it is set to 'b000'; for a master response
bits following a page response by a (potential) slave, it is set to the active
member address assigned to the new active slave
CLOCK[2:27] 26 the current time (updated with each retransmission of the packet) of
bits the Bluetooth clock of the device sending this packet
Page scan mode 3 the default page scan mode of the device; one mandatory page scan
bits mode and up to three optional ones are supported in version 1.0

The header of the BB_PDU carrying the FHS packet as payload has the AM_ADDR field set to
'b000' without meaning that this is a broadcast packet. The FHS packet is protected by a 2-byte
CRC and encoded with an FEC with rate 2/3. The size of the FHS packet is 240 bits of payload
and 126 bits of packet header and access code.

The operations of a master, the inquiring device, and a slave, the listening device, are highlighted
in Figure 6.11. The numbers shown in the figure are typical numbers, which can be changed
through intervention from applications as needed.

In summary, a master transmits its inquiry ID packets on different frequencies of the inquiry-
hopping sequence, changing the transmission frequency rapidly in the hope of transmitting as
soon as possible on one of the frequencies that slaves are listening to. This would ultimately
happen, given enough time, as slaves performing inquiry scans change their listening frequency
from the inquiry-hopping sequence at a much slower rate. Since a master does not know when a
slave listens for inquiries, the master repeats its inquiry transmissions a number of times. When
"contact" finally occurs, the slave responds with its FHS packet that includes vital paging
information. SCO transmissions scheduled in any of the inquiring or listening devices take
precedence over the inquiry procedures. A device will forego an inquiry action to transmit and
receive scheduled SCO packets.

The inquiry-hopping rate is 3,200 hops per second, double the nominal frequency-hopping rate.
The master will transmit and listen for responses over 16 different frequencies of the inquiry-
hopping sequence (train A in Figure 6.11) over a period of 10 msec (8 transmit and 8 receive
slots alternating with each other). If an insufficient number of responses is gathered, the master
will repeat the same process over the same set of 16 frequencies at least 256 times, or 2.56
seconds. Following this interval and assuming operation in a 79 channel country, the master may
also search through the remaining 16 frequencies of the inquiry-hopping sequence (train B in
Figure 6.11) an additional 256 times. The whole inquiry process may then be repeated from the
beginning.

67
Figure 6.11. Fast frequency scanning for inquiries in a 79 channel country; f t[.]I
denotes the master transmit frequencies from the inquiry-hopping sequence.

To avoid collisions from multiple slaves responding to the same inquiry ID packet, a rare event in
its own right, a back-off mechanism is used and it works as follows. Upon receipt of an inquiry ID
packet, the slave enters the inquiry response substate. It then randomly selects a number RN (
1,023) and suspends its inquiry response operations for at least that many slots; the slave may
move into the standby, connected or page states as necessary. When the slave resumes the
inquiry response substate, it will respond with an FHS packet following the first inquiry ID packet
it receives again. The detailed description of the inquiry procedures can be found in section 10.7
of the Baseband part of the specification.

Responding immediately after receiving an inquiry ID packet is not prudent, as the master may
not have switched to the mode in which it listens for responses. To guarantee that this does not
occur, the slave responds with its FHS packet 625 µsec after the receipt of the inquiry ID packet,
as shown in Figure 6.12. The figure shows two slaves, noted as i and j, responding to inquiry ID
packets. Slave I heard the inquiry ID packet in the first half of a master transmit slot. Slave j
heard the inquiry ID packet in the second half of a transmit slot from the master. In either case,
even though the slave is unaware exactly when the master will switch to the proper listening
frequency, it is guaranteed that the corresponding FHS packet from a slave is sent at the right
transmit frequency at the time that the master is listening at that same frequency.

68
 Figure 6.12. Inquiry transmission sequences; f r[.]I denotes the master receive
frequencies from the inquiry-hopping sequence corresponding to f t[.]I.

Note that the inquiry ID packet is 68 µsec long and it is transmitted twice over two different
frequencies within a 625 µsec time interval. Therefore, closely observing the figure, one may
deduce that the transmit frequency synthesizer has 244.5 µsec in which to switch to a new
frequency. Actually, accounting for a ±10 µsec tolerance for clock drift, the synthesizer must
settle to a new transmit frequency within 224.5 µsec. Admittedly this number is large compared
to state-of-the-art synthesizer design. However, it allows the use of less complex and less precise
circuitry that results in the desired low cost system design point. For more information on this
subject, see [Haartsen00].

Page State
The purpose of a device page is to invite a specific paged device to join a piconet whose master is
the paging device. The paging device uses the paged device's BD_ADDR and clock estimate to
send its pages as discussed earlier. The page state is composed of several substates executed by
potential masters and slaves. These are the page and master response substates executed by a
master and the page scan and slave response substates executed by a slave.

In the page substate, a master transmits page BB_PDUs, which are received by the slave when it
is in the page scan substate. The paging transmission contains only the slave's DAC. This
BB_PDU is referred to as the slave ID packet. In its page response, the slave also sends the slave
ID packet that simply notifies the master that the slave has received the page. Finally, the
master enters the master response substate during which the master transmits to the slave its
fundamental elements and the slave's AM_ADDR, which allows the slave to join and participate in
communications in the master's piconet. These fundamental elements and AM_ADDR are
transmitted within an FHS packet (see Table 6.6). The slave responds with one more slave ID
packets, and then enters the connected state and readies itself to start piconet communications.

The operation of the master and the slave in the page and page scan substates, respectively, is
quite similar to that of the inquiry and inquiry scan operations discussed earlier. In particular, the
illustration of Figure 6.11 for inquiries can also be used for pages as well by replacing the terms
related to inquiries with corresponding terms related to pages. The typical value for TpageScan is
1.28 seconds; subsequently, the typical value for Npage is 128. These typical values correspond to
the so-called R1 paging mode. The paging mode, and hence the corresponding parameters
TpageScan and Npage, are communicated to the master during the slave FHS transmission in an
inquiry, or during link manager information exchange during regular communications.

69
For a 79-channel country, trains A and B contain 16 frequencies each from the page-hopping
sequence, while for 23-channel countries there is only one train containing all 16 frequencies. In
the former case, train A contains the 16 frequencies closest to the frequency on which the slave
listens for pages as estimated by the master using its knowledge of (the estimate of) the slave's
native clock. Train B contains the remaining frequencies from the page-hopping sequence. Yet,
since train B is used 1.28 seconds after transmitting pages on frequencies from train A, the
master knows that the frequency on which the slave listens will also move by one. Hence, trains
A and B have one common frequency. For example, if train A contains frequencies f t[0]P through
f t[15]P, then when train B is used, it will contain frequencies f t[17]P through f t[0]P, in that order.
A device that performs page scans in the R1 paging mode can be located within no more than
1.28 seconds most of the time. When the estimate of the slave's native clock deviates more than
–8*1.28 seconds or +7*1.28 seconds from the actual value of the slave's clock, the search time
can be as much as twice the nominal value, or 2.56 seconds.

The sequence of transmissions during paging operations is summarized in Figure 6.13, where a
master pages a slave denoted as i. Following the paging operation, the slave shall be able to
participate in piconet communications. Hence, the slave not only needs to learn about the
master's BD_ADDR and clock value but also must have an AM_ADDR assigned to it and must
know exactly when a master transmit slot starts. The AM_ADDR is included in the FHS packet
transmission to slave i. The time of transmission of this packet is used to identify the start of the
master transmit slots in the piconet. The master transmits its FHS packet to slave i at the
beginning of its transmit slot, regardless of whether the slave sends its previous slave ID packet
in the first or second half of the slot during which the master listens for the slave response to its
pages. In the example of Figure 6.13, since the master receives the slave response to the
master's pages in the second half of the master's receive slot, the master transmits the FHS
packet 312.5 µsec after it receives the slave ID packet. Thus, by the time that the slave receives
and processes the FHS packet, the slave has all the information needed to participate in the
piconet communications, starting with a master transmission 1.25 msec from the start of
reception of the FHS packet.

Figure 6.13. Page transmission sequence. f t[.]P and f r[.]Pdenote the

corresponding master transmit and receive frequencies, respectively, from the
page-hopping sequence and f t[.]C denotes a master transmission frequency from
the channel-hopping sequence.

As with inquiries, SCO transmissions scheduled in any of the paging or paged devices take
precedence over the paging procedures. A device will forego a page action to transmit and

70
receive scheduled SCO packets. This case is not elaborated further here. The detailed description
of the page procedures can be found in section 10.6 of the Baseband part of the specification.

71
The Link Manager and Link Manager Protocol
Link manager entities, or simply link managers, in communicating devices exchange messages to
control the Bluetooth link between those devices. The communication protocol between link
managers is called the link manager protocol(LMP) and the messages exchanged between
communicating link managers are noted as LMP_PDUs. Figure 6.14 summarizes the functions of a
link manager. LMP does not carry application data. Based upon control data it receives from
higher layers, LMP either communicates with the link manager in another device using LMP_PDUs
or it sends control signals to its own device's baseband and radio layers. It should be noted that,
contrary to baseband processes that are executed in real time, link manager interactions are not.
Albeit infrequently, communicating link managers may take up to 30 seconds to react to each
other's requests.

Figure 6.14. The link manager functions.

As discussed earlier (see Table 6.5), LMP_PDUs are carried in the payload of ACL packets whose
header has an L_CH field with the value 'b11'. LMP_PDUs are transmitted on single-slot DM1
packets or on DV packets. LMP_PDUs have very high priority and, if needed, they can preempt
even an SCO transmission to transmit control information to another device. Table 6.7
summarizes the LMP_PDU packet format; note that LMP_PDU packet format.

Table 6.7. The LMP_PDU format.

72
Field name Size Comments
transactionID 1 bit 'b0': identifies link manager transaction
initiated by the master
'b1': identifies link
manager transaction
initiated by a slave
OpCode 7 bits identifies the LMP_PDU and the type of
contents it carries
payload 0–17 the LMP_PDU fits in DM1 BB_PDU; if the
bytes LMP_PDU payload is less than 9 bytes then,
when supported, DV BB_PDUs may also be
used

When a link manager in a device initiates an LMP_PDU transaction with the link manager in
another device, the latter link manager will respond with the next LMP_PDU in the transaction
sequence (for example, respond with the requested information). Alternatively, the receiving link
manager responds with an LMP_accepted or LMP_not_accepted PDU that signifies whether the
link manager request from the transaction initiator is or is not accepted, respectively. When an
LMP_not_accepted PDU is sent, the reason for not accepting the transaction is provided.

Figure 6.15 shows two typical types of LMP_PDU transactions. In the first, either one of the
communicating link managers initiates a transaction with a request. The receiving link manager
either will accept the request and act accordingly (perhaps providing the requested information)
or will reject the request with an LMP_not_accepted PDU. It might also send its own
corresponding request LMP_PDU initiating a negotiation phase for the original request. In the
second transaction type, the master sends a command to be executed by the slave in an
LMP_PDU, without the opportunity for the slave to reject the command or negotiate its
parameters. An example of the latter case is forcing a slave to go into a power-saving mode, like
the hold mode, or requesting a link detachment, which is the only operation that a slave may also
force on a master.

Figure 6.15. Typical LMP_PDU transactions: (a) a request/response transaction and negotiation;
(b) master demands link adjustment.

73
There are many link manager transactions from a simple device name exchange to elaborate
authentication and encryption transactions, but not all of them are mandatory. However, the
receiving link manager must be able to respond to all link manager transaction requests, even if
the response is an LMP_not_accepted PDU, with the reason for non-acceptance being "feature not
supported." The following sections focus on a few of the more important link manager
transactions. The interested reader can find a more detailed presentation in the LMP part of the
specification.

Security Management
Security has been part of the specification from the outset of its development. It was recognized
early on that in ad hoc, wireless, and especially RF environments security is of paramount
importance.

The baseband defines security algorithms and procedures needed to authenticate devices, and if
needed to encrypt the data flowing on the link between them. Section 14 of the baseband part of
the specification includes algorithms for the generation of authentication and encryption keys and
the operations for verifying the authenticity of a device. Even though security is presented mostly
in the baseband part of the specification, it is discussed here in the link manager section, since it
ultimately relates to the configuration of a link between devices, the responsibility for which lies
with the link managers.

Device authentication is a mandatory feature supported by all Bluetooth devices. Link encryption
is optional.

Device Authentication

Authentication of Bluetooth devices is based on a challenge-response transaction. In this

transaction, a verifier challenges a claimant by sending to the latter a 16-byte random number in
an LMP_au_rand PDU. The claimant operates on the random number and returns the result of the
operation to the verifier in an LMP_sres PDU. If the result is the one expected by the verifier, the

74
verifier considers the claimant an authenticated device. Optionally, the two devices may then
exchange their roles as verifier and claimant and perform authentication in the opposite direction.

The above procedure occurs when the two devices have a common link key, which is used to
operate on the random number. A device may maintain identical or separate link keys for every
other device that it wants to authenticate. If a link key does not exist for a device, when an
LMP_au_rand PDU is sent, the claimant will respond with an LMP_not_accepted PDU, giving the
reason that the key is missing.

When a link key is missing, the devices need to be paired first. With the pairing process, an
initialization key is generated and used to authenticate the devices and eventually to create a
permanent link key for them. The initialization key is generated by entering a common personal
identification number (PIN) in both of the pairing devices, which generates a temporary key. Note
that neither keys nor the PINs that generate them are ever sent in clear form over the air. Using
the temporary key generated by the PIN, the two devices may proceed with the authentication
process as if they had a link key. The only difference is that pairing is initiated using an
LMP_in_rand PDU instead of the LMP_au_rand PDU. Certain devices without a user interface may
have a fixed, non-changeable PIN. In this case, the PIN entered in a device with a user interface
must match this fixed PIN; otherwise authentication is not possible.

Authentication of Bluetooth devices depends upon a shared secret. Commonly used public key
and certificate schemes are not appropriate for ad hoc networks of personal devices. These other
schemes require the support of trusted authentication agencies and other third-party means of
communication that cannot be assumed to be available in ad hoc networks. Authentication keys
are 128 bits long and are constructed using the PIN (only for the initial authentication), a 128-bit
random number, and a device's BD_ADDR.

Bluetooth devices may store link keys for future authentication without the need to enter a PIN
each time. The two primary types of link keys are the unit keys and the combination keys. The
former are derived from input parameters available in only one device, while the latter are
derived by combining input parameters available in each of the two devices. The use of
combination keys is preferred, as it provides for a stronger "bonding" between pairs of devices; a
device must store a separate combination key for each other device it wants to authenticate
using a stored link key. However, devices of limited storage capacity may store and use just a
single link key for authentication of other devices.

Link Encryption

To protect the privacy of the data flowing over a Bluetooth link, the link can be encrypted.
Encryption in Bluetooth wireless technology is based on a 1-bit stream cipher, whose
implementation is included in the specification. The size of the encryption key, which changes
with each BB_PDU transmission, is negotiable to match application requirements.

The encryption key is derived from the link key used to authenticate the communicating devices.
This implies that prior to using encryption two devices must have authenticated themselves at
least once. The maximum key size is 128 bits, but regulatory authorities in various countries may
limit the permissible maximum key size. Encryption applies only to the payload of BB_PDUs and it
is symmetric, in that both directions of communication are encrypted. Encryption is a link
property in that both SCO and ACL packets over this link are encrypted.

A request for encryption starts with the LMP_encryption_mode_req PDU with an encryption mode
parameter that distinguishes encryption of a link between two devices (point-to-point
encryption), or encryption of broadcast packets as well. In the latter case, a master key is
created that is to be used for encryption by multiple devices in the piconet. If the request for
encryption is accepted, the devices then negotiate the size of the encryption key exchanging
75
LMP_encryption_key_size_req PDUs. If the negotiation succeeds, the devices can initiate
encryption by sending an LMP_start_encryption PDU. Encryption starts by: (a) the master
becoming ready to receive encrypted data; (b) a slave becoming ready to transmit and receive
encrypted data; and (c) the master becoming ready to transmit encrypted data.

Power Management and Power-Managed States

Devices in a connected state can regulate their association with the piconet(s) to which they are
connected to preserve power or to attend to other business such as participation in a scatternet.
There are three low-power modes: sniff, hold, and park; all are optional.

Apart from modifying the property of the link between devices, a device optionally may request
its communicating partner to adjust its transmission power depending on the quality of the link,
as measured by the received signal strength of incoming transmissions. Power control for this
case is discussed in Chapter 2 and is not discussed further here.

Sniff Mode

Typically a slave must listen at the beginning of each even-numbered slot to see whether the
master will transmit to the device. In the sniff mode, a slave may relax this requirement for its
ACL link. The master will transmit to the slave at a reduced duty cycle by starting its
transmissions every T sniff slave listening opportunities (master transmit slots). In particular
every, say, T sniff[j] listening opportunities, slave j will listen for N sniffAttempt [j] slots for a
transmission to it. If data is received, the slave will continue listening until the transmissions
stop. The slave will continue listening for an additional N sniffTimeout [j] listening opportunities for
additional transmissions to it. While a slave is in the sniff mode, any ongoing SCO transmissions
will still occur as scheduled.

A master may force a slave into sniff mode with an LMP_sniff PDU. Alternatively, a master or a
slave may request that the slave enter into sniff mode with an LMP_sniff_req PDU. Both of these
LMP_PDUs carry the timing parameters defining the slave operation in sniff mode. These
LMP_PDUs also carry an offset parameter D sniff that determines the time of the first sniff
instance. Subsequent sniff instances are separated by the period T sniff. In the case of a request to
enter the sniff mode, the master and the slave may negotiate the timing parameters for this
mode.

Hold Mode

While sniff mode communications are periodic, in hold mode ACL communications with a slave
are suspended in single installments for a time interval referred to as the hold time. While a slave
is in hold mode, any ongoing SCO transmissions will still occur as scheduled.

A master may force a slave into hold mode with an LMP_hold PDU. Alternatively, a master or a
slave may request that the slave enter into hold mode with an LMP_hold_req PDU. Both of these
LMP_PDUs carry the initial value of the hold time. In the case of a request to enter the hold
mode, the master and the slave may negotiate the timing parameters for this mode.

Park Mode

In the sniff and hold modes, a slave is still considered a fully qualified active member of the
piconet and as such it maintains its AM_ADDR that was assigned to it when it joined the piconet.
Note that while in these two modes, SCO transmissions with the slave are not interrupted.

76
To further reduce power consumption during periods of no activity, a slave may enter the park
mode during which it disassociates itself from the piconet, while still maintaining timing
synchronization with the piconet. By doing so, it can rejoin the piconet relatively quickly without
having to perform inquiry and paging procedures.

A slave that enters the park mode gives up its AM_ADDR. On the other hand, to manage its fast
and orderly readmission to the piconet, the master assigns to the slave two temporary 8-bit
addresses, the parked member address (PM_ADDR) and the access request address (AR_ADDR).
PM_ADDR is used to distinguish up to 255 parked devices (actually, slaves); the address '0x00' is
a reserved PM_ADDR. Parked devices could be recalled using their 48-bit BD_ADDR if needed,
but the use of the much shorter PM_ADDR allows for increased efficiency in recalling multiple
parked devices.[11] AR_ADDR is used in scheduling the order of readmission of parked devices in a
way that minimizes the possibility of collisions.
[11]
When the value of PM_ADDR = '0x00'; is assigned to a device, this device can only be unparked using its BD_ADDR. This
could be the case when there are at least 255 parked devices in a single piconet, which is a rather exceptional case.

To maintain synchronization with the piconet and to facilitate the readmission of parked devices
in the piconet, the master defines a low-bandwidth beacon channel, which consists of the periodic
transmission of broadcast packets. Prior to entering park mode, slaves are notified of the timing
parameters of the beacon transmissions, and thus they know when they can wake to receive
possible transmissions from the master. Beacon transmissions destined to the parked stations are
broadcast transmissions (BB_PDUs with AM_ADDR = 'b000'), for the simple reason that parked
devices don't have an AM_ADDR and thus they cannot be addressed explicitly.

The timing parameters for beacon intervals are numerous. They include an offset parameter
denoting the time of the first beacon transmission and the period of the beacon instances. They
also include the broadcast repetition parameter, the interval following a beacon instant before the
master gives the opportunity to parked devices to request to rejoin the piconet, the length of
time that the master will continue giving this opportunity, and so on.

Just as in the sniff and hold modes, the master may force a slave into park mode with an
LMP_park PDU. Alternatively, a master or a slave may request that the slave enter into park
mode with an LMP_park_req PDU. When a slave is to rejoin the piconet, the master broadcasts in
the beacon slots an LMP_unpark_BD_ADDR_req or an LMP_unpark_PM_ADDR_req PDU,
depending upon whether the parked device is addressed with its 48-bit BD_ADDR or its 8-bit
PM_ADDR. Multiple parked devices can be invited with a single unpark LMP_PDU. In the unpark
LMP_PDUs, the master also includes the new AM_ADDR to be assigned to the parked device when
it rejoins the piconet as a slave. Note that a parked device cannot be invited to rejoin a piconet
when there are already seven active slaves in the piconet. In the latter case, the master may
have to park some active devices and free the corresponding AM_ADDRs prior to unparking a
parked device.

Bandwidth-Conscious Communications
Bluetooth devices have several options available for managing the bandwidth that is allocated
between them. As mentioned earlier, devices may use SCO links whose high-priority periodic
transmissions provide for telephony-quality voice communications. Transmissions on ACL links
can also be provided with bandwidth guarantees through polling interval restrictions. Support for
SCO links is optional, while support for ACL polling interval transactions is mandatory.

Furthermore, to increase the efficiency of the transmission and thus increase the bandwidth
supported on an ACL link, link managers may negotiate the use of larger BB_PDUs. Support for
this link manager transaction is mandatory; the actual use of larger BB_PDUs needs to be
coordinated with additional LMP transactions described below. Finally, devices may dynamically

77
change the encoding schemes of the transmissions to take better advantage of the link quality
conditions. Support for this link manager transaction is optional. The latter two transactions are
not discussed further.

SCO Links

A piconet supports up to three SCO links for telephony-quality (64 Kbps) voice communications.
SCO packets transmitted on the SCO links are of high priority and can preempt any other activity
that the device may be involved with, like pages and inquiries, holds, and so on. A device
requests the establishment of an SCO link with an LMP_SCO_link_req PDU. This LMP_PDU
contains the audio parameters like the period T SCO, the SCO BB_PDU type and the air-mode,
which represents the voice codec type. Supported codec types are: 64 Kbps µ-law or A-law PCM
format, or 64 Kbps CVSD (continuous variable slope delta) modulation format. With such a high
resolution of voice traffic, cellular phone conversations carried to, say, a headset that is
connected with a cellular phone over a Bluetooth SCO link should not degrade in quality.

When the master responds positively to a slave's LMP_SCO_link_req PDU or sends its own
LMP_SCO_link_req PDU, it supplies the offset DSCO that identifies the time of the first
transmission for the new SCO link, and an SCO link unique identifier, or handle. Either the master
or the slave can subsequently request to change the parameters of the SCO link, using the
LMP_SCO_link_req PDU again, or to remove the link altogether, using an
LMP_remove_SCO_link_req PDU. The latter transactions make use of the SCO link handle to
identify the particular SCO link whose parameters or status is to be changed.

Quality of Service (QoS) for ACL Links

To control the minimum bandwidth assignment for ACL traffic between two devices, or
equivalently the maximum access delay of ACL BB_PDUs, the maximum polling interval [12] for a
slave can be adjusted as needed. A master can enforce a new maximum polling interval using an
LMP_quality_of_service PDU. In this case, the slave cannot reject the adjustment of the polling
interval determined by the master. On the other hand, a master or a slave may request a change
in the polling interval with an LMP_quality_of_service_req PDU. In this case, the request can be
either accepted or rejected by the other party.
[12]
Recall that a master polls a slave either explicitly through the use of a POLL BB_PDU or implicitly by simply transmitting any
payload carrying BB_PDU.

Both of these LMP_PDUs also carry the number of times, N BC, that each broadcast packet is to be
repeated. Since this parameter relates to the operation of the entire piconet, and not just to the
ACL link between a slave and the master, N BC is meaningful only when it is sent from the master.
When this parameter is included in a request LMP_PDU from a slave, it is ignored.

Link Controller Management

The transactions in this section apply to negotiation of parameters related to the link controller
and the baseband protocols, such as negotiation of the paging scheme, timing accuracy, master-
slave role switch and so on.

Paging Scheme

When two devices have already communicated with each other, they may subsequently
reconnect with each other more rapidly, since they can bypass the inquiry process. However,
during an inquiry response, a slave provides paging information to the master in an FHS packet.
When bypassing the inquiry process, this FHS packet is also bypassed. Thus, if a device has

78
modified its paging parameters, perhaps to switch to an optional paging scheme or to change its
T pageScan interval, the master will not become aware of the change.

With the paging scheme LMP_PDU transaction, devices can announce or even negotiate the
paging scheme to be used the next time these devices page each other. With an
LMP_page_mode_req PDU, the requesting link manager suggests to the other link manager the
paging scheme to be used when the requesting device pages the other. Likewise, with an
LMP_page_scan_mode_req PDU, the requesting link manager suggests to the other link manager
the paging scheme to be used when the other device pages the requesting device. Rejecting any
of these request LMP_PDUs implies that the current paging scheme is not to be changed.
However, a request to change to the mandatory paging scheme cannot be rejected. Support for
this transaction is optional.

Master-Slave Role Switch

A paging device becomes the default master of the resulting piconet, although circumstances
may necessitate that the roles of the master and the slave be exchanged. For example, such an
exchange is needed to implement the LAN access profile using PPP (described in Chapter 15). To
initiate the process of master-slave role switch, a device sends an LMP_switch_req PDU, which
upon acceptance will initialize the role switch. The switch basically comprises the process of
migrating from the master/slave transmit timing sequence in the piconet of the old master (the
new slave) to the master/slave transmit timing sequence in the piconet of the new master (the
old slave). Support for a master-slave role switch is optional.

Clock and Timer Information

A device can request updated clock information from another device to optimize various link
controller operations.

An LMP_clock_offset_req [13] PDU sent by a master results in a slave returning the most current
offset between the native clocks of the slave and the master as registered by the slave. This
information can be used to optimize the paging time when the master pages the slave again in
the future. Support for this transaction is mandatory.
[13]
The name of this LMP_PDU is actually LMP_clkoffset_req.

An LMP_slot_offset PDU carries with it the slot offset, in microseconds, between the start of the
time of a transmit slot from the master and the corresponding transmit slot from the slave, if the
slave were to be a master. This information is used to optimize a master-slave role switch.
Support for this LMP_PDU is optional.

An LMP_timing_accuracy_req PDU results in returning the long-term jitter, in microseconds, and

drift, in parts per million (ppm), of the receiving device's clock. This information is used to
optimize the wake time for a device after a long period of inactivity while still being associated
with a piconet, such as waking after hold mode, or waking prior to a master's transmission at a
sniff slot or a beacon slot for a parked device. Support for this LMP_PDU is optional; when it is
not supported the jitter and accuracy are assumed to be at their maximum value of 10 µsec and
250 ppm, respectively.

An LMP_supervision_timeout PDU sent by a master includes the link supervision timeout value
used by a link controller to detect the loss of a Bluetooth link between the master and a slave.
Support for this LMP_PDU is mandatory.

Information Exchange

79
Link managers typically exchange information about each other to better coordinate their
interaction. The LMP_version_req PDU contains the LMP version supported by the sender of this
PDU. The receiver of this LMP_PDU returns the LMP_version_res PDU which contains its own
supported LMP version. The version number is provided as a triplet
[versionNo:companyID:subVersionNo]. The version number part of the triplet is a version of LMP
as defined by the SIG. The subversion number is relative to a company that may have its own
particular implementation of the protocol. Support for this LMP_PDU transaction is mandatory.

The LMP_features_req PDU contains the optional radio, baseband, and link manager features
supported by the sender of this LMP_PDU. The receiver of this LMP_PDU returns the
LMP_features_res PDU, which contains its own supported features. These features include the
supported packet types, other than the mandatory FHS, NULL, POLL, DM1 and DH1; supported
power control modes, voice codecs, encryption, role switch, optional paging schemes and so on.
Support for this LMP_PDU transaction is mandatory.

With the LMP_name_req PDU, the requesting link manager requests the user-friendly name of
the device that receives this LMP_PDU. The user-friendly name is the name that a user of a
device assigns to it. Within a device a name is encoded in UTF-8 and it can be up to 248 bytes
long. Since the name of a device can be longer than a single DM1 packet, when a device requests
the user-friendly name of another device it also provides an offset parameter that the responding
device can use to transmit the proper segment of its name, using the LMP_name_res PDU.

The UTF-8 encoding [IETF96] for device names has been selected for its support of international
languages because the Bluetooth wireless technology is targeted for worldwide use. UTF-8
characters are encoded using sequences of 1 to 6 bytes. For compatibility with the widely used
ASCII character set, ASCII characters are encoded using a one-byte UTF-8 character, which has
the same value as the corresponding ASCII character. Hence, the user-friendly name of a
Bluetooth device can be up to 248 ASCII characters long.

Connection Establishment and Link Detachment

LMP is a transport protocol for control information between link managers in devices. LMP does
not encapsulate PDUs of any higher communication layer. As such, LMP transactions may occur
without involvement of any higher layer, such as L2CAP or the host itself. When a host
application in a device wants to communicate with one in another device, the first device sends
an LMP_host_connection_req PDU which the receiving device will either accept or not. If the
connection request is accepted, the two link managers will negotiate the parameters of the link,
like authentication and QoS. When link managers finish negotiating, each sends an
LMP_setup_complete PDU. Only after both link managers have issued the LMP_setup_complete
PDU can communication that does not involve LMP_PDUs commence between the devices.

When any device wants to terminate its link with another device, it issues an LMP_detach PDU
with a reason parameter explaining why the link is to be terminated. The LMP_detach PDU cannot
be contested and the link between the two devices will be terminated immediately.

Support for the LMP_PDUs in this section is mandatory.

80
Summary
In this chapter we have highlighted the lower Bluetooth transport protocols: radio, baseband, and
link manager. These protocols define the operational characteristics of the Bluetooth wireless
technology and instantiate the Bluetooth air-interface. Bluetooth devices use relatively high rate
frequency-hopping spread-spectrum transceivers operating over 79 (or 23) 1 MHz channels in the
2.4 GHz ISM RF band. Devices find others in their vicinity using inquiries and request connections
to those devices by explicitly paging them. Communicating devices are organized in piconets
composed of a master and one or more slave devices. Device transmissions are organized over a
TDD transmission time axis, with the slaves transmitting only when they have been first
addressed by the master. Bluetooth links between devices can support both asynchronous and
synchronous transmissions, and they can be authenticated, encrypted, and conditioned based on
QoS demands.

The next chapter presents the upper transport protocols, which aim to conceal the details of the
lower transport protocols from higher layers and applications. This allows the higher layers to use
the Bluetooth links in a manner that is agnostic of the way that connections and transmissions
between devices are organized and managed over the Bluetooth air-interface.

81
Chapter 7. The Upper Protocols of the
Transport Group
The lower transport protocols are optimized to deal with the hostility of the RF transmission
medium, user requirements for low cost and power consumption, security concerns, regulatory
issues, and so on. These design points have led to, among other things, selection of the TDD,
polling-based medium access protocol at the baseband. While this approach is suitable for
operation of Bluetooth systems in the 2.4 GHz ISM band, the small size of a BB_PDU does not
fare so well with the much larger packet sizes typically encountered with Internet and other
similar traffic.

It was thus recognized early on that an adaptation layer was needed to move larger upper-layer
PDUs and smaller lower-layer PDUs back and forth among the protocol stack layers. This
adaptation layer was originally called level 2 medium access control (MAC-2), at a time when
MAC-1 represented the medium access control protocol at the baseband level. But the name
MAC-1 never prevailed, and so MAC-2 did not apply either. It was therefore decided late in the
summer of 1998 to change the name from MAC-2 to a more descriptive one, and the name
logical link control and adaptation protocol (L2CAP) came into being. Incidentally, shortly after
the first L2CAP draft specification was produced in September 1998, a portion of that
specification was split out into its own independent document, spawning a brand-new activity in
the SIG. Specifically, the Bluetooth discovery protocol (BDP) section of the MAC-2 and early
L2CAP specifications grew in scope and resulted in the service discovery protocol (SDP)
specification highlighted in the next chapter. This chapter describes L2CAP, which is certainly one
of the most important layers in the stack.

In the reference implementation shown in Figure 6.1 in the previous chapter, the L2CAP layer[1] is
a software component that resides within a host. To permit L2CAP and higher protocol layers and
applications to transfer and receive control and application data to and from any vendor's
Bluetooth module in a standardized way, the SIG has developed a protocol that allows the host to
communicate to the module in an interoperable manner. This protocol is the host controller
interface (HCI), supplemented with a series of HCI transport protocols, which are mechanisms
used to transfer HCI data across various physical connectors, like USB ports, RS-232 ports, and
so on. This chapter also discusses HCI and its transport protocols.
[1]
This layer is more appropriately called "L2CA layer" or "L2CAL," but since L2CAP is phonetically more pleasing than either
L2CA or L2CAL, the technically inappropriate usage of the term "L2CAP layer" or even just "L2CAP" has tacitly prevailed. Here,
the use of the term "L2CAP" as a noun is reserved primarily for the protocol used to communicate between L2CAP layers in
different devices.

Figure 7.1 is a refinement of Figure 6.1 and depicts the placement of the transport protocols in a
reference implementation of a Bluetooth device. Note that the link manager and host I/O block in
Figure 6.1 has been separated into two logical components, which may nevertheless run on the
same firmware platform. The host controller interacts with both the host and the Bluetooth
module hardware and firmware components to transfer data between them. On the host side, the
HCI layer executes the HCI communications protocol to carry data to and from the module
(through the host controller) and the host itself.

82
 Figure 7.1. The transport protocol group placement in a Bluetooth
reference implementation.

The L2CAP Layer

The primary role of the L2CAP layer is to hide the peculiarities of the lower-layer transport
protocols from the upper layers. By doing so, a large number of already developed higher-layer
transport protocols and applications can be made to run over Bluetooth links with little, if any,
modification.

The L2CAP layer concerns itself only with asynchronous information (ACL packet) transmission.
Its packets, referred to as L2CAP_PDUs, are carried on ACL BB_PDUs whose L_CH field in the
payload header has the value 'b10', denoting the start of an L2CAP_PDU, or 'b01', denoting the
continuation of an L2CAP_PDU (see Table 6.5 in the previous chapter). Even though L2CAP_PDUs
are closely associated with ACL BB_PDUs, the lower transport protocol concepts of master, slave,
polling, frequency hopping sequences, native clocks, and so on are meaningless at the L2CAP
layer. The lower transport layers provide the equivalent of a packet interface to L2CAP over which
L2CAP sends and receives its data and control messages, but L2CAP and higher layers are
otherwise insulated from the lower transport protocols.

The L2CAP layer supports higher-layer protocol multiplexing, compensating for the lack of such
support at the lower transport layers. Furthermore, it facilitates the segmentation and
reassembly of larger-size, higher-layer packets to and from the smaller baseband packets. Since
no knowledge of BB_PDUs exists at the L2CAP layer, not to mention knowledge of their
transmission size, the L2CAP layer itself does not perform segmentation and reassembly of lower-
layer PDUs. However, it facilitates these operations by providing L2CAP_PDU length information
in its PDUs, allowing a reassembly engine to verify that it has reconstructed the PDU correctly.
Moreover, the L2CAP layer exports maximum-packet-size information to higher layers that
informs them of the largest packet size that L2CAP layers in other devices can handle. It is the
responsibility of the higher layer to fragment its information into packets that do not violate the
L2CAP maximum packet size.

In addition, the L2CAP layer supports the exchange of quality-of-service (QoS) information, which
aids in controlling the transmission resources in a way that supports the expected QoS. Finally,
the L2CAP layer also provides a group abstraction to higher layers. This allows mapping groups of
higher-layer protocol addresses into piconets without exposing the concept of a piconet to the
higher layers.

The L2CAP layer assumes that the underlying transmission facilities (that is, the lower transport
protocols) provide a full-duplex communication channel that delivers L2CAP_PDUs in an orderly
manner. L2CAP itself does not provide any mechanisms for securing the reliable transmission of
83
its PDUs. Instead, it relies upon the retransmission process at the baseband layer to support a
sufficiently reliable communication channel for higher layers.

L2CAP Channels
Communication between L2CAP layers is based on logical links, called channels, through which
L2CAP traffic flows between endpoints within each device. Each endpoint of a channel is assigned
a unique channel identifier (CID). A CID is a 16-bit identifier that is locally administered. An
L2CAP layer assigns a different CID to every channel endpoint used therein.[2]
[2]
Strictly speaking, "local" CIDs assigned by an L2CAP layer need to be unique only within the set of channels that this L2CAP
layer establishes with a single "remote" L2CAP layer.

Figure 7.2. L2CAP channels; although not shown, every endpoint is

associated with a payload recipient entity.

Figure 7.2 shows the L2CAP layers in three devices exchanging information using L2CAP
channels. Each channel terminates at an endpoint within the L2CAP layer. Each L2CAP endpoint is
uniquely associated with a payload recipient entity to which the payload of the L2CAP_PDU is
directed for additional processing. The payload recipient entity may reside within the L2CAP layer
itself and be used for signaling purposes between communicating L2CAP layers. The payload
recipient entity may also reside above the L2CAP layer, in which case it represents the higher
layer whose PDUs are transported across Bluetooth links by the L2CAP layer.

The figure identifies the various types of L2CAP channels currently defined. There are persistent
connection-oriented (CO) channels that are used for bidirectional communications; these require
a connection signaling exchange prior to being established. There are ephemeral connectionless
(CL) channels that are unidirectional and can be used for broadcast transmissions to groups of
devices. Since these channels are unidirectional, a device that needs to respond to a

84
connectionless L2CAP transmission must use another channel to do so. Finally, there are
signaling channels that are used primarily to exchange control information that is used to
establish and configure CO channels. Signaling channels borrow features from both CO and CL
channels. Just like CL channels, they do not require an explicit connection establishment prior to
commencing communications over them, but they are persistent and bidirectional in that
information flows in both directions over the same signaling channel.

A number of CIDs are reserved for well-defined, globally known channels, while the remaining
CIDs are administered as needed. Table 7.1 summarizes the various CID types. Between two
devices there can be many CO and many CL channels, but only one signaling channel, since there
exists only one CID that can be assigned to both endpoints of the signaling channel. Owing to
this restriction, each signaling channel can be viewed as a CO channel whose connection phase
has been eliminated because the CID information defining that channel is already known to the
devices; thus the channel is preconfigured with fixed parameters.

Table 7.1. The CID assignment types.

CID Comments
'0x0000' null identifier, not to be assigned
'0x0001' CID for both endpoints of an L2CAP signaling channel
'0x0002' CID for the destination endpoint of a CL L2CAP channel
'0x0003'– range of reserved CIDs
'0x003F'
'0x0040'– range of CIDs allocated on demand by a device to its local endpoints for either
'0xFFFF' CL or CO L2CAP channels

At the outset the MAC-2 protocol (L2CAP's predecessor) was to provide only connectionless
services to the upper layers. Over time it was recognized that for this layer to be extensible and
to remain relevant and amenable to future enhancements (such as support for quality of service),
it needed to provide configurable traffic services. The latter need led to the development and
inclusion of configurable connection-oriented services in the L2CAP layer. Today this connection-
oriented service is the primary one provided by the L2CAP layer. In version 1.0, only the TCS-
based telephony profiles (described in Chapter 13) require the use of CL L2CAP channels.

L2CAP_PDU Types
There are two types of L2CAP_PDUs: the first is used with CO channels and the second with CL
channels. Signaling L2CAP_PDUs are formed according to the former type.

The Connectionless (CL) L2CAP_PDU Type

Table 7.2 summarizes the fields of a CL L2CAP_PDU in the order of transmission. Note that each
header field uses a little-endian byte order with the least significant byte transmitted first; all
fields in the L2CAP_PDU headers follow this little-endian transmission convention.

Table 7.2. The format of a connectionless L2CAP_PDU.

field size comments
L2CAP_PDU_CL_Header

85
 Table 7.2. The format of a connectionless L2CAP_PDU.
field size comments
Length 2 bytes total length in bytes of this L2CAP_PDU excluding the
Length and CID fields 2)
Destination_CID 2 bytes indicates the CID of the destination endpoint of the
L2CAP channel used for this transmission: has fixed
value '0x0002'
PSM 2 bytes protocol and service multiplexer

L2CAP_PDU_CL_Payload

Payload (Length – CL L2CAP_PDU payload data; the maximum possible size

PSM_field_size) is 65,535 bytes minus the size of the PSM field, which
bytes typically is 2 bytes

The PSM field provides the means for identifying the higher-layer recipient of the payload of this
connectionless L2CAP_PDU. It is discussed in more detail below along with the signaling
L2CAP_PDUs for CO channels. The minimum supported value for maximum transmission unit
(MTU) for payloads in CL L2CAP_PDUs is MTU CL = 670 bytes, unless explicitly stated otherwise,
say, in a profile specification.[3]
[3]
The various L2CAP MTUs discussed in this chapter apply only to the payload section of the corresponding L2CAP_PDUs.
Thus, the MTU information is used by the payload recipient entities at the endpoints of an L2CAP channel, see Figure 7.2, to
adjust the maximum size of PDUs that they can send or receive over this L2CAP channel.

The Connection-Oriented (CO) L2CAP_PDU Type

Table 7.3 summarizes the fields of a CO L2CAP_PDU in the order of transmission. As mentioned
earlier, each header field uses a little-endian byte order with the least significant byte transmitted
first.

Table 7.3. The format of a connection-oriented L2CAP_PDU.

field size comments
L2CAP_PDU_CO_Header

Length 2 bytes total length of this L2CAP_PDU excluding the L2CAP_header( 0)

Destination_CID 2 bytes indicates the CID of the destination endpoint of the L2CAP channel
used for this transmission
L2CAP_PDU_CO_Payload

Payload Length CO L2CAP_PDU payload data; the maximum possible size is 65,535
bytes bytes

Comparing the headers of the CL and CO L2CAP_PDUs, one may notice a subtle difference in the
definition of the corresponding Length fields. The PSM field in a CL L2CAP_PDU is treated as if it
were part of the payload, hence its size is accounted for when calculating the Length field. This
difference is intended to maximize code reuse when processing L2CAP_PDUs of either type.

86
The MTU for payloads in CO L2CAP_PDUs, MTU CO, as well as other parameters of a CO channel,
are negotiated during the connection establishment phase using the L2CAP signaling discussed in
the following section.

L2CAP Channel Management: The L2CAP Signaling

Connection-oriented, point-to-point L2CAP channels use signaling to become established, to be
configured, and to be terminated. During the connection establishment phase, the payload
recipient entity in an upper layer of L2CAP_PDUs is identified and the endpoint CIDs for the newly
formed channel are exchanged between the two communicating L2CAP layers. During the
connection establishment phase, the properties for each direction of transmission on the channel
are negotiated and agreed upon. These properties include the payload MTUs, the reliability level
of transmissions between the involved devices, and QoS.

L2CAP signaling consists of request and response PDU transactions carried over the signaling
channel whose endpoints both have the reserved CID value '0x0001'. A device, referred to as the
local device, sends an L2CAP signaling request PDU (for example, to create or configure a
channel) to a remote device, and the remote device responds to the local device's request with a
corresponding L2CAP signaling response PDU. Each transaction is identified by a transactionID
that matches a request from a local device with the subsequent response from the remote
device. Contrary to other L2CAP_PDU transmissions, L2CAP signaling transactions are reliable in
that a local device may retransmit a request if a response is not received within a timeout period.
The decision about whether or not to retransmit a request, as well as the value of the timeout
period, are implementation dependent. The timeout period is at least 1 second and can be up to
60 seconds. A local device may wait up to an additional 300 seconds to receive the final response
if the remote device has responded indicating that it has received an initial request but needs
additional time to complete its processing. For example, a request for connection may require a
device authentication to occur first, which in turn, may require the device to enter a PIN as
discussed in Chapter 6.

Figure 7.3. The management and data-exchange phases of a CO channel

and the local/remote device roles.

87
Figure 7.3 shows a typical sequence of L2CAP signaling transactions between a local and a
remote device. This sequence starts with the L2CAP layer of the local device transmitting a
request for the creation of a channel between the devices. The remote device responds by either
accepting or rejecting the request. Upon acceptance of the request and establishment of the
channel, the local device initiates configuration of the channel for one direction of communication.
The configuration parameters are dictated by the implementation limitations of the L2CAP layer,
including the L2CAP MTU that can be used on this channel and the QoS requirements of the
applications that will be using this channel. The remote device responds positively or negatively
to the local device's configuration parameters. A negative response causes a configuration
negotiation phase between the devices until they both agree upon the configuration parameters.
Following the termination of configuration in one direction, the devices exchange their local and
remote roles and the configuration process continues likewise in the opposite direction. Upon
termination of the configuration phase, the channel is ready to receive and transport PDUs from
higher layers over the newly established channel. Subsequent channel reconfiguration could
happen at any time that the channel is active and could be initiated by either device. The L2CAP
channel terminates when either device initiates the termination phase.

The header of the L2CAP signaling PDUs resembles that of a CO L2CAP_PDU, with the destination
endpoint CID field having the reserved CID value '0x0001'. The payload of the signaling PDUs
consists of a collection of signaling commands. All L2CAP implementations must be able to accept
signaling PDUs with an MTU SIG of 48 bytes. Table 7.4 summarizes the fields of a signaling
command.

Table 7.4. The format of an L2CAP signaling command.

field size comments
L2CAP_Signaling_Command_Header

88
 Table 7.4. The format of an L2CAP signaling command.
field size comments
Code 1 byte identifies the command type
Identifier 1 byte identifies the signaling transaction, transactionID, for matching responses
to corresponding requests; retransmitted commands use the same identifier
Length 2 bytes total length of the payload portion of this command ( 0)
L2CAP_Signaling_Command_Payload

Payload Length signaling command payload data (collection of signaling commands)

bytes

Signaling commands with an unsupported code result in an L2CAP_Command_Reject command

(Code = '0x01') being transmitted in the reverse direction.

The L2CAP_Connection_Request Signaling Command

When a local device wants to establish a CO L2CAP channel with a remote device, it forms and
sends an L2CAP_Connection_Request signaling command (Code = '0x02') to the remote device.
The significant fields of the command are summarized in Table 7.5; note that the table does not
show all the fields of the command and must be interpreted with respect to the signaling-
command format in Table 7.4.

Table 7.5. The L2CAP_Connection_Request signaling command.

field size comments
L2CAP_Connection_Request_Command_Payload

PSM 2 identifies the destination payload processing entity for the L2CAP_PDUs
bytes transmitted to the remote device over the requested channel

Source_CID 2 bytes the CID for the requested channel endpoint in the local device

If and when the channel is established, the remote device will use the value in the Source_CID
field as the Destination_CID (see Table 7.3) to send L2CAP_PDUs to the local device over this CO
channel.

The PSM (protocol and service multiplexer) field is a variable-size field with a minimum (and
typical) size of 2 bytes. It is used for multiplexing several protocols over the L2CAP layer. In
particular, the local device uses the PSM field to inform the remote device about where to direct
the payload of the L2CAP_PDU transmissions over this channel.

Although the PSM field is used for multiplexing middleware protocols that use L2CAP's transport
services, like SDP, RFCOMM, TCS, and so on, it goes a step further. PSM could also identify one
of many implementations of a protocol layer, or even an entire protocol stack, that reside above
L2CAP. For example, a manufacturer could implement two independent RFCOMM layers within a
single device. In this case, multiplexing simply on the name of the RFCOMM protocol would not
be very helpful. The PSM field aids in distinguishing the two RFCOMM implementations by
assigning a different PSM value to each of them.

89
The range of values for the PSM field is divided into two regions. The first region covers the PSM
values up to '0x1000' and consists of reserved values that represent established, well-known
protocols that directly use L2CAP, such as SDP (PSM = '0x0001') or RFCOMM (PSM = '0x0003').[4]
The region of PSM values above '0x1000' is used to identify multiple implementations of a given
protocol above L2CAP (as described above), protocols not yet standardized, experimental
protocols under development, and so on. The PSM value for a given connection can be retrieved
from service discovery records using SDP as described in the next chapter.
[4]
The values of the PSM field are always odd, thus providing a simple means for extending the PSM field beyond its typical
size of 2 bytes.

Originally, the PSM field was just a Protocol field, used to identify a specific protocol that could be
multiplexed over the L2CAP layer. The L2CAP working group in the SIG realized that enhanced
system security requires the ability to identify not just the protocol used but also the application
associated with the connection request. In this respect, the L2CAP layer was recognized as the
natural choice in which to add any security safeguards. But an L2CAP connection request using
just the Protocol field could not identify the application that would ultimately use the connection.
Thus, the PSM field was introduced to identify a protocol stack from the L2CAP layer all the way
up to the service provided by the application that would use the newly formed channel.
Eventually, the group consensus about security at the L2CAP layer took a more general path and
is highlighted in [Muller99]. However, the PSM field did not revert back to the Protocol field. It
was recognized that the added multiplexing flexibility that the PSM field introduced was too
powerful to ignore. Thus, the use of the PSM field has persisted in the specification, although its
name is now somewhat outdated, and it can be used to multiplex not only protocols, but multiple
stack implementations as well. This feature is truly unique to the L2CAP layer.

The L2CAP_Connection_Response Signaling Command

Following the receipt of an L2CAP_Connection_Request command, the remote device returns an

L2CAP_Connection_Response command (Code = '0x03') to inform the local device whether or not
it accepts the connection request. The remote device could also return a connection pending
response to inform the local device that the connection request has been received but no decision
has been made yet; the remote L2CAP layer could, for example, await the result of an
authentication procedure before deciding to accept or reject the connection. If a connection is
refused, the remote device provides the reason(s) for doing so, which could include security
issues, resources not available, or PSM value not supported. Finally, the remote device also
returns the Destination_CID that identifies the CID of the channel endpoint located in the remote
device. This CID is meaningful only if the connection is accepted, and it is used as the
Destination_CID field of the CO L2CAP_PDUs that the local device subsequently sends to the
remote device over this CO channel.

The L2CAP_Configuration_Request Signaling Command

Following channel establishment, the channel needs to be configured. The channel configuration
transaction is mandatory; however, empty configuration commands may be sent when nothing
needs to be configured. Configuration transactions for a channel may occur again at a later time
after normal communications have commenced for the channel. The key fields of the
L2CAP_Configuration_Request command (Code = '0x04') are summarized in Table 7.6.

Table 7.6. The L2CAP_Configuration_Request signaling command.

field size comments
L2CAP_Configuration_Request_Command_Payload

90
 Table 7.6. The L2CAP_Configuration_Request signaling command.
field size comments
Destination_CID 2 bytes for the channel to be configured, identifies the CID of the channel
endpoint in the device that receives this command (the remote
device)
Flags 2 bytes in version 1.0, only the LSB is used to signify that additional
configuration options are to follow in a subsequent configuration
command from the local device
Config_Options variable configuration options for the channel to be configured

The LSB of the Flags field, referred to as the C bit, is used as a continuation flag for additional
configuration options to follow in subsequent configuration commands. Segmentation of the
configuration options in multiple configuration commands may be necessitated by the small MTU
SIG value.

Before examining the configuration options, we discuss the corresponding response command
from the remote device, which also contains a similar set of configuration options.

In the L2CAP_Configuration_Response command (Code = '0x05') that corresponds to an

L2CAP_Configuration_Request command sent from a local device,[5] the responding (remote)
device states whether or not it agrees with the values of the various configurable parameters in
the L2CAP_Configuration_Request command. If a configuration option in an
L2CAP_Configuration_Request command is not supported by the remote device, it rejects the
request and includes in its response a copy of the unsupported option(s).
[5]
Recall that we have defined a local device to be the device that originates an L2CAP signaling transaction, which starts with
the transmission of a request command. The responding device is the remote device.

When an L2CAP_Configuration_Request command is rejected due to disagreement with the

values of any of the configurable parameters, the remote device may either terminate the
configuration process or provide the values of the parameters that could have been acceptable to
it. In this case, the local device may submit a new L2CAP_Configuration_Request command with
the configuration parameter values readjusted; the number of successive resubmissions of
L2CAP_Configuration_Request commands is implementation dependent. If no agreement is
reached between the local and remote devices, the current configuration parameters remain in
effect, or the channel is terminated. The duration of configuration negotiations is implementation
dependent, but the maximum time is 120 seconds.

Note that any response from the remote device regarding a configuration option is exclusively for
the direction of traffic flow implied by the L2CAP_Configuration_Request command. For example,
if the configurable parameter in an L2CAP_Configuration_Request command refers to traffic
leaving the local device, an outgoing traffic parameter, any reference to this parameter by the
remote device will refer to the same traffic parameter arriving at the remote device, an incoming
traffic parameter. Following termination of configuration transactions in one direction, the role of
the local and remote devices is reversed once and configuration of the channel parameters in the
opposite direction may commence. This gives the other device (the former remote device) the
opportunity to configure its traffic parameters as well.

The Configuration Options

Table 7.7 lists the communications parameters that can be adjusted through configuration. The
interpretation of these parameters is relative to the local device—that is, the device that
91
originates the L2CAP_Configuration_Request command and contains the configuration option
related to these parameters.

Table 7.7. The configuration options.

parameter comments
MTU CO identifies the maximum L2CAP_PDU payload, in bytes, that the local device can
accept over this channel; minimum MTU CO = 48 bytes, default MTUCO = 672
bytes[1]
Flush_Timeout identifies the amount of time, in multiples of 1.25 milliseconds, during which the
link manager of the local device will continue attempting to transmit the
baseband segments from an L2CAP_PDU, prior to discarding it; by default
theFlush_Timeout value indicates a reliable channel where PDUs are
retransmitted for as long as required, or until the link is declared lost
QoS identifies the traffic-flow specification for the local device's traffic (outgoing
direction) over this channel

[1]
While the minimum MTUCO was chosen to accommodate buffering capabilities of "simple" devices, such as headsets, the
default value was chosen so that it can conveniently fit within two DH5 BB_PDUs.

The QoS option includes a Service_Type parameter that determines whether or not traffic will be
sent in the outgoing direction by the local device. If yes, then the Service_Type further
determines if the outgoing traffic will be treated by the local device as best effort or guaranteed.
Best-effort traffic is the default and mandatory service type supported by any L2CAP-layer
implementation. With the guaranteed service type, the local device provides the QoS parameters
associated with its outgoing traffic flow. These QoS parameters consist of a subset of the ones
specified in [IETF92] and include: Token_Rate, Token_Bucket_Size, Peak_Bandwidth, Latency,
and Delay_Variation. All of these parameters have default values of "not specified." These values
are ultimately communicated to the link manager of the local device, which then negotiates with
the link manager of the remote device to determine an appropriate polling interval that supports
the desired QoS.

The QoS parameters must be passed to the L2CAP layer from the upper layers. Following any
configuration negotiation for these values, the L2CAP layer uses the resulting parameter values to
control the admission of new connection requests initiated by upper layers of the stack. Based on
their QoS requirements, the L2CAP layer may decide to reject any new connection requests if it
concludes that establishing a new L2CAP channel with a remote device could compromise the
QoS of any existing channel.

With the exception of MTU CO, the definition and use of the QoS parameters was a source of much
debate within the SIG's L2CAP task force. The QoS discussions continued to the very day that the
specification was finalized for publication in the summer of 1999. Debate centered around the
meaning of the QoS parameters, their applicability, implementation effort required, the way they
should be negotiated, and so on. No version 1.0 profile supports anything but best effort traffic;
hence, the QoS parameters easily could have been omitted from the version 1.0 specification.
While proposals to do just that were circulated, it was finally decided that including QoS
parameters in the specification was preferable. Having a standardized set of QoS parameters
enables experimentation with them; this could help software developers gain QoS experience
such that whenever the need arises in any future profiles for the use of QoS guarantees, a solid
foundation of knowledge and implementation experience will exist to efficiently address the
problem. Inclusion of the QoS parameters is an example of the SIG addressing future flexibility of
the specification rather than an immediate requirement of a version 1.0 usage model.

92
Other Configuration Commands

The most commonly used signaling transactions pertain to the L2CAP_Connection_Request and
L2CAP_Configuration_Request signaling commands, together with their corresponding response
commands, and a channel termination request and response transaction using the
L2CAP_Disconnection_Request/_Response signaling commands. L2CAP signaling also provides
two additional exchanges used for testing and information gathering.

The L2CAP_Echo_Request and L2CAP_Echo_Response command transaction is used to test the

connection to a remote device, in a manner similar to the ping command in IP networks. The
echo commands contain an optional payload portion, which could be used to pass information
between the devices in a nonstandard, proprietary (vendor-specific) manner.

The L2CAP_Information_Request and L2CAP_Information_Re-sponse command transaction is

used to request implementation-specific information. Currently, the only piece of information that
can be requested in a standard manner is the value of the connectionless MTU, MTU CL, that the
remote device supports. Nonstandard, vendor-specific information could also be requested with
this transaction.

The Host Controller Interface (HCI)

The Bluetooth transport protocols can be implemented in an integrated fashion, entirely on the
same host (motherboard or processor) that runs the applications that use the transport protocols.
On the other hand, they may be implemented independently of the host on a separate Bluetooth
module that is then attached to the host as an add-on accessory attachment or a plug-in card,
through some physical interface on the host (such as a USB port or an RS-232 serial port). When
implemented separately, the module also contains a host controller unit whose responsibility is to
interpret the information received from the host and direct it to the appropriate components of
the module, like the link manger or the link controller. Likewise, the host controller collects data
and hardware/firmware status from the module and passes it to the host as needed. In the
reference implementation of a Bluetooth module considered by the SIG, the module contains the
radio, the link controller, the link manager and host interfaces for attaching the module to a host,
as depicted in Figure 7.1. This reference implementation does not preclude the possibility of other
implementations built with different components of the stack.

To permit the interoperable use of nonintegrated modules from different manufacturers, the SIG
has defined a standard interface to communicate with the module's host controller in a manner
that is independent of the physical interface and transport mechanism used between the host and
the host controller. The SIG has also defined a transaction-style communication protocol to carry
information between the host and the host controller. This standardized interface between the
host controller and the host, together with the corresponding communication protocol between
them, is collectively referred to as the host controller interface (HCI).

The HCI portion of the specification is by far the largest one—nearly 300 pages including the HCI
transport sections. The SIG's HCI e-mail list is also the most populated and busy one. This should
come as no surprise; in a sense, the capabilities of the HCI define what can be accomplished with
the Bluetooth technology. Since HCI defines the set of functions of a Bluetooth module that are
accessible to the host and its applications, HCI is the gatekeeper of the services that this module
can provide to its users. Any feature of the module that is not exposed (or that is not exposed
properly) by the HCI limits the functionality of the module and ultimately the potential of
Bluetooth wireless communications.

Figure 7.4. System architecture for a device with a host interface.

93
Figure 7.4 shows a protocol stack with an HCI. The HCI part contains a set of interfaces to the
higher layers, which the specification defines through a long list of HCI_PDUs.[6] There is also a
host driver, or HCI driver, which executes the communication protocol for exchanging the
HCI_PDUs with the host controller. Finally, there is the transport protocol that carries the
HCI_PDUs across the physical interface, or HCI transport. For the HCI transport, the SIG has not
developed any new protocols; instead it has reused three existing ones: the Universal Serial Bus
(USB) protocol, the RS-232 serial port protocol, and the universal asynchronous receiver and
transmitter (UART) protocol, which is a proper subset of the RS-232 protocol and can be used if
the module attaches directly to the UART of a serial port without the need for serial cables. The
HCI transport has its own complementary driver components in both the host and module.
[6]
Once again, this is not the terminology used in the specification, but it is used here for consistency with the rest of the book.

Implementation of the HCI is not mandatory and in fully integrated systems may not even be
necessary. However, manufacturers of products, both OEMs and component integrators, must
provide an HCI-like interface to test their product for compliance with the lower transport
protocol test specification as described in the Test Control Interface part of the specification.

The HCI_PDU Packet Classes

Three classes of HCI_PDUs are used to exchange information between the HCI layer[7] in the host
and the host controller in the module, as shown in Figure 7.5. There are command-class
HCI_PDUs that carry control and management information; these are sent from the HCI layer to
the host controller. There are event-class HCI_PDUs that carry control and management
information from the host controller to the HCI layer. Finally, there are data-class HCI_PDUs that
carry fragments of L2CAP_PDUs and SCO data. The HCI specification splits the latter class into
two categories, one for asynchronous L2CAP data and one for synchronous data, but in reality all

94
data-class HCI_PDUs have the same number of fields and identical field delineation. As such, the
two categories of data-class HCI_PDUs are better interpreted as two different modes of the same
HCI_PDU class. Information in HCI_PDUs is encoded in little-endian format. The figure also
includes the physical interface between the host and the module. Based on the type of this
interface, a separate HCI transport protocol is used. The figure indicates the three HCI transports
defined in the specification: RS-232, UART and USB.
[7]
We collectively refer to the HCI and the HCI protocol driver as the HCI layer.

Figure 7.5. The HCI_PDU classes; HC stands for host controller.

For completeness, Figure 7.5 shows the possible active links that a device might have. Two
devices may have at most one ACL link between them. A master may have up to seven active
ACL links with its slaves (one per active slave). Also, there may be up to three SCO links between
the master and all its slaves in a piconet. Note that an ACL link between two devices must exist
prior to establishing any SCO links between those devices.

Table 7.8 shows the structure of a command HCI_PDU. It includes an OpCode field used to
identify the command type. The payload section of the command consists of a number of
parameters that vary by command type.

Table 7.8. The command HCI_PDU.

field size comments
HCI_Command_Header

OpCode 2 bytes OpCode group subfield (OGF) (6 bits) identifies the group
that the OpCode belongs to:

• 'b111110' identifies a reserved OGF used for

Bluetooth logo testing
• 'b111111' identifies a reserved OGF for vendor-
specific commands used during module manufacture,
such as module debugging operations
• Other values indicate other groups such as link
control link policy baseband and others as described

95
 Table 7.8. The command HCI_PDU.
field size comments
below and detailed in the specification

OpCode command subfield (OCF) (10 bits) identifies a

specific HCI command within the particular OGF
Payload_Length 1 byte length of the payload of the command HCI_PDU in bytes
HCI_Command_Payload

Payload Payload_Length the payload of a command HCI_PDU is structured as a

bytes sequence of variable-size fields for the various parameters
related to this command

Table 7.9 shows the structure of an event HCI_PDU. Similarly to a command HCI_PDU, it consists
of an Event_Code field used to identify the event and a payload section with a number of
parameters which are relative to this event HCI_PDU.

Table 7.9. The event HCI_PDU.

Field size comments
HCI_Event_Header

Event_Code 1 byte identifies the event

• '0xFE' is reserved for Bluetooth logo specific events

• '0xFF' is reserved for vendor-specific events used
during module manufacturing, such as module testing
and debugging operations

Payload_Length 1 byte length of the payload of the event HCI_PDU in bytes

HCI_Event_Payload

Payload Payload_Length the payload of an event HCI_PDU is structured as a

bytes sequence of variable-size fields for the various parameters
related to this event

A host uses the command HCI_PDUs for things like:

• setting operational parameters of the module, such as providing a link key for
authentication;
• configuring the module's operational status and related parameters, for instance causing it
to activate and set the related parameters for a low power mode;
• reading and writing register entries, like the number of broadcast packet repetitions, N BC,
and so on.

Depending upon the command, module registers will be read or set, the link manager will
execute an LMP transaction, the link controller will change state and execute, say, a page, and so
on. The host controller notifies the host of the outcome of the command with an event HCI_PDU

96
either soon after the command is sent from the host or at a later time when appropriate—for
example, following the termination of an LMP transaction. The reason that host controller
HCI_PDU transmissions to the host are called events and not responses is that the host controller
may initiate its own request (for instance, requesting a missing link key from the host) or send a
transmission to the host without the host's prior action (perhaps notifying it of a connection
request coming from a remote device). Actually, some of the command HCI_PDUs sent from the
host are simply responses to event HCI_PDUs that originated from the host controller. For
example, the HCI_Accept_Connection_Request command is sent by the host to the host
controller instructing the latter to accept an incoming connection request from a remote device.
Before the host transmits the HCI_Accept_Connection_Request command, the host controller
notifies the host of the incoming connection request with a Connection_Request event.

Table 7.10 shows the structure of a data HCI_PDU.

Table 7.10. The data HCI_PDU.

field size comments
HCI_Data_Header

Connection_Handle 12 bits identifies the baseband link over which these data are
transmitted or received; connection handles in the range
'0xF00' to '0xFFF' are reserved for future use
Flags 4 bits ACL transmissions: composed of two subfields:

• Packet_Boundary_Flag: identifies the beginning or

continuation of an upper-layer (L2CAP) PDU
• Broadcast_Flag: identifies the "spread factor" for
the ACL transmission: point-to-point, broadcast to
active slaves, or broadcast to all slaves including
any parked ones

SCO transmissions: reserved field

Payload_Length 2 bytes length of the payload of the data HCI_PDU in bytes

HCI_Data_Payload

Payload Payload_Length data to be carried over the ACL or SCO baseband link
bytes identified by the contents of the Connection_Handle field

Transmission of data HCI_PDUs across the physical interface is regulated by the buffer sizes
available on the receiving side of the PDU. Both the host and the host controller inquire about the
buffer size available for receiving data HCI_PDUs on the opposite side of the interface and adjust
their transmissions accordingly. This implies that a large L2CAP_PDU may need to be fragmented
within the HCI layer prior to sending it to the host controller. On the receiving side, the HCI layer
could reconstruct L2CAP_PDUs based on the packet boundary flag information within the received
data HCI_PDUs. Transmission of HCI_PDUs across the physical interface is in first-in-first-out
order without preemption. Commands are processed by the host controller in their order of
arrival, but they may complete out of order since each might take a different amount of time to
execute. Similarly, events are processed by the host in order of arrival, but their processing may
terminate out of order.

97
Note that none of the fields in any of the HCI_PDUs identifies the HCI_PDU class: command,
event or data. Identification of the HCI_PDU class is left to the HCI transport protocol that
actually carries the PDUs between the host and the host controller. Strictly speaking, this is a
violation of protocol layering. However, it allows the HCI to take advantage of the capabilities of
the underlying transport protocol, which may provide its own means for distinguishing the three
HCI_PDU classes with minimal overhead. Purists may wish to consider that the HCI layer in the
host and its complementary part in the host controller consist of a transport-independent
sublayer, and a transport dependent convergence sublayer (which executes the HCI transport
protocol) that adapts the HCI_PDUs to the particular transport method used to carry them across
the physical interface.

The HCI_PDUs
There are many command HCI_PDUs organized into several groups identified by the OGF subfield
in the header of the command HCI_PDU. For many of these command HCI_PDUs there exists a
corresponding event HCI_PDU that carries the outcome and return parameters related to the
command. For several commands, information related to their status and execution results is
carried by two special events: Command_Status_Event and Command_Complete_Event. The
former typically is sent immediately after a command is received by the host controller to indicate
the status of the command, such as command pending execution, command not understood, and
so on. This provides a sort of acknowledgement of the command along with an indication of its
processing status. The latter is used to indicate the completion of execution of a command and to
return related parameters, including whether or not the requested command was executed
successfully. Observe that multiple events might be generated in response to a single command.

There are command HCI_PDUs related to link controller actions, policy-setting commands, the
host controller itself, and many others. Command and event HCI_PDUs number over 100; some
of these are highlighted in the following sections. These selected HCI_PDUs are illustrative of the
type of information and the level of detail that is communicated between the host and the host
controller. For the full set of HCI_PDUs, refer to the specification.

Link Control HCI_PDUs

The commands in this group are identified via the OGF subfield with the value 'b000001'. This
group contains commands that allow inquiries to be sent to discover other devices in the vicinity.
There are commands to create and terminate ACL and SCO connections and to accept or reject
incoming connection requests. There are commands for initiating authentication and encryption
procedures as well as for transporting authentication keys and PINs from the host to the link
controller. There are information commands in this group to request the user-friendly name of
the remote device, the link manager options that it supports and the clock offset registered in the
remote device.

Following are some examples of HCI_PDUs in this group. The HCI_Inquiry command PDU
instructs the module to enter the inquiry mode, using a given inquiry access code, for a specified
amount of time or until a specified number of responses is collected. This command is
summarized in Table 7.11.

Table 7.11. The HCI_Inquiry command HCI_PDU.

Command_Name HCI_Inquiry
OCF 'b0000000001'
Parameters LAP 3 lower address part used for generating the inquiry
bytes access code

98
 Table 7.11. The HCI_Inquiry command HCI_PDU.
Command_Name HCI_Inquiry
Inquiry_Length 1 byte indicates the maximum duration for this inquiry:
1.28 sec - 61.44 sec
Num_Responses 1 byte indicates the maximum number of responses to be
collected

The inquiry mode originated by this command terminates either when Inquiry_Length time has
elapsed or when the number of responding devices reaches Num_Responses, whichever occurs
first.

The host controller returns information collected from inquiries to the host with the
Inquiry_Result_Event [8] summarized in Table 7.12; the parameters of the event are derived from
the FHS BB_PDUs (detailed in the previous chapter) that are received from the devices
responding to the inquiries. A brief description of the parameters below is given in Table 7.13,
which presents the command that uses these parameters.
[8]
This event is actually called "Inquiry Result" event. Once again we take liberty in the naming convention for consistency
purposes with other PDUs.

Table 7.12. The Inquiry_Result_Event event HCI_PDU; the index i

identifies each of the Num_Responses responding devices.
Event_Name Inquiry_Result_Event
Event_Code '0x02'
Parameters Num_Responses 1 byte
BD_ADDR[i] 6*Num_Responses bytes

Page_Scan_Repetition_Mode [i] 1*Num_Responses byte(s)

Page_Scan_Period_Mode[i] 1*Num_Responses byte(s)

Page_Scan_Mode[i] 1*Num_Responses byte(s)

Class_of_Device[i] 3*Num_Responses bytes

Clock_Offset[i] 2*Num_Responses bytes

The HCI_Create_Connection command PDU instructs the module to create a connection with a
specified device, using a given set of BB_PDU types for the ACL link. Since the connection
process requires that the "local" device page the "remote" device, this command also provides
information used to accelerate the paging process. The paging information becomes available to
the host of a local device via an earlier Inquiry_Result_Event PDU, shown in Table 7.12. The
HCI_Create_Connection command is summarized in Table 7.13.

Table 7.13. The HCI_Create_Connection command HCI_PDU.

Command_Name HCI_Create_Connection
OCF 'b0000000101'

99
 Table 7.13. The HCI_Create_Connection command HCI_PDU.
Command_Name HCI_Create_Connection
Parameters BD_ADDR 6 identifies the remote device with which to
bytes establish a connection
Packet_Type 2 indicates which BB_PDU types can be
bytes used by the link manager for the ACL link
Page_Scan_Repetition_Mode 1 indicates the page scan repetition mode,
byte that is, how frequently the remote device
enters the page scan mode, last reported
by the remote device
Page_Scan_Mode 1 indicates the page scan mode supported
byte by the device
Clock_Offset 2 indicates the difference between the
bytes slave and master clocks, as calculated in
the last communication between them
Allow_Role_Switch 1 indicates whether this (the paging)
byte device will be the master or will allow the
paged device to become the master if
requested[1]

[1]
Master-slave role switching is described in the previous chapter.

Upon successful creation of the connection, a Connection_Complete_Event is sent to the hosts on

both sides of the connection. The events contain the Connection_Handles for identifying the
connection. The connection handles are assigned by each host controller independently and their
scope is limited to the local device only.

Link Policy HCI_PDUs

The commands in this group are identified via the OGF subfield with the value `b000010'. This
group contains commands that allow a device to set a power-management policy through the
hold, sniff, and park baseband modes and to define the parameters for those modes. Also, there
are commands that pass QoS parameters from the L2CAP layer to the link manager, learn about
the role (master or slave) that the device[9] plays for a particular connection and request a role
switch if needed.
[9]
Recall that information regarding the role that a device plays in a particular connection does not propagate through the stack
beyond the link manager layer. A host needs to explicitly request this information from the host controller.

Table 7.14 summarizes the HCI_PDU command that requests the host controller to instruct the
link manager and the baseband to enter hold mode with the parameters provided. Similar
commands exist for sniff and park modes.

Table 7.14. The HCI_Hold_Mode command PDU.

Command_Name HCI_Hold_Mode
OCF 'b0000000001'
Parameters Connection_Handle 2 identifies the connection (actually the ACL
bytes link) to be placed in hold mode; only the

100
 Table 7.14. The HCI_Hold_Mode command PDU.
Command_Name HCI_Hold_Mode
12 LSBs are used
Hold_Mode_Max_Interval 2 indicates the maximum negotiable hold
bytes interval (0.625 msec – 40.9 sec)
Hold_Mode_Min_Interval 2 indicates the minimum negotiable hold
bytes interval (0.625 msec – 40.9 sec)

The host controller notifies the host when hold mode is entered or is terminated using the
Mode_Change_Event.

Host Controller and Baseband HCI_PDUs

The commands in this group are identified via the OGF subfield with the value 'b000011'. This
group contains commands that allow the host to access and configure various hardware registers
that maintain operational parameters. Among the operations that can be performed are
determining the types of events that the host controller can generate; reading, writing, and
deleting stored keys; reading and writing the user-friendly device name; activating and
deactivating inquiry and/or page scans; reading and writing the authentication and/or encryption
activity flag for a link; reading and writing the inquiry access codes used to listen during inquiry
scans; forcing the flushing of ACL packets for a connection handle; reading and writing the audio
codec parameters and so on.

Table 7.15 summarizes the HCI_PDU command that sets the inquiry scan parameters; a similar
command exists for page scans as well. Inquiry scans occur only when the host has already sent
an HCI_Write_Scan_Enable command PDU to enable inquiry scans.

Table 7.15. The HCI_Write_Page_Scan_Activity command PDU.

Command_Name HCI_Write_Inquiry_Scan_Activity
OCF 'b0000011100'
Parameters Inquiry_Scan_Interval 2 determines the interval between successive
bytes starts of inquiry scans11.25 msec – 2.56 sec
(typically, 1.28 sec)
Inquiry_Scan_Window 2 determines the duration of a single
bytes continuous scan operation11.25 msec – 2.56
sec (typically, 11.25 msec)

When the host controller finishes updating the related registers it returns a
Command_Complete_Event to the host.

Informational Parameters HCI_PDUs

The commands in this group are identified via the OGF subfield with the value 'b000100'. This
group includes commands that request static information about the hardware and firmware that
is electronically "engraved" on the device at manufacture time. There is a command to request
the version of the various protocols (LMP, HCI, and so on) that the module supports; a command
to request a list of features supported by the link manager; a command to request the country of
operation of the module; a command to request the BD_ADDR of the module;[10] and a command

101
to request the host controller buffer information for ACL and SCO packets, used to execute
effective flow control at the host. The requested information is returned in a
Command_Complete_Event.
[10]
Recall that the BD_ADDR is hardwired and cannot be modified.

Status Parameters HCI_PDUs

The commands in this group are identified via the OGF subfield with the value 'b000101'. This
group includes commands that request information that is dynamically updated, like the value of
the contact counter that measures the number of successive instants during which the remote
device does not respond to local transmissions, causing the local link manager to flush any PDUs
waiting to be transmitted. There is also a command HCI_PDU to retrieve information related to
the quality of the link and the RSSI (received signal strength indicator) value. The requested
information is returned in a Command_Complete_Event.

Testing HCI_PDUs

The commands in this group are identified via the OGF subfield with the value 'b000110'. These
commands, which all result in Command_Complete_Event events, are used for testing the
Bluetooth module and are not discussed further here.

Summary
In this chapter we have highlighted the upper two Bluetooth transport protocols: L2CAP and HCI.
The latter is a transport protocol internal to a device, rather than an over-the-air protocol as are
L2CAP and the other protocols discussed in Part 2 of the book. The primary purposes of these
protocols are both to hide, in the case of L2CAP, and to expose, in the case of HCI, the internal
operation of the lower transport protocols. L2CAP is used to multiplex and transport higher
protocol layers while shielding them from the peculiarities of the lower transport protocols, like
the baseband. The HCI provides a standardized interface to the services and capabilities provided
by the lower transport protocols.

In this and the previous chapters we have presented the protocols that the SIG has developed for
transporting data across Bluetooth devices. These protocols have been developed entirely by the
SIG specifically for Bluetooth wireless communication. They reflect the SIG's objectives to
develop simple, cost-effective communication systems that can operate at low power in noise-
susceptible places. In the next chapter we introduce the middleware protocols that are used to
take advantage of the data-transport services of the transport protocols to enable a plethora of
applications, including legacy applications, to operate smoothly over Bluetooth links.

102
Chapter 8. The RFCOMM and SDP
Middleware Protocols
We now move from the transport protocol layers to a detailed discussion of the middleware
protocols. In this chapter we discuss RFCOMM, the Bluetooth serial port emulation protocol, and
the Bluetooth Service Discovery Protocol, or SDP. Version 1.0 of the core specification (volume 1)
devotes nearly 90 pages to these two protocols. As with the other detailed discussions of portions
of the specification, this chapter attempts to reveal the motivation and thought process behind
the development of these protocols. While the important elements of RFCOMM and SDP are
examined here, this material focuses on the design basis for the protocols and thus is not a
substitute for the specification itself.

Both RFCOMM and SDP reside directly above the L2CAP layer (discussed in the previous chapter)
and use L2CAP connections to accomplish their respective functions. Both of these protocols
provide a protocol data unit (PDU) structure for use by higher layers (either applications or other
middleware protocols) in the stack. PDUs allow the higher layers of the stack to work with logical
data elements at a higher level of abstraction than that of the packet format used by the
transport protocols. Both RFCOMM and SDP are protocols developed specifically for use with
Bluetooth wireless communications, although RFCOMM borrows heavily from an existing
standard. Figure 8.1 illustrates the position of RFCOMM and SDP in the protocol stack. As shown
in the figure, RFCOMM is used by higher layer middleware protocols and by applications for
networking, IrDA interoperability and telephony. These same applications may communicate
directly with RFCOMM as well as with their associated middleware protocols that in turn
communicate with RFCOMM. Since service discovery is fundamental to all Bluetooth profiles, most
applications will also communicate with the SDP layer.

Figure 8.1. RFCOMM and SDP in the Bluetooth protocol stack.

103
The RFCOMM Protocol
Serial interfaces are ubiquitous in computing and telecommunications devices, particularly those
devices with a high affinity for Bluetooth communications. Notebook computers have serial ports,
personal digital assistants typically have serial ports (often used to synchronize the PDA with
some other device), many mobile telephones have serial ports (often used for a wired headset),
many digital cameras use serial ports to transfer image data to another device, printers and other
computer peripherals often use serial ports for communication, and so on. Moreover, infrared
communication, which as previously established has some traits in common with Bluetooth
wireless communication, normally uses a serial port to communicate with the IR transceiver.[1]
[1]
In the PC domain, infrared communications are frequently tied to a COM port resource. In commonly used PC operating
environments, these COM ports classically have been difficult to configure, especially for infrared communications. This
drawback has led to a situation where, while many infrared ports are deployed in products, only a fraction of these ports are
actually used, since many users lack the expertise or motivation to perform the necessary configuration process. The rise of
infrared ports on PDAs and mobile phones, where the configuration process is much easier, seems to lead to a higher usage
rate of infrared in peer-to-peer communications.

Because Bluetooth technology aims to replace cables, it seems clear that there is a large
opportunity to replace serial cables. To do this effectively, the stack needs to support serial
communication in the same manner as is done with cables, so that applications are presented
with a familiar serial interface. This permits the cornucopia of legacy applications that are
unaware of the Bluetooth technology to operate seamlessly over Bluetooth links. Furthermore,
application software developers skilled in developing serial communication applications may still
continue to do so, assured that their applications will operate over Bluetooth links. But the
transport-layer protocols are not modeled after a serial port. L2CAP supports packet data
structures, and while the air-interface may transmit bit patterns in a serial fashion, this is not the
same as the common RS-232 types of serial interfaces used today with serial cables.

Thus the SIG has chosen to define a layer in the protocol stack that looks very much like a typical
serial interface: the RFCOMM layer. In the world of personal computers, serial interfaces are
often called COM ports. The name RFCOMM connotes a wireless (RF) instance of a virtual COM
port. RFCOMM primarily is intended to enable cable-replacement scenarios for existing
applications.

RFCOMM Protocol Development

The motivation for the RFCOMM protocol layer is rooted in the requirement to support legacy
applications with initial Bluetooth implementations. The need for this serial communication
function in the software stack was identified quite early in the SIG's formation. Just one month
after the SIG was publicly announced, discussions ensued on developing the specification for the
RFCOMM layer. At that time, the ETSI TS 07.10 standard [ETSI99] had already been identified as
a candidate for a basis upon which to build Bluetooth serial communications. Requirements for
Bluetooth serial communications include:

Multiplexed serial communications: There may be many simultaneous clients of the serial
interface in the stack, including IrOBEX, telephony control and networking clients. Thus the serial
port needs to be shareable through multiplexed connections (which in turn might be supported by
the protocol multiplexing in the L2CAP layer, over which distinct RFCOMM entities in different
devices communicate).

RS-232 signal compatibility: RS-232 is a widely used serial interface for the cables with which
Bluetooth wireless communication needs to be compatible. Many applications are familiar with
RS-232 interfaces, including the various control signals associated with RS-232; these include
common signals such as Request to Send/Clear to Send (RTS/CTS), Data Terminal Ready/Data

104
Set Ready (DTR/DSR), the RS-232 break frame and others. Emulating these signals allows
RFCOMM to present to its clients the appearance of a serial port that is virtually the same as that
used with a serial cable.

Remote status and configuration: In a peer-to-peer environment, the two parties

communicating over the serial link often need to determine the status and configuration of the
remote serial interface so that the local serial interface can be configured in a compatible
manner. The service discovery protocol, discussed in following sections, can be used to obtain
basic information needed to establish a serial communications channel; following connection
establishment the two ends of the serial interface need to be able to negotiate compatible serial
communication settings for the connection.

Internal and external serial port: To support the various uses of serial communications in
Bluetooth applications, RFCOMM needs to support both an internal emulated serial port, in which
the serial port parameters are used only locally (the parameters do not apply across the air-
interface) as well as an external serial port, where the serial port parameters and status are
transmitted across the RF link along with the data and may be used by the receiving serial port.

These requirements are not unique to Bluetooth environments, and the SIG realized that the
aforementioned ETSI TS 07.10 standard was a good match for the needs of Bluetooth serial
communications, so the SIG adopted much of that standard. However, TS 07.10 is not a perfect
match for use in the Bluetooth protocol stack, so the SIG added some of its own modifications to
adapt the ETSI standard for use in Bluetooth wireless communications. Among these additions
and changes are:

Data frame adaptations: Since Bluetooth communication has an underlying packet structure by
virtue of the use of L2CAP, some of the data frame contents specified by TS 07.10 are
unnecessary for RFCOMM. For example, the frame delimiter flags specified in TS 07.10 are
discarded for the RFCOMM specification.

Connection establishment and termination: Again, because Bluetooth communication has its
own connection management in the transport protocol layers that RFCOMM uses, the connection
management functions of TS 07.10 are superfluous for RFCOMM. The specification details how
RFCOMM links are managed.

Multiplexing: RFCOMM uses a subset of the multiplex channels specified for TS 07.10 and
specifies the way in which some TS 07.10 multiplexing control commands are used in RFCOMM.

Applicability: The RFCOMM specification mandates support of several features which are
optional in the TS 07.10 standard. These features deal with exchanging information about the
configuration and status of the serial connection and include negotiating the serial port and
individual channel settings and retrieving the serial port status. In Bluetooth environments these
functions are quite useful and in fact can be considered necessary for effective use of the air-
interface; thus they are specified as mandatory to support in RFCOMM.

Flow control: Typical serial ports pace the data transfer using XON/XOFF pacing or DTR signal
pacing. For RFCOMM, the specification describes flow control mechanisms specific to the
Bluetooth protocol stack, including flow control that applies to all multiplexed RFCOMM channels
as well as per-channel pacing.

The remaining RFCOMM sections in this chapter review key points of the RFCOMM specification, in
many cases highlighting the significance of the design choices for this protocol layer.

The RFCOMM Protocol Examined

105
The relatively few pages[2] devoted to RFCOMM in the specification belie its importance in the
version 1.0 protocol stack. RFCOMM is the basis for most of the version 1.0 profiles and might
also be used in some future profiles, although its primary purpose is to enable support for legacy
applications in simple cable-replacement scenarios.[3] The main reason that RFCOMM does not
require many dozens of pages of explanation is the SIG's decision to adopt much of the ETSI TS
07.10 protocol (which itself is over 50 pages of specification). By specifying TS 07.10 as the basis
for RFCOMM, the SIG has adopted a mature standard protocol and the specification needs to
describe only the adaptation of this standard for Bluetooth environments. Much of the RFCOMM
chapter of the specification focuses on describing which parts of TS 07.10 are relevant for
RFCOMM, how those features are used and the modifications necessary to map TS 07.10 into the
Bluetooth protocol stack.
[2]
Only about 25 pages, making the RFCOMM portion of the specification a good candidate for beginning-to-end reading for
those interested in fully understanding this key layer of the stack.

[3]
RFCOMM might become less significant in future usage models as the specification evolves to support general TCP/IP
networking. In the meantime, the SIG specified RFCOMM as a solution for serial-cable-replacement usage models.

RFCOMM uses an L2CAP connection to instantiate a logical serial link between two devices. In
particular, an L2CAP connection-oriented channel is established that connects the two RFCOMM
entities in the two devices. Only a single RFCOMM connection is permitted between two devices
at a given time, but that connection may be multiplexed so that there can be multiple logical
serial links between the devices.[4] The first RFCOMM client establishes the RFCOMM connection
over L2CAP; additional users of the existing connection can use the multiplexing capabilities of
RFCOMM to establish new channels over the existing link; and the last user to drop the final
RFCOMM serial link should terminate the RFCOMM connection (and hence the underlying L2CAP
connection). Each multiplexed link is identified by a number called a Data Link Connection
Identifier, or DLCI. Figure 8.2 depicts multiplexed serial communications links using RFCOMM
over L2CAP. In the illustration the various clients of RFCOMM each see their own emulated serial
port, distinguished by a DLCI value (depicted by the different line types in the figure). These
separate channels are then multiplexed over the RFCOMM link, which in turn is carried over an
L2CAP connection.
[4]
Multiple links might be attained either through multiple instances of a single-channel RFCOMM or through a single instance
of a multiple-channel RFCOMM (the latter being what the Bluetooth specification defines). While these might be logically
equivalent, they are likely to result in real differences in implementations. The RFCOMM specification indicates that a client
which requires a serial connection should first check for an already existing RFCOMM connection to the target device; if an
RFCOMM connection to that device already exists, the client should just establish a new channel on that existing connection.

Figure 8.2. Multiplexed RFCOMM logical serial links (indicated by

different line types) over a single RFCOMM connection, in turn over an
L2CAP connection.

106
The specification allows for up to 60 multiplexed logical serial links over a single RFCOMM
connection but does not mandate this level of multiplexing for RFCOMM implementations. In fact
for most portable devices it is uncommon to have cases in which dozens of simultaneous serial
links would be required in Bluetooth environments. Most devices are expected to support a fixed
number of profiles, which will be a determining factor in how the protocol stack for those devices
is implemented, including design tradeoffs such as the number of RFCOMM serial links supported.
But consider also devices such as network access points that allow portable devices to use
Bluetooth wireless communication to access larger networks (such as the Internet). The LAN
Access profile (discussed in Chapter 15) specifies the use of PPP over RFCOMM, so a LAN access
point device might indeed need many simultaneous serial connections to multiple devices. The
RFCOMM specification supports this sort of usage by allowing more than one multiplexer session
(that is, more than one instance of RFCOMM, in which case the multiplexing is achieved by using
L2CAP's multiplexing capabilities), although such a capability is not mandated.

The RFCOMM chapter of the specification includes a discussion of two different sorts of devices
that RFCOMM supports: communication endpoint (computer- or peripheral-style devices) and
communication midpoint (modem-style devices). In general serial communications, these are
often referred to as data terminal equipment (DTE) and data communications equipment (DCE),
respectively. After making this distinction, though, the discussion concludes by stating that
RFCOMM does not distinguish between these device types at all. In fact, it is not necessary for
RFCOMM to do so; much as a standard serial cable can be configured for a direct serial
connection or for null modem operation, RFCOMM also can be used in both manners. RFCOMM
has included features to support DCE (modem-style) communications; these features may not be
applicable for DTE communications. RFCOMM supports both device styles without needing to
distinguish between them.

Typical cabled serial connections have a number of signals in the cable (usually nine for RS-232
communications, although all nine signals are not necessarily used in all applications). Bluetooth
wireless communication obviously has no such signals because the transmission medium is the
air-interface rather than a cable. In a multiplexed environment such as is defined by TS 07.10, it
is desirable that each serial channel be viewed as an independent entity, with its own set of
control and data signals. So even in a cabled environment some scheme is needed for
multiplexing the serial signals. TS 07.10, and thus RFCOMM, do this by defining a specified
control channel across which information is transmitted as data. That is to say, rather than
setting and monitoring signal levels as is done with a standard RS-232 interface, RFCOMM uses
commands and responses to communicate the state of the multiplexed serial interface (thus
virtualizing the RS-232 signals).

107
RS-232 defines other states that are not directly represented by signals. Notable among these is
the baud rate, or the clock frequency used to transmit and receive data. In standard cabled serial
communications, a clock governs the time associated with the signal transition to and from low
and high levels, which define the 0/1 bit patterns. Obviously both sides of the interface must use
the same clock frequency, or baud rate, to correctly interpret the data that is transmitted across
the wire. For wireless environments, however, there is no cable and thus no signal wire to pulse
at a specified frequency. Clearly, though, Bluetooth wireless communication does employ clock
timings to communicate over the air-interface at the baseband level. Since RFCOMM operates
over the transport layers of the protocol stack, it makes use of the packet structure and
transmission medium used by those lower layers. The baud rate of Bluetooth wireless
communication is determined by the packet types and structures being sent over the air-
interface. The actual communication will occur at the rate determined by the baseband protocol,
regardless of what baud rate might be specified at the RFCOMM layer for serial port emulation.
So while an application or other client of RFCOMM can specify a baud rate (this would be a typical
action, especially for legacy applications, and RFCOMM allows it), the specified baud rate does not
determine the actual data rate. In many cases, the data transmission rate using Bluetooth
wireless communication could be faster than for typical cabled communications.

RFCOMM Protocol Usage

Curiously, the RFCOMM chapter of the core specification (volume 1) includes a section containing
the sort of information (application considerations, interactions with other protocol stack layers
and SDP service record data) that is usually found in the profile specifications (volume 2). This is
an artifact of the development of the RFCOMM specification. As previously noted, RFCOMM
specification development was underway almost from the beginning of the SIG's formation. Along
with the lower-layer transport protocols, which consumed much of the SIG's attention at first,
RFCOMM was one of the first protocols to reach a stable specification level (this is due partly to
the fact that RFCOMM leverages the TS 07.10 standard and partly to the hard work applied to the
RFCOMM specification by its owners in the SIG, since the SIG recognized that RFCOMM was a key
element of the version 1.0 protocol stack and a foundation upon which other protocol layers and
profiles were to be built). Most of the profiles were developed after the core specification was
stable. The forward-looking authors of the RFCOMM portion of the specification had already
included some of the information that subsequently became part of the serial port profile
(covered in Chapter 14).

So the RFCOMM chapter of the specification gives some hints on using this layer of the protocol
stack. The specification talks about Port Emulation and Port Proxy entities, the former mapping
platform APIs to RFCOMM functions and the latter mapping RFCOMM to a "real" RS-232 external
interface. The point, though, is that the authors of the RFCOMM specification not only have
specified a protocol that is necessary for many legacy applications to make use of Bluetooth
wireless communications but also have offered a few considerations for the applications that use
that protocol.

In fact the programming model suggested in RFCOMM is a specific instance of the generalized
model suggested in the section entitled "The Application Group" in Chapter 5 (refer back to
Figure 5.4). In this case we suggest a thin layer of Bluetooth adaptation software for legacy
applications that maps platform APIs to specific functions of the Bluetooth protocol stack. In the
case of RFCOMM, which provides an emulated serial port, this adaptation software (which the
specification calls a port emulation entity) needs to map the application's interactions with a
"real" RS-232 serial port to the equivalent operations for the RFCOMM emulated serial port. For
the most part these are expected to be initialization operations such as activating and configuring
the serial port and establishing a serial connection; and finalization operations such as
terminating the serial connection. Once a general serial port adaptation layer is in place in a
system, all those legacy applications that use serial communication ought to be enabled to use
Bluetooth transports via the RFCOMM emulated serial port.

108
As pointed out earlier, the use of serial ports is prevalent in devices and environments where
Bluetooth wireless communication is likely to be used, and the majority of the version 1.0 profiles
depend upon serial port communications. In the absence of a version 1.0 specification for general
networking, the RFCOMM protocol provides an important utility for legacy applications. The
implementation of this protocol, along with adaptation software for legacy applications that use
serial communications, permits many simple cable replacement applications of Bluetooth wireless
communication.

The Service Discovery Protocol (SDP)

Service discovery is a process by which devices and services in networks can locate, gather
information about and ultimately make use of other services in the network. In traditional
networks such as LANs, these services might be statically configured and managed by a network
administrator. In these environments, the administrator or end user performs the configuration
that is necessary for one participant in the network to use the services of some other network
member. For example, a PC user might specify all of the information associated with a network e-
mail service (including the mail server name, user and account names, e-mail type, capabilities
and options, and so on) to the PC's operating system and applications; once all this information is
entered into the PC and associated with that e-mail service, then the e-mail service becomes
available to the PC user.

Administered network services of this sort may be fine for many fixed networks but are really not
suitable for temporary mobile networks (ad hoc networks) such as those that might be formed
using Bluetooth wireless communication. In these environments a more dynamic, flexible and
adaptive solution is needed. Graham, Miller and Rusnak [Graham99] observe the growing
incidence of these ad hoc networks and the resulting demand for self-configuring systems:

The emergence of information appliances and new types of connectivity is spurring a new form of
networking: unmanaged, dynamic networks of consumer devices that spontaneously and
unpredictably join and leave the network. Consumers will expect these ad hoc, peer-to-peer
networks to automatically form within the home, in very small businesses and in networked
vehicles.…

To achieve the goals of simplicity, versatility and pleasurability, the appliances and the
network(s) they join must just work right out of the box. By just work we mean that the
participants on the network must simply self configure. By self configure we mean that these
network devices and services simply discover each other, negotiate what they need to do and
which devices need to collaborate without any manual intervention.[5]
[5]
Reprinted by permission from Discovering Devices and Services in Home Networking, copyright (1999) by International
Business Machines Corporation.

Protocols for service discovery can help to enable this self-configuration. Since much of the
interdevice communication in Bluetooth usage scenarios is of a peer-to-peer, ad hoc nature, the
SIG determined that a service discovery protocol in the stack could provide significant value. The
resulting protocol, known as SDP, is a central component of nearly all of the profiles and usage
cases, both existing and foreseen.

The service discovery concept is not new or unique to Bluetooth wireless technology. Numerous
service discovery technologies are available in the industry, some of them well known. As is
evident in other layers of the protocol stack, the SIG is content to adopt existing protocols where
it makes sense to do so. In the case of service discovery, though, the SIG developed its own
protocol unique to and optimized for Bluetooth wireless communication rather than adopting

109
some other service discovery protocol in the industry. The reasons should become evident as we
review SDP's development in the next section.

SDP Development
The need for a service discovery component in the protocol stack was recognized early in the
process of developing the specification, although direct work on SDP did not commence until
later. In early and mid 1998, many of the initial participants in the SIG were focusing on the
transport protocols and key middleware protocols like RFCOMM. While the need for other
protocols had been identified, task forces of experts to develop these protocols had not been
assembled in all cases. In the case of SDP, some preliminary work had been started at Intel and
Ericsson in the summer of 1998.

In early internal versions of the specification, service discovery was a section within the L2CAP
part of the specification. Initially, L2CAP channels were modeled after a computer bus, and
service discovery was concerned exclusively with the transport of Plug and Play parameters over
this virtual bus. In September 1998, at a SIG meeting in London,[6] author Bisdikian suggested
that the addition of a transport protocol for Plug and Play parameters unnecessarily complicated
the L2CAP specification, and that such a protocol merited its own service discovery portion of the
Bluetooth specification.
[6]
To advance the development of the specification, face-to-face meetings among SIG members have taken place in many
different countries reflective of the multinational constituency of the SIG membership.

In October 1998 the SIG held a developers conference in Atlanta which author Miller attended.
Based upon conversations during that conference, Miller was asked to chair the service discovery
task force of the SIG's software working group shortly thereafter. The following month the newly
constituted group met for the first time as a formal SDP task force.

While at this time (late 1998) many of the protocol layers had been under development for
several months, with some of them approaching levels of stability that would soon near final
stages, SDP was still really in a nascent state of forming the requirements and the beginning of a
proposal to address those requirements.

Among the identified objectives for Bluetooth SDP were:

Simplicity: Because service discovery is a part of nearly every Bluetooth usage case, it is
desirable that the service discovery process be as simple as possible to execute. For the SDP task
force this also implied the reuse of other Bluetooth protocols to the extent possible.

Compactness: As described in previous chapters, the formation of Bluetooth communication

links between two devices can in some cases be time consuming. Since service discovery is a
typical operation to perform soon after links are established, the SDP air-interface traffic should
be as minimal as feasible so that service discovery does not unnecessarily prolong the
communication initialization process.

Versatility: The version 1.0 specification includes a number of profiles, and future revisions will
undoubtedly add to the list, which is expected to continue to grow. Since an exhaustive set of
profiles, usage cases and associated services cannot be foreseen or accurately predicted, it is
important for SDP to be easily extensible and versatile enough to accommodate the many new
services that will be deployed in Bluetooth environments over time. To support this objective the
SDP task force chose a very broad definition of "service," so that the widest possible spectrum of
features (services) could be supported in the future.

110
Service location by class and by attribute: In the dynamic ad hoc networking environment it
is important to enable client devices and users to quickly locate a specific service when they
already know exactly (or at least largely) what they are looking for. It should be straightforward
to search for a general class of service (say, "printer"), for specific attributes associated with that
service (for example, "color duplex IBM printer") and even for a specific instance of a service
(such as a specific physical printer).

Service browsing: In addition to searching for services by class or attribute, it is often useful
simply to browse the available services to determine if there are any of interest. This is a
different usage scenario than is searching for specific services, and in some respects it is almost a
contrary objective, but the SIG agreed that both usage models have merit, and they developed a
solution that uses a consistent method to support both specific service searching and general
service browsing.

These objectives led to the development of requirements for a simple, flexible protocol and data
representation for service discovery in the protocol stack. Popular industry discovery protocols
were reviewed, but none seemed to provide a good match for the SDP objectives—many of these
technologies provide robust and comprehensive service discovery and access methodologies, but
the SIG was really looking for a fairly low-level, simple, narrow-in-scope solution that met the
rather modest objectives noted above in a straightforward manner.[7] At this point Motorola®
approached the SIG with a proposal to contribute some technology, suitable for use in Bluetooth
service discovery, that Motorola had had under development for several years. Through a
contributing adopter agreement Motorola was then able to participate in the SDP task force of the
SIG (and in fact the Motorola representative served as editor of the SDP specification), with their
contributed technology forming the basis for SDP.
[7]
Subsequent to publication of the version 1.0 specification, efforts were begun to map some of the leading industry service
discovery technologies to the Bluetooth stack. Chapter 16 gives details of this work.

So with the SDP effort underway in November 1998, the SDP requirements and scope were
agreed upon and the specification development ensued, incorporating the ideas contributed by
Motorola along with the many contributions by the other SIG member companies. Even though
the real SDP work started later than for many other protocols, through hard work the SDP
specification was completed, ratified and published along with the bulk of the other protocols in
the stack in July 1999 in the version 1.0 specification.

The following sections describe some of the key facets of the SDP specification, including why
these elements are significant and the rationale for including them in the specification.

SDP Examined
Key to understanding the development of SDP is to understand its motivation and requirements.
In fact, this information is included at the beginning of the SDP portion of the specification. As
noted above, SDP is intended to allow devices in Bluetooth environments to locate available
services. As the specification states, these environments are qualitatively different from
traditional networks such as LANs or WANs. Devices and services are likely to come and go
frequently in Bluetooth piconets. Thus SDP was developed to satisfy the requirements of such
environments.

Some of the notable requirements for SDP are listed in the preceding section. These are also
mentioned and expanded upon in the specification. Also of interest are those items that SDP does
not attempt to address, at least in version 1.0 of the specification.[8] The "Non-Requirements and
Deferred Requirements" portion of the SDP specification can be summarized largely with the
statement that SDP is narrow in scope, focusing primarily on discovery in Bluetooth environments

111
and leaving more sophisticated service functions and operations to other protocols which might
be used in conjunction with SDP.
[8]
Of these, the Bluetooth SIG might choose to enhance SDP in the future to address some of the issues. Many, however, are
likely to remain outside the scope of Bluetooth SDP, since some of the issues can be and are addressed by industry discovery
protocols, which Bluetooth SDP can accommodate, as explained in the main body text.

SDP includes the notion of a client (the entity looking for services) and a server (the entity
providing services). Any device might assume either role at a given time, acting sometimes as a
service client and sometimes as a service provider (server).

The service provider needs to maintain a list of service records that describe the service(s) it
provides; this list is called the service registry. A service record is simply a description of a given
service in a standard fashion as prescribed by the specification. A service record consists of a
collection of service attributes containing information about the class of the service (which might
be printing, faxing, audio services, information services, and so on), information about the
protocol stack layers that are needed to interact with the service, and other associated
information such as human-readable descriptive information about the service. Figure 8.3
illustrates the general structure of a service registry with its constituent service records. Shown is
a set of services, each with a service record handle (depicted by srvRecHnd[0] through
srvRecHnd[j]) and a set of attributes per service (shown as srvAttribute[0:a] through
srvAttribute[j:c]). Further explanation of the content of these service records follows.

Figure 8.3. General SDP service registry structure.

Service records consist of both universal service attributes and service-specific attributes. The
universal service attributes are simply those parts of the service record that apply to all types of
services, such as the service class and protocol stack information noted above. Service-specific
attributes are those parts of the service record that are relevant only for a specific class or
instance of a service. Examples of service-specific attributes could include attributes specific to a
printing service (such as color, duplex and finishing capabilities), attributes specific to an audio
service (such as data rate or encoding scheme) or attributes specific to a dial-up networking
service (such as serial port configuration or modem setup information). Volume 1 of the
specification includes definitions for a set of universal service attributes (those which could apply
to all types of services), but it does not include service-specific attributes, since it would be
impossible to specify and predict all of the attributes for every imaginable type of service.
Service-specific attributes are defined in profiles (volume 2 of the specification). Since profiles
describe a usage scenario and how the protocol stack is used, they effectively define a service.

112
So, for example, the headset profile defines the service specific attribute "remote audio volume
control" that applies to the headset service. While the universal service attributes can apply to all
types of services, this does not mean that they are mandatory—it is not required that every
service include every universal service attribute in its service record. In fact, only two of the
universal service attributes are mandatory: the service class attribute, which defines the class, or
type of the service, and the service record handle, which serves as a pointer, or reference to the
service record and is used by the client to access the server's service record.

Each service attribute in a service record consists of an attribute identifier (attribute ID, a 16-bit
unsigned integer) and an attribute value associated with that attribute ID. Each entry of the
service record is one of these (attribute, value) pairs. Because these attributes describe all sorts
of information, SDP uses the concept of a data element for the attribute value. A data element is
simply a self-describing piece of data. The first part of a data element consists of a one-byte
header that tells the actual type and size of the data. The remainder of the data element consists
of the data values for the attribute, of the format and size specified by the data element header.
Through the use of data elements, SDP allows attribute values to be of several types, including
strings, Booleans, signed and unsigned integers of various sizes, and universally unique
identifiers (UUIDs, discussed further below). Moreover, these data types can be lists of the scalar
elements noted above, thus providing a flexible representation for the many data types of which
attribute values might be composed.

Discovering a service in Bluetooth wireless communication reduces to a simple operation: the

client specifies the service(s) of interest and the server responds, indicating any available
services that match what the client specified. In practice for SDP this consists of the client's
sending a request in the form of an SDP protocol data unit (SDP_PDU) that indicates what
service(s) it is searching for and the server's sending back a response, also in the form of an
SDP_PDU, that indicates what services match the request that the client has made. To
accomplish this, the client needs a standard way to represent the service(s) of interest and the
server needs a standard method to match its available services against the client's specification.
For this purpose SDP introduces universally unique identifiers (UUIDs).

A UUID is a concept adopted from the International Organization for Standardization (ISO).
UUIDs are 128-bit values that can be created algorithmically and, generally speaking, can be
virtually guaranteed to be entirely unique—no other UUID ever created anywhere will have the
same value.[9] One advantage of using UUIDs is that new identifiers can be created for new
services without requiring a central registry of identifiers maintained by the SIG, although the
SIG does include a list of "well-known" UUIDs in the specification for those services related to the
published profiles. So a client looking for a service just specifies the UUID associated with that
class of service (or with the specific service) in its service search request, and the service
provider matches that UUID against those of the services it has available to generate its
response.
[9]
This concept is sometimes hard to grasp, but universally unique identifiers can in fact be created. While there is an extremely
small chance of duplication, UUIDs as defined by ISO (see [ISO96]) are quite sufficient for the purposes of Bluetooth SDP and
turn out to be quite valuable in this context.

The SDP_PDUs exchanged between the client and server are simple transactions. The general
SDP protocol flow requires only two transactions; the specification defines three different SDP
transactions, but the third is really just a composite of the first two. A typical SDP transaction
consists of:

1. Client sends a request to search for service(s) of interest; server responds with handles to
services that match the request.
2. Client uses the handle(s) obtained in step 1 to form a request to retrieve additional
service attributes for the service(s) of interest.

113
Following the above transaction, the client will presumably use the information obtained in step 2
to open a connection to the service using some protocol other than SDP to access and utilize the
service. Step 1 is called the ServiceSearch transaction and consists of the ServiceSearchRequest
SDP_PDU from the client to the server and the ServiceSearchResponse SDP_PDU in return (from
server to client). As noted above, the ServiceSearchResponse SDP_PDU contains handles to one
or more services that match the request. In step 2, the client presents one or more of those
handles in a ServiceAttributeRequest SDP_PDU which causes the server to generate a
ServiceAttributeResponse SDP_PDU; this exchange is the ServiceAttribute transaction. In the
ServiceAttributeResponse SDP_PDU will be the attribute values associated with the service that
correspond to the attribute IDs that the client specified in the ServiceAttributeRequest SDP_PDU.
These attributes may be a combination of universal service attributes and service-specific
attributes, and in most cases should provide the client with enough information to subsequently
connect to the service.

The specification defines a third SDP transaction, called the ServiceSearchAttribute transaction.
This transaction consists of a ServiceSearchAttributeRequest SDP_PDU from the client to the
server followed by a ServiceSearchAttributeResponse SDP_PDU from the server to the client. It is
actually redundant to the first two transactions described above and is included for efficiency.
What the ServiceSearchAttribute transaction allows is the combination of steps 1 and 2. That is,
the client can form a single request that specifies not only services to search for but also the
attributes to return for matching services in the server's response. The server then responds with
handles to matching services as well as the requested attribute values for those matching
services. An implementer thus has a choice between the two alternatives for SDP transactions.[10]
More importantly, though, the ServiceSearchAttribute transaction may in some cases be more
efficient in terms of the number of bytes transmitted over the air-interface. The consolidated
transaction itself requires more bytes than the individual transactions but could result in fewer
total transactions. Especially in cases where many service records are being accessed, such as in
a service browsing application, the ServiceSearchAttribute transaction might be more efficient.
[10]
It should be noted, however, that different profiles mandate the use of different SDP transactions, so if a profile is being
implemented, the profile will determine which SDP transaction(s) need to be used, and the programming effort to support all
three transactions should not be great.

In a nutshell, this is most of what is needed for SDP transactions. The specification also includes
protocol definitions for special cases, including an error response SDP_PDU and a mechanism,
called the continuation state, for dealing with server responses that cannot fit into a single
SDP_PDU.[11] The syntax of these protocol transactions and the data elements that they carry is
detailed in the specification and is not reproduced here. A unique feature of the SDP chapter of
the specification is the inclusion of several detailed protocol examples as an appendix to the SDP
specification. The members of the service discovery task force of the SIG who developed the
specification felt that because the actual byte streams generated for SDP transactions can be
complex (even though the transactions themselves are conceptually simple), it would be useful to
include the examples as a guide for implementers. The complexity is introduced mostly when
complex data elements (such as DataElementSequences, which are lists of data elements and
which can be nested) are carried in the SDP_PDUs. When these complex data types are included
in SDP_PDUs, or when SDP_PDUs need to be split using the continuation state information, the
various "count" fields that introduce segments of the SDP_PDUs need to accurately reflect the
number of bytes that follow in that segment. The examples in the specification serve to clarify
the correct construction of SDP_PDUs.[12]
[11]
The client can specify the maximum size for the response to its request SDP_PDU. It is possible for the response that is
generated by the server to be larger than this maximum size. In this case, the server includes some continuation state
information at the end of its response, which allows the client to initiate another request to obtain the next portion of the
response, if desired.

[12]
In fact the developers of the specification learned first hand of the need for these examples when they constructed them,
since there were some errors in the first internal versions of the examples. There were even some errors in the examples
published in the original version 1.0A SDP specification, which were subsequently corrected in version 1.0B.

114
Figure 8.4 summarizes the SDP transactions. Shown in the figure are representations of the
relevant arguments and parameters passed in the SDP_PDUs, although these are not complete
lists of all arguments and parameters; the complete syntax is in the specification. As Figure 8.3
shows, only services and service attributes that are described by UUIDs are searchable.
Attributes of a service which are not described by UUIDs are not searchable and can be retrieved
only after a service has been located using a UUID attribute.

Figure 8.4. SDP transaction summary.

SDP Usage
Since SDP was developed primarily for discovering services in Bluetooth environments, the
applications most likely to make use of SDP will be those developed specifically to be aware of
Bluetooth wireless communication (as opposed to legacy applications). One exemplary application
for SDP usage is what we will call the Bluetooth Piconet Minder[13] (or BPM application). Such an
application is likely to be included, in one form or another, in many Bluetooth devices. A BPM
application as we envision it would present a view of available devices and services in proximity
(in a piconet) to the user and to other applications. This could include a user interface; one might
imagine icons or other representations of devices and services. Such an application could give a
user a central point to manage the Bluetooth connections to other devices and to select and
make use of the services offered by those other devices. To support such functions, a BPM
application might make use of service searching and service browsing and thus initiate SDP
transactions to populate the service information that is exposed to the user and to other
applications.
[13]
This term is used generically here and is not known to, or intended to, conflict with any actual product names.

Certainly other applications designed for use in Bluetooth environments might use SDP. Every
profile (or at least every "non-generic" profile that involves concrete usage scenarios) includes an

115
SDP service record to be used when implementing that profile. Applications written specifically to
exercise the protocol stack will probably need to execute SDP transactions to successfully
instantiate the profiles. First, such applications will need to execute SDP transactions with
another device to determine if that device offers the desired service, and if so, those applications
will need to execute additional SDP transactions to obtain the information from the service record
about how to access that service (this can include such information as the required protocol stack
and associated parameters that the service uses).

In the case where multiple applications use SDP (perhaps one or more profile applications and a
BPM application), it may be advantageous to implement a central SDP client and SDP server that
are available to all the applications that need them. These SDP "helper applications" could be
implemented as part of the common services layer that was described in Chapter 5. The
applications could use the platform APIs to access the common SDP services which would
generate the SDP transactions and pass the retrieved information back to the applications.

The Service Discovery Application Profile (SDAP) detailed in Chapter 12 offers guidance for
application interactions with SDP. While, as previously noted, the specification does not define
APIs, the SDAP does define primitive operations that could be mapped to APIs and events on
many platforms, thus providing a basis for SDP common services.

There may be legacy applications that make use of service discovery, but such applications
probably use some other industry discovery protocol (perhaps Jini™, Universal Plug and Play™,
Salutation™, Service Location Protocol, the IrDA service discovery protocol, or some other
protocol). Since SDP was developed for Bluetooth applications, legacy applications would not be
expected to include this protocol without modification to the application. Even for these
applications, though, SDP does offer some accommodation. One of the design points for SDP was
to ensure that other popular industry discovery protocols could be used in conjunction with it.
One of the things that can be discovered using SDP is that the service supports one or more
other discovery protocols. Thus SDP might be used in the initial service discovery phase to locate
the service; further SDP transactions might be used to discover that the service supports, say,
Salutation; once this has been determined, the newly discovered protocol (Salutation in the
example) can be used for further interaction with the service. SDP specifically supports this sort
of operation. A SIG white paper [Miller99] describes how Salutation can be mapped to SDP.
Similar mappings to other technologies should be possible, and the SIG is working toward
formalizing some of these mappings as profiles, as discussed in Chapter 16.

116
Chapter 9. IrDA Interoperability Middleware Protocols
Continuing our examination of the middleware protocols, we now visit those protocols intended to
provide interoperability with IrDA applications. In this chapter we examine the protocols and
conventions that together in the specification are termed "IrDA Interoperability." This term does
not mean that devices with Bluetooth wireless communication can communicate directly with
IrDA devices but rather it refers to protocols that enable common applications to use either form
of wireless communication. The IrDA interoperability middleware includes protocols adopted from
the Infrared Data Association (IrDA), namely IrOBEX (or briefly, just OBEX), its associated data
object formats and the Infrared Mobile Communications (IrMC) method of synchronization. IrDA
interoperability occupies fewer than 20 pages in version 1.0 of the core specification (volume 1),
although over 100 pages are devoted to the IrDA-related profiles in volume 2 (this latter material
is discussed in Chapter 14 of this book). As is the case with RFCOMM, the main reason that the
IrDA interoperability protocols take up only a relatively few pages of the specification is that they
call out existing standard protocols that are fully described in external documentation, in this
case, specifications of the IrDA. IrDA application interoperability is a fundamental design principle
for Bluetooth wireless communication, and thus the IrDA interoperability middleware is a key
element of the protocol stack. These protocol layers are the basis for several profiles which are
likely to become some of the most commonly implemented and widely deployed scenarios on
devices that employ the Bluetooth technology. This chapter examines not only the IrDA
interoperability information in the specification (as usual, attempting to reveal the rationale for
these protocols) but also the similarities and differences between IrDA and Bluetooth wireless
communication, since this latter topic is fundamental to the design basis for the IrDA
interoperability solution adopted for the specification.

The IrDA interoperability protocols reside above other middleware protocols. In particular OBEX
operates over RFCOMM in the standard case and also could operate over TCP/IP as an optional
implementation.[1] Like RFCOMM and SDP, the OBEX session protocol uses a protocol data unit
(PDU) structure, allowing the higher layers of the stack to work with logical data elements at a
higher level of abstraction than that of the packet formats used by the transport protocols or
even by RFCOMM. More importantly, though, OBEX primarily is intended to promote application
interoperability with IrDA, so applications using this protocol with IrDA wireless communication
can adapt easily to the use of Bluetooth links. Figure 9.1 depicts OBEX in the protocol stack. As
shown in the figure, OBEX is used by higher layers of the stack, typically applications, and OBEX
in turn uses other middleware protocols, namely RFCOMM (and optionally, within the constraints
described above, also may use TCP/IP).
[1]
While TCP/IP operation for IrOBEX is described in the Bluetooth specification (volume 1) in the same level of detail as is RFCOMM operation for
IrOBEX, there is no SIG-specified end-to-end TCP/IP solution for version 1.0, since the specification does not address the general use of TCP/IP
over Bluetooth transport protocols. Thus, even though IrOBEX could work over TCP/IP, and the IrDA Interoperability chapter of the specification
describes how to do this, IrOBEX is assumed to operate over RFCOMM throughout volume 2 of the specification because TCP/IP is not fully
specified in the version 1.0 Bluetooth protocol stack. As noted elsewhere, though, TCP/IP can operate over PPP links, and general IP networking
solutions are in progress within the SIG.

Figure 9.1. OBEX in the Bluetooth protocol stack.

117
IrDA and Bluetooth Wireless Communication Compared
Before examining the specification in detail, we first look at the underlying technologies of IrDA
and Bluetooth wireless communication. The objective, after all, for including IrDA protocols in the
stack is to promote interoperability with IrDA applications (hence the "IrDA Interoperability" in
the title of this chapter and in the specification). Here we must clearly state that this
interoperability is at the application layer, not at the physical layer. IrDA interoperability does not
imply that Bluetooth devices can communicate directly with IrDA devices. Instead it is intended
to promote development of applications that can use either transport. uPrevious chapters have
touched on the relationship of IrDA and Bluetooth wireless communication. Here we compare and
contrast specific features of these technologies. Some excellent background reading on this topic
can be found in [Suvak99], which was written by a SIG and IrDA participant.

IrDA is a specific use of infrared light as a communications medium; Bluetooth technology is a

specific use of radio waves as a communications medium. Like the Bluetooth SIG, the Infrared
Data Organization (IrDA) specifies hardware and software protocols for wireless communication
intended to promote interoperable applications.

While both technologies are wireless, they use different parts of the electromagnetic spectrum
with quite different signal propagation characteristics. Since infrared uses the nonvisible infrared
light spectrum, IrDA communication is blocked by obstacles that block light (such as walls, doors,
briefcases and people). The signal wavelength used with Bluetooth communication, at about 12.5
cm, is three orders of magnitude greater than that of IrDA. At this wavelength, 2.4 GHz RF
communications can penetrate these sorts of obstacles. Recent advances in infrared technology
have enabled more diffuse transmission patterns, although much of the IrDA equipment in use
today uses a relatively narrowly focused beam, which usually requires that the two devices
engaged in IrDA communication be aligned with (pointed at) each other. RF transmission
patterns are generally spherical around the radio antenna, so any two devices within range can
communicate with each other whether or not they are "pointed at" each other (in fact, the second
device might not be visible at all to the user of the first device, as it could be in another room
behind doors and walls or even on another floor of a building, for example).

The IrDA specification is more mature than the Bluetooth specification, having been available for
several more years. IrDA technology was already widely deployed when the Bluetooth
specification was first released. Thus IrDA has already undergone several phases of enhancement
that Bluetooth wireless technology might undergo in the future. Among these is some
improvement in communication speed. The initial IrDA data rate of 115 Kbps has now been
enhanced to 1 Mbps, which is comparable to that of the first Bluetooth radios. Today IrDA can
achieve data rates of up to 4 Mbps, with even higher rates already specified. While Bluetooth RF
communication has the potential for similar increased data rates (and the SIG is investigating
these possibilities; see Chapter 16 for more information), it is likely to lag the IrDA speeds for at
least several years.

The effective range for Bluetooth wireless communication is about 10 meters using the standard
0 dBm radio. With optional power amplification of up to 20 dBm, range on the order of 100
meters can be achieved. IrDA range is about 1 meter and, as noted above, generally requires a
line of sight to establish a connection.

Bluetooth wireless technology is designed for very low power consumption, and as compared to
other RF technologies it consumes very little power. IrDA communication, however, consumes
even significantly less power than Bluetooth technology, since far less power is required for
infrared transceivers than for RF transceivers.

118
In terms of cost, IrDA hardware was significantly less expensive than Bluetooth radio modules at
the time Bluetooth technology was introduced. This is partly due to the maturity and wide
deployment of IrDA: the technology has been around long enough that several iterations of cost
optimizations have occurred, and installed IrDA units number in the millions, so economies of
scale resulting from high-volume production have been realized. Bluetooth modules in the year
2000 had not realized either of these forms of cost reduction; even so, it is expected that
Bluetooth hardware is likely to remain more expensive than IrDA hardware[2] owing to the
complexity of the underlying technology, although the cost difference probably will narrow over
time.
[2]
Bluetooth radio module costs in the 2003–2005 time frame are variously estimated to approach $5 U.S.; IrDA solutions are
already well below this figure.

Table 9.1 summarizes these feature comparisons of IrDA and Bluetooth wireless communication.
The table reflects the state of these technologies in the year 2000 and reflects consensus
forecasts in the industry. The table is intended to be illustrative rather than authoritative; certain
parameters will vary from implementation to implementation.

Table 9.1. Illustrative feature comparison of IrDA and Bluetooth wireless

communication. Estimates as of 2000; some values are implementation
dependent.
Feature IrDA technology Bluetooth technology
Connection Line of sight Penetrates obstacles
establishment
Transmission pattern Relatively narrow Relatively spherical
conical
Data rate 4 Mbps 1 Mbps
Range 1 meter 10–100 meters
Power consumption 10 mW (nominal) 100 mW (estimated nominal;
product-dependent)
Transceiver module < $1.00 $5.00 (estimated, approximately
cost 2003–2005)

As explained in the specification and in the following sections, IrDA and Bluetooth wireless
communication share similar application domains, even though the underlying technology used to
achieve scenarios such as object exchange and synchronization is inherently different. Feature
differences may cause one technology to be preferred over the other in certain environments and
applications, although we believe that both have merit and both are likely to be deployed in
pervasive computing devices in the foreseeable future. Thus the IrDA interoperability provisions
of the specification can help to enable the best use of either or both technologies as the situation
warrants.

119
The IrDA Interoperability Protocols
One of the most common applications for IrDA technology is exchanging files and other objects.
This includes exchanging electronic business cards between two devices as well as transferring
files and other data objects between two devices, all in an ad hoc fashion and without wires. The
devices commonly used in these scenarios—especially mobile phones, notebook computers and
handheld computers, but also others[3]—are the same set of devices where Bluetooth technology
is deployed or is expected to be deployed. Even though direct communication between an IrDA
device and a Bluetooth device is not feasible, it seems clear that these same sorts of applications
are quite relevant and useful in Bluetooth environments. In fact, profiles exist in the version 1.0
specification for both object push (which could be used for electronic business card exchange)
and file transfer (which can include transferring several specific object types). An extended
application of this sort of data exchange is synchronization, where the data is not only exchanged
but is also replicated between the two devices. A profile exists for this usage case also, and it too
is based upon the IrDA application and protocols. In volume 2 of the specification, all of the file
transfer, object push and synchronization profiles are derivatives of the generic object exchange
profile, and all of these are described in further detail in Chapter 14 of this book.
[3]
Perhaps including digital cameras and computer peripherals such as printers.

The rationale for IrDA interoperability in Bluetooth wireless communication is to enable the same
applications to operate over both IrDA and Bluetooth links, and the most straightforward way to
do this is to use the same session protocol in both environments. Since the IrDA protocols
already existed and some were suitable for Bluetooth applications, the SIG chose to adopt OBEX
and IrMC in the Bluetooth protocol stack in the same relative position as in the IrDA protocol
stack. Unlike RFCOMM, the IrDA interoperability specification does not include any significant
subsets, alterations, adaptations or clarifications of OBEX, although there are some specific
considerations (such as calling out the specific OBEX version 1.2) noted for its use in the protocol
stack. Much of the description in the specification echoes important elements of OBEX and
describes precisely how OBEX is used over other middleware layers of the protocol stack.

IrDA Interoperability Protocol Development

The reuse of IrDA protocols and specifically OBEX was identified as the design direction of the
SIG early in the specification's development. As with RFCOMM, work was underway on the use of
OBEX and IrDA protocols and data formats at about the time the SIG was publicly announced.
The synchronization usage case was already identified at that time, as were file transfer and data
exchange applications (the latter scenarios at that time were part of the conference table usage
case). In early 1999 the business card exchange scenario had led to the beginning of what is now
the object push profile; file transfer and synchronization were well defined, and work on profiles
for these usage models was also underway. It quickly became evident that a generic framework
profile that applied to all IrDA interoperability usage cases (that is, all those profiles using OBEX)
would be valuable, so the generic object exchange profile also was initiated.

Given the objective of interoperability between IrDA and Bluetooth applications, an initial goal of
the SIG was to produce a specification that would allow a single application to operate seamlessly
over both wireless transports. The SIG was (and is) motivated to reuse existing protocols where
appropriate. These considerations led to the selection of OBEX as the point in the IrDA protocol
stack that could be inserted into the corresponding point in the Bluetooth protocol stack to allow
applications to deal with the same protocol (OBEX) in both environments. With study and
discussion in the SIG it was determined that OBEX could operate both over RFCOMM, which was
reasonably well defined by this time, and over TCP/IP (although the latter is enabled only in
certain circumstances in version 1.0, as discussed below). Other transports for OBEX not directly

120
applicable to the Bluetooth protocol stack include IrSock (infrared sockets), IRCOMM and Tiny TP
(or TTP), some of which are mentioned in passing in the specification.

The OBEX Protocol Examined

IrDA interoperability in general, and OBEX and IrMC in particular, are significant elements of the
protocol stack, yet relatively few pages[4] are devoted to the topic in volume 1 of the version 1.0
specification. OBEX is the basis for several of the version 1.0 profiles and IrDA interoperability is
an important objective and key value of the Bluetooth technology. The IrDA interoperability
specification can be so compact because of the SIG's decision to adopt existing IrDA protocols
that are fully specified by IrDA (the IrDA OBEX specification [IrDA99a] is about 85 pages long
while the full IrMC specification [IrDA99b] is nearly 200 pages, although only a portion of this
latter specification deals directly with IrMC synchronization).
[4]
At fewer than 20 pages, the IrDA Interoperability portion of the specification is easy to read from beginning to end, yet it is a
fairly complete description of how IrDA protocols are used in the Bluetooth stack.

While the specification discusses the use of OBEX over TCP/IP, it does not define how TCP/IP
should operate natively over Bluetooth transports. The fact that OBEX can operate over TCP/IP
will become more important in the future when the SIG defines general TCP/IP operation over
Bluetooth links (as described in Chapter 16). Until such a definition exists, the fact that OBEX can
operate over TCP/IP transports is not directly relevant for version 1.0 implementations.[5] Thus
TCP/IP operation for OBEX is specified as optional.
[5]
Which is not to say that such a stack could not be implemented; in fact, it could. But like all other implementations not based
upon profiles, the risk of noninteroperability exists. Because TCP/IP is such an important protocol, it is safe to assume that
TCP/IP over Bluetooth links eventually will be solved (this is being pursued by the SIG), and thus it is good to know that OBEX
over TCP/IP is already enabled.

The other Bluetooth protocol over which OBEX is designed to operate is RFCOMM. RFCOMM
(detailed in the previous chapter) was designed specifically with OBEX in mind as one of the
RFCOMM clients. Since OBEX over TCP/IP is defined only in the context of PPP for version 1.0, we
focus here on its use over RFCOMM. The specification describes the requirements for the use of
OBEX over RFCOMM. These are not new or unique requirements specific to Bluetooth
environments; rather they define the boundaries within which a generic OBEX application should
operate to ensure that it will work over RFCOMM and thus over Bluetooth transports. Among the
considerations for OBEX over RFCOMM are:

Client and server functions: The specification indicates that both client and server functions
must be supported by devices implementing the OBEX IrDA interoperability protocol. When one
examines the IrDA interoperability profiles (see Chapter 14), it becomes evident that while it is
technically possible for a device to support only a client or only a server role, it is really useful
only when a device can support both roles. Even object push, which is largely a one-way data
transfer, still requires both a client role (in this case the client needs to push the object) and a
server role (in this case the server needs to pull the object). This apparent dichotomy is
explained in Chapter 14.

RFCOMM multiplexing: All OBEX transactions must use a separate RFCOMM server channel (as
described in the previous chapter, only one RFCOMM connection is permitted between two
devices); thus, multiple clients of RFCOMM must use its protocol multiplexing feature. The OBEX
server must open a separate RFCOMM channel connection with a client. Similarly the RFCOMM
connection needs to be terminated when the OBEX session that uses it is terminated. The
specification also describes how to parse the stream-oriented communications that occur over
RFCOMM to delimit the OBEX packet structures contained therein.

121
SDP Support: OBEX applications in Bluetooth environments need to be able to make use of SDP.
OBEX clients need to obtain the relevant information about the OBEX service from its service
record in the OBEX server. OBEX servers need to populate the service record with information
such as the appropriate RFCOMM server channel to use. As described in the previous chapter,
this SDP application enablement might be obtained through the use of common SDP application
services; these need not be unique to OBEX applications.

OBEX provides a session protocol for transactions between two devices. The IrDA defines both
connection-oriented and connectionless sessions; the Bluetooth specification calls for use of only
the connection-oriented sessions, since this is what best fits Bluetooth environments. Like SDP,
OBEX transactions consist of a request PDU issued by the client followed by a response PDU
issued by the server. With OBEX, the client role normally is assumed by the device that initiates
the transaction, while the responding device becomes the server. Also similar to SDP, the OBEX
PDUs consist of a header, a size indicator and the arguments and parameters associated with the
particular transaction. Fundamentally, OBEX is a simple protocol, with the main operations being
connect and disconnect to initialize and terminate sessions, along with get and put operations to
exchange data objects within an existing session. These operations are described in the Bluetooth
specification and detailed in the IrOBEX specification.

In addition to a session protocol, OBEX also serves as an object transport for the data that can be
exchanged in OBEX sessions. To support the IrDA interoperability profiles, the specification calls
out particular object formats as follows:

vCard: format managed by the Internet Mail Consortium [IMC96a] for representing electronic
business cards.

vCalendar: format managed by the Internet Mail Consortium [IMC96b] for representing
electronic calendar and schedule entries.

vMessage: format defined by IrMC [IrDA99b] that represents electronic messages and electronic
mail.

vNote: format defined by IrMC [IrDA99b] that represents short electronic notes.

Volume 2 of the specification calls out each specific object format as it applies to the object push,
file transfer and synchronization profiles. Some of these profiles allow for different versions of the
object types noted above; some also allow for other generic object types to be used with OBEX.

IrMC Synchronization Examined

In addition to transferring data objects over OBEX, it is also quite useful to synchronize these
same objects. Synchronization, generally, is the process of comparing two sets of data and then
updating those data sets so that they exactly reflect (are synchronized with) each other at the
point in time that the synchronization is performed. There are variations on the synchronization
process, such as one-way synchronization where a "slave" data set is always updated to match a
"master" data set, or partial synchronization where only a subset of the data is synchronized, but
in general the idea is to merge the changes made in two (or even more) data sets into each other
so that the data sets become replicas of each other (until additional changes are made to them).
Synchronization allows data (perhaps calendar entries, address books or e-mail) to be
manipulated at various times and places and then be replicated against some other related data
set so that the updates from the data manipulation can be applied. Applications for
synchronization include synchronizing address books to incorporate new, changed or deleted
entries; synchronizing calendar entries to incorporate new and changed schedule items; and
replicating e-mail to send and receive new notes and messages and incorporate saved or deleted

122
messages. Synchronization can be especially useful when these types of data are kept on more
than one device. Address books, calendars and e-mail can be replicated among mobile phones,
handheld computers, notebook computers and network repositories of data so that no matter
which device is used, the data on that device can be current and updates to these data can be
reflected on the other devices through synchronization.

Note that the devices mentioned above are some of the devices most likely to employ Bluetooth
wireless communication. Thus it seems that synchronization is a natural usage case in Bluetooth
environments. Note further that the types of data mentioned above as being common candidates
for synchronization (calendar, e-mail and contact information) are the same data types defined in
the profiles for object transfer over OBEX. Thus it seems evident that it ought to be valuable and
feasible to employ OBEX-based synchronization in the specification, and indeed this is precisely
what the SIG has done. Just as with object transfer, the SIG has chosen to adopt the method
defined by the IrDA, called IrMC synchronization. IrMC synchronization builds upon the OBEX
session protocol and certain object formats (including some object formats defined by IrMC itself)
to specify a method of synchronizing these objects. As with OBEX, the specification incorporates
IrMC synchronization as a way to enable IrDA application interoperability.

The core specification (volume 1) includes very little information about synchronization per se,
focusing instead on the use of OBEX in Bluetooth wireless communication. It does, however,
briefly describe Bluetooth synchronization when discussing the synchronization profile, which is
where the details can be found. Essentially IrMC provides a framework for OBEX-based exchange
of data; given this capability to exchange data formats including those noted above, additional
logic can be applied to perform differencing and selective object transfer, thus accomplishing
synchronization using the IrMC framework within OBEX sessions. Chapter 14 more fully explores
Bluetooth synchronization.

IrDA Interoperability Usage

The IrDA interoperability information in the core specification (volume 1) includes a description of
the related profiles found in volume 2 of the specification. In fact, since IrDA interoperability is
really about application interoperability, there is a larger amount of information (over 100 pages)
on this topic in the profiles than in the core specification. Recall that IrDA interoperability just
makes reference to existing IrDA specifications and describes how to use these standards in
Bluetooth environments.

The reuse of IrDA protocols, along with the fact that these protocols operate over RFCOMM (a
serial port abstraction), is intended to facilitate the use of existing IrDA applications in Bluetooth
environments. IrDA applications are familiar with the use of serial port communications and are
likely to have support for OBEX protocols. By accommodating these IrDA interoperability layers in
the Bluetooth stack, the SIG has paved the way for applications that can operate with both IrDA
and Bluetooth wireless communication.

123
Chapter 10. Audio and Telephony Control
Support for voice or, more generically, audio is a distinguishing attribute of Bluetooth wireless
communication. With support for both voice and data, the technology is well positioned to bridge
the domains of computing and communications, as evidenced by the enthusiastic support for the
Bluetooth technology within both industries. Several of the profiles address scenarios in which
both a computing device and a telephony device are used. This chapter, our final in-depth
examination of the core specification, deals with the components of the protocol stack that enable
telephony and voice (audio) communication. The telephony control protocol is embodied by the
TCS-BIN (or just TCS for short) layer, while audio can be carried natively over the baseband. TCS
is based upon the existing ITU-T Q.931 protocol [ITU98], but even so it occupies over 60 pages
in the specification. TCS is a binary encoding for packet-based telephony control and resides
above the L2CAP layer of the stack. TCS-BIN is sufficient to realize the version 1.0 telephony
profiles, although applications using AT commands over the RFCOMM serial port abstraction
(including headset, dial-up networking and fax) might also accomplish a form of telephony
control (this latter form of telephony control is not included as a separate entity in the version
1.0 specification; it is discussed further in subsequent sections here). Audio is not a layer of the
protocol stack per se but rather a specific packet format that can be transmitted directly over the
baseband layer. Since audio is frequently (although not exclusively) associated with telephony
applications, it is discussed together with TCS in this chapter as a logical convenience. This
chapter examines telephony functions, including audio, in Bluetooth wireless communication. As
in preceding chapters we will not only provide highlights and interpretations of the specification
but also touch upon the background information for these elements of the protocol stack,
including the evolution of TCS-BIN.

Figure 10.1 depicts audio and TCS-BIN in the protocol stack; it also shows the component we call
AT Command Telephony Control. This latter component is a remnant of what was once called
TCS-AT and is explored further below. In general, when we refer simply to TCS we mean the
TCS-BIN layer of the stack. TCS-BIN resides above L2CAP; audio communicates directly through
the baseband; and AT command telephony control operates over RFCOMM. Telephony control
applications can communicate directly with TCS-BIN and might also use AT command telephony
control.

Figure 10.1. Audio and TCS-BIN in the Bluetooth protocol stack. Also shown is
the AT command based form of telephony control used by some applications.

124
Audio and Telephony Control Operation
TCS-BIN is used for the call control aspects of telephony, including establishing and terminating
calls along with many other control functions that apply to telephone calls. TCS can be used to
control both voice and data calls. When a voice call is made the audio element of the stack is
used to carry the its content; in the case of data calls the data content can be carried over the
transport layers of the stack (perhaps also involving other middleware layers). The call control
functions provided by TCS-BIN can be used no matter what the call content (voice or data) is;
data calls like those used with the dial-up networking profile are supported and so is voice
telephony, like that used for the cordless telephony and intercom profiles.

TCS-BIN also defines a method for devices to exchange call signaling information without actually
having a call connection established between them; this is called connectionless TCS and is
described more fully below. Another aspect of TCS-BIN is that of group management functions.
When there is a group of devices that all support the TCS-BIN protocol, the members of the
group (called a wireless user group, or WUG) can make use of some special functions defined by
TCS, including group membership management, telephony service "sharing" among devices in
the group and a method for a fast direct connection between two group members. The TCS-BIN
call control and other functions are examined more fully below.

A second form of call control, which we have called AT command telephony control, was
introduced above. While it is not defined as a named protocol in the specification, it is mentioned
here because it is a well-known method for accomplishing call control, and it is used by several
profiles. In fact, at one time this concept was embodied as a separate protocol and element of
the stack called TCS-AT. While TCS-AT is no longer defined as a separate entity (and indeed,
given the existence of TCS-BIN, a separate SIG-defined TCS-AT protocol is unnecessary, as
described more fully below), it is worth acknowledging that this sort of telephony control does
exist in many Bluetooth environments. AT commands are modem control commands that are
likely to be used especially by legacy applications; these applications typically are configured to
communicate with a modem over a serial port. Within the Bluetooth protocol stack these
applications could use RFCOMM to communicate with a compatible modem service using the
same AT command call control functions as in other environments, with little or no change to the
application (especially through the use of a Bluetooth adaptation layer as described in Chapter 5).
TCS-BIN is the only telephony control protocol defined as a separate entity in the specification,
and it is the protocol upon which several telephony profiles are based. However, AT command-
based telephony control is also used in the headset, fax and dial-up networking profiles, even
though no separate AT protocol is specified by the SIG.

Audio, as already pointed out, is not really a layer of the protocol stack. In fact it would not be
unreasonable to consider audio as a specialized sort of transport layer, since it is largely
embodied as a particular packet format that is sent and received directly over the air-interface
using the baseband protocol. Indeed, outside the baseband chapter, the specification directly
addresses audio only in an appendix that is fewer than ten pages long! Yet we have established
that voice support is a key differentiating value of Bluetooth wireless communications, and clearly
audio directly supports voice (voice and audio are often equated, although voice is not the only
form of audio). So why does the specification not contain a chapter on audio with a description
and page count commensurate with the importance of audio for Bluetooth applications? The
answer has already been suggested: because Bluetooth audio is really just a specification of a
packet format and an encoding scheme for the data in those packets, it does not require a
lengthy explanation. Once the allowances (including time slot reservation and audio packet
definition, described more fully in Chapter 6) have been made at the baseband layer to support
audio traffic, little more specification is required. In fact the actual bulk of the audio specification
can be found in the baseband chapter of the specification, which even includes a section devoted
entirely to audio baseband traffic. Thus to fully understand Bluetooth audio one should

125
understand the baseband protocol stack layer, described in Chapter 6 of this book. However,
because audio so often is associated closely with voice and thus with telephony, it is logically
consistent to discuss it here along with the other telephony-related functions.

TCS Protocol Development

Telephony control is intertwined with audio functions, and in fact it was audio that drove the need
for telephony control rather than the other way around. Before there was a TCS working group, it
was agreed that the protocol stack needed to support audio so that voice as well as data traffic
could be enabled. At first the audio requirement pointed out the need for some control functions,
which initially were presented as "audio control" functions. These audio control capabilities were
needed to support the ultimate headset, speaking laptop and three-in-one phone usage models
(described in Chapter 3), and initially just a small set of simple operations (such as make a call,
answer a call, terminate a call and adjust volume) was envisioned. As the telephony profiles
(including those noted above along with dial-up networking and fax) were further developed, it
became evident that a richer set of telephony control functions was desirable and a working
group was formed to define these capabilities for the protocol stack.

With the initial recognition of a need for minimal audio control functions early in the SIG's
history, it was at first supposed that these simple operations would be accomplished via AT
commands using the RFCOMM serial port abstraction (recall that RFCOMM was fairly well defined
even at this early stage). Thus was born the TCS-AT specification. This specification was intended
to describe how standard AT commands could be mapped over the Bluetooth protocol stack and
to define any new AT commands required for Bluetooth wireless communication. TCS-AT was
designed to support legacy applications that send and receive AT commands over a serial port
(most likely using a serial cable). TCS-AT of course specified the use of RFCOMM as the serial
port replacement. As the specification progressed, it became apparent that there was very little
need for any new AT commands specific to Bluetooth environments (only two new AT command
responses were identified as being useful enough to propose specific definitions for Bluetooth
TCS-AT). Thus the TCS-AT specification became a short reference that described how to use AT
commands in the Bluetooth protocol stack, and its definition was absorbed into the profiles that
use AT protocols (namely headset, fax and dial-up networking).

In the meantime a binary, packet-based telephony control protocol was also being defined within
the Bluetooth protocol stack. Called TCS-Binary (or TCS-BIN), it was adapted from an existing
ITU-T specification, Q.931 [ITU98]. As in other cases, the SIG's adoption of existing standards
provided benefits for the protocol stack, in this case including the capability for robust telephony
control operations in a standardized manner. In early 1999 it was observed that the likely future
direction for telephony control applications was along the lines of the TCS-BIN (ITU-T) style, and
it was further observed that TCS-BIN provided all of the functions necessary for all of the
telephony-based profiles. Finally it was also observed that the TCS-AT specification did not
provide significant new functions specific to Bluetooth environments and primarily specified a
method by which legacy applications might use standard AT commands over RFCOMM as a
means of cable replacement. Thus TCS-BIN subsumed TCS-AT as a separate protocol in the
stack. The SIG decided to remove TCS-AT as a separate specification, although the functions
were not removed; only the name was. Thus the version 1.0 specification does not mention TCS-
AT,[1] although several applications in fact do use RFCOMM as a serial transport for AT commands
in cases where a modem service supports such a configuration. Indeed, the headset, fax and
dial-up networking profiles use AT command telephony control. With only TCS-BIN being
explicitly mentioned in the specification, all further references to TCS herein imply TCS-BIN.
[1]
Actually there is one "leftover" reference to TCS-AT in the Bluetooth Assigned Numbers appendix of the specification, the
last remnant of TCS-AT's former existence as a separately described protocol. As defined there, the value could be used to
indicate a device's support for AT command telephony control.

126
The TCS Protocol Examined
In addition to what the specification calls TCS supplemental services (including caller
identification information and dual tone multi-frequency [DTMF] tone generation), TCS defines
three major functional areas:

• Call control
• Group management
• Connectionless TCS

Each of these is explored below. The majority of the more than 60 pages of specification devoted
to TCS deals with the detailed syntax and semantics of TCS-BIN, which are not reproduced here.
Instead we highlight some of the important features and nuances of TCS-BIN in the protocol
stack.

TCS Call Control

The TCS call control functions serve to set up calls that subsequently will carry voice or data
traffic. TCS acts as a state machine, performing the operations necessary to progress a call from
one state to the next, and tracking the resulting state. When making calls, these operations
might include such things as setting up the call, including dialing information; establishing and
confirming a connection; and disconnecting when the call is complete. For received calls, the
states and transitions include call presence (ringing), call acceptance and connection
establishment and termination. Much of the TCS chapter of the specification is devoted to a full
explanation of these states and their transition operations; the appendix to the TCS chapter of
the specification details these states and transitions in comprehensive state diagrams.

The telephony control functions can operate not only in a point-to-point network topology but
also in a point-to-multipoint configuration. The multipoint environment is relevant, as pointed out
in the specification, for incoming calls when numerous phones all need to receive the incoming
ring signal and control information. In this case, TCS uses multipoint signaling to alert all the
telephones of the incoming call; it can then establish a single content channel (where the voice or
data traffic will flow) with the telephone that answers the call.[2] TCS does not deal with the
content that is subsequently streamed over the channel but only with the call control functions
that occur on the control channel.
[2]
The need to transmit ring signals simultaneously to multiple telephone handsets was a primary motivation for including group
abstraction and management and connectionless channels in L2CAP. These features could certainly be utilized in other future
scenarios, but in version 1.0 they are used only in the context of TCS-BIN.

Unlike RFCOMM, in which a single instance of the protocol layer is multiplexed, the specification
indicates that multiple instances of TCS may be executed at the same time to handle multiple
calls (recall that Bluetooth wireless communication permits up to three voice channels
simultaneously over the baseband). Multiple instances of TCS simply use multiple L2CAP
channels.

TCS Group Management

Group management functions use the concept of a wireless user group (or WUG). Such a group
can use the TCS group management functions to allow for groups of devices to take advantage of
some special functions that TCS enables. These functions include a method for one device to
make use of the telephony services of another device in the group; a way to manage group
membership (called configuration distribution); and a way for two slave members of the group to
use the TCS protocol to establish a direct connection (called fast intermember access).

127
Group management is useful in telephony applications to enable the provision of the sorts of
telephony functions that many users expect, such as multiple telephone extensions, call
forwarding and group calls. In addition, group management can help to accomplish parts of the
three-in-one phone profile by permitting phones to join a WUG (thus enabling a cellular phone to
be used as a cordless phone) and to directly communicate with other TCS devices (thus
permitting the intercom or "walkie-talkie" function).

A WUG is just a group of devices that all support TCS. The specification makes special provisions
for security within the WUG by allowing the WUG master to distribute keys used specifically for
communications within the WUG, including communication with the master and separate
communication (using a different key) with other WUG members as is done with the fast inter-
member access described below.

One device in a WUG can request to use the telephony services of another device in the WUG;
TCS calls this an access rights request. A handset might request the use of the telephony services
of a base station to make a call, or an access rights request might be used to transfer a call from
one TCS device (such as a handset or headset) to another.

Configuration distribution is the TCS-BIN method for managing the membership of the WUG.
Again using the concept of a WUG master that maintains all of the information about the WUG,
TCS-BIN defines a protocol for the WUG master to send updated WUG configuration information
to each WUG member, each time that configuration information changes. For example, this might
be used to inform all WUG members that a new member has joined (or that some member has
left) the WUG. Among other applications, this feature could be used to support the three-in-one
phone profile by advising WUG members (perhaps stationary handsets and base stations in a
home) that a new member (say, a mobile phone brought into the home) has joined the WUG.
Thus the mobile phone's presence is known and it can contact the base station (to act as a
cordless phone) or it could directly contact other phones in the WUG (to act as an intercom).

Fast intermember access is a facility by which any two WUG members can quickly establish a
connection with each other. This feature makes use of the fact that two members already belong
to a WUG and have already established connections with a common WUG master. Thus all WUG
members are already in a single piconet, all using the same hopping sequence established by the
WUG master's clock. Furthermore, via the configuration distribution noted above, all WUG
members can know about all other WUG members. Because all of this information is already
known, it can be leveraged to establish a connection with another WUG member more quickly
than such a connection could be established from scratch. With fast intermember access, a WUG
member uses the configuration information to determine another member with which it wishes to
establish contact. It forwards this information to the WUG master, which in turn contacts the
target WUG member. That member then responds to the WUG master, includes its own clock
offset information in the response, and then places itself into a page scan state. The master
forwards the clock offset information to the requesting WUG member, which can then very
quickly use this information to establish a connection with the target member by paging that
member (which is now in page scan state to accept such pages), the result being a new piconet,
consisting initially of the two devices. This scheme takes advantage of the other features that are
already in place for a WUG to enable quick direct connection between any two devices in that
WUG to support, for example, the "walkie-talkie" function of the three-in-one phone profile.

Connectionless TCS

Finally, TCS-BIN also provides a way for devices to exchange call signaling information without
actually placing a call or having a TCS call connection established. This is called connectionless
TCS. Connectionless TCS provides a sort of "sideband" in which devices within a WUG can send
messages to each other without having to have a TCS connection established between them.
What sort of messages might these devices want to send? The specification defines only a single

128
message format for connectionless TCS called CL Info. CL_Info messages in turn can contain only
two types of information: audio control, used to specify information about microphone gain and
speaker volume settings, and company information, which is the common TCS way to allow any
information not specified in a standardized TCS format to be interchanged. Thus it can be seen
that connectionless TCS could be used to manage the audio settings of all members of a WUG as
well as to communicate product-specific features, defined by the manufacturer, among all of the
devices from that manufacturer in the WUG. Such use of connectionless TCS might allow, for
example, advanced telephony features to be used between a base station and a handset from the
same manufacturer that might not be available to handsets from another manufacturer (although
through standard TCS operations the basic telephony functions would be expected to work within
the WUG with all handsets).

Bluetooth Audio Development

There was no audio working group per se within the SIG. Audio has been an inherent part of
Bluetooth wireless communication since its inception and thus has always been integrated into
the fundamental design of the protocol stack. Audio (voice or other audio) is carried over SCO
links at the baseband layer. These basic SCO links were already defined early in the SIG's
history, shortly after it was publicly announced (the addition of multiple SCO connections to
support multiple voice channels was introduced in mid-1998).

This evolution of Bluetooth audio mirrors its situation within the stack: it is not a distinct protocol
layer but rather a fundamental part of the technology. Audio essentially is integrated into the
baseband. Owing to a few specific considerations for audio in the protocol stack we discuss it as a
separate topic. And as noted above, due to audio's affinity with telephony, for pragmatic reasons
we discuss it in this chapter.

Bluetooth Audio Examined

A quick scan of the specification searching for audio information is likely to locate only Appendix
V, "Bluetooth Audio." This appendix contains information interesting mostly to audio and sound
engineers, including such things as recommended sound pressure, loudness and audio levels.
Although important, it is not the fundamental information about how to deal with Bluetooth
wireless audio traffic. That information, as might be expected from preceding discussions, is
actually found in the "Bluetooth Audio" section of the Baseband chapter of the specification.

While audio in Bluetooth wireless communication need not be used exclusively for voice, its
design is optimized for voice content. Sound tends to be continuous for periods of time and is
thus isochronous, or time limited. The transmission rate for Bluetooth audio traffic is set at 64
Kbps, chosen to be sufficient for normal voice conversations. While the communication of other
audio media (say, music) over Bluetooth audio links is not precluded, the design is not based
upon such audio traffic; it clearly is centered around voice traffic.

Two types of encoding schemes are specified for Bluetooth audio. The first is pulse coded
modulation (PCM) with either of two types of logarithmic compression (called A-law and µ-law)
applied. PCM audio with these compression types is well known and widely used for general
audio, including things like short sound clips. The second audio encoding scheme is continuous
variable slope delta (CVSD) modulation. The characteristics of typical voice conversations, which
have a more predictable continuity than general audio (music, for example), make a delta-slope
prediction more efficient. CVSD generally is also more tolerant of communication errors. Thus
CVSD, in general, is a more effective and efficient (and thus generally preferred) method to use
for Bluetooth audio communication; we observe once again that this is an optimization for voice
versus other forms of audio.

129
The specification says little else about audio as a topic unto itself. The remainder of what needs
to be specified (and what implementers and others may wish to understand) about audio can be
gleaned from a study of the baseband protocol, including the SCO packet structure and timing
designed specifically to support audio traffic simultaneously with data traffic. This information is
found in the baseband chapter of the specification and in Chapter 6 of this book.

One final note about audio: it should be clear that Bluetooth audio as described here and in the
specification is digital isochronous (effectively streaming) audio traffic that operates directly over
the air-interface using the baseband protocols. Of course audio information can also be encoded
in a digital packet-based format[3] using local recording and playback. Such digital audio
information clearly could be transmitted over Bluetooth links using the L2CAP layer of the
protocol stack, but this is quite different from what we refer to here as Bluetooth audio.[4]
[3]
Such as WAV and many other fundamentally similar representations.

[4]
For one thing, it is not truly isochronous, at least not in a streaming, over-the-air fashion. For another, most encoding
schemes for such digital packet audio are designed so that many types of audio (music, sound clips and so on) can be
effectively rendered, rather than optimizing the audio content for one primary use such as voice.

Audio and Telephony Control Usage

Several families of telephony applications are possible. TCS-BIN is intended to support
applications that realize the Bluetooth telephony-based profiles: cordless telephony and intercom.
These are the only two profiles technically classified as telephony profiles, based upon their usage
of TCS-BIN. Such applications are expected to use TCS-BIN directly, as depicted in Figure 10.1.

Other sorts of applications also might be considered in some respects to be telephony

applications; these include dial-up networking, fax and headset profile applications. In volume 2
of the specification these profiles are considered to be part of the serial port profile family; this is
because the telephony facets of these applications tend to use the programming model of AT
commands over a serial port (RFCOMM in the Bluetooth wireless communication case), as
described earlier in this chapter. Although not TCS-BIN based, we also consider these
applications in general to be telephony applications, and they are depicted in Figure 10.1 as such
(that figure shows telephony applications using both TCS-BIN and AT commands over RFCOMM).

Legacy applications are likely to use AT command telephony control, since this is the typical
programming model in the world of serial cables. New applications developed specifically to make
use of Bluetooth wireless links, though, are encouraged via the specification to make use of the
TCS-BIN protocol, which provides a robust set of telephony control functions based upon an
existing standard that has been adapted for the Bluetooth stack.

Telephony and audio, particularly voice audio, play important roles in the Bluetooth stack. With
their associated applications (which may involve both computing and telecommunications devices
in some profiles and usage models), they provide a distinguishing feature of Bluetooth wireless
communication.

130
Part 3: The Bluetooth Profiles Examined
Having examined the Bluetooth core specification in Part 2, we continue in Part 3 with an
examination of volume 2 of the specification, known as the profiles. We begin inChapter
11 with an overview of the profiles and their interrelationships, including the rationale for
our own grouping of the profiles in this book. The remaining chapters then explore each of
the published profiles in logically related groups.Chapter 12 discusses the fundamental
generic access and service discovery application profiles.Chapter 13 explores the profiles
that deal with telephony functions (cordless telephony, intercom and headset),
whileChapter 14 describes the family of serial port related profiles (basic serial port, object
push, file transfer and synchronization). FinallyChapter 15 examines the profiles related to
networking, namely the dial-up networking, LAN access and fax profiles.

Part 3, like Part 2, is designed to summarize important information from the Bluetooth
profile specification, making that information more accessible and understandable.
Drawing on our experience in the Bluetooth SIG, we attempt here to expose the
motivation and rationale for key elements of volume 2 of the Bluetooth specification.

Chapter 11. The Bluetooth Profiles

Volume 2 of the specification consists of the profiles. These are intended to promote
interoperability among many implementations of the protocol stack that is specified in volume 1.
In this chapter we discuss the general nature of the profiles—the rationale for generating them,
their history and evolution and the interrelationships among them. Each of the version 1.0
profiles is then examined in more detail in subsequent chapters.

The Version 1.0 Profiles

Profiles spring from usage cases. Chapter 3 discussed the usage scenarios that were part of the
development of the version 1.0 specification (although not all usage cases resulted in a
corresponding profile for version 1.0). Many of the profiles can be grouped together based upon
the shared elements of their usage scenarios; this is how the profiles are grouped into chapters in
this part of the book. The profiles also can be grouped into families based upon their technical
underpinnings; in many cases these map in a straightforward manner to usage scenario
relationships, although in other cases the technical relationship (for example, of fax to headset) is
not so obvious. Furthermore, the version 1.0 specification contains additional profiles that do not
directly embody usage cases. These include the generic access profile, the service discovery
application profile, the generic object exchange profile and the serial port profile. Each of these
profiles can be considered a transport profile which defines a common basis of shared
characteristics upon which other application profiles can be built (or, in object-oriented
terminology, these profiles are classes from which other profiles, or subclasses, inherit).

Figure 11.1 depicts the version 1.0 profile families based upon their technical relationships. A
similar figure appears in multiple places in volume 2 of the specification. That figure depicts these
relationships in a "nested container" sort of representation, while Figure 11.1 uses an object
hierarchy representation, but both diagrams convey the same information. The abbreviations in
parentheses in the figure introduce the shorthand nomenclature that is used in the remaining
chapters of Part 3 to name the profiles. These abbreviations are used for convenience; in some
cases (but not all) they are consistent with similar abbreviations for the profiles that are used in
the specification.

131
Figure 11.1. The Bluetooth version 1.0 profile families, based upon protocol stack relationships, in
class hierarchy representation.

This chapter describes each of the profiles according to the relationship shown in Figure 11.1. The
remaining chapters of this part of the book, though, examine the profiles in logical groupings
based upon the relationships of the services that each profile provides. There are multiple ways
of viewing several of the profiles and thus there are multiple ways to group the profiles. This
chapter presents one such grouping, that of the technical elements shared among profiles (which
is consistent with the version 1.0 specification, although it does not propose any overt grouping
at all other than including a different representation of the figure shown above). Figure 11.2
depicts the logical, service-based grouping that we use in discussing these profiles in subsequent
chapters. One example of these multiple viewpoints is that of the headset profile. As depicted in
Figure 11.1 in the profile hierarchy, headset is a derivative of the serial port profile. However,
from a functional or services point of view the headset profile could be considered to be part of
the telephony profile group, as shown in Figure 11.2, and thus we include it in Chapter 13 along
with cordless telephony and intercom. Another example is that of the fax profile, which from a
technical perspective is also a serial port profile derivative. Our treatment of the fax profile in this
book, though, is alongside that of the dial-up networking and LAN access profiles, as part of what
we consider a "networking" category,[1] a group which the specification does not address.
[1]
While it may not be obvious how a fax profile fits within a networking category, consider that the fax usage scenario, like dial-up networking and
LAN access, uses a Bluetooth device as a "gateway" to a wide area network for data communication. Chapter 15 further elaborates this point.

Figure 11.2. The Bluetooth version 1.0 profiles, based upon logical service-based groupings.

132
This discussion and the figures are intended only to point out that there are multiple ways in
which to categorize the version 1.0 profiles. The choice of which method to use is probably best
made depending upon the purpose and circumstances surrounding the need to group the profiles
in the first place, and most distinctions are not likely to be drastically different. However, because
the number of profiles is expected to grow over time, with the SIG already planning to add quite
a few new ones (as discussed in Chapter 16), the act of grouping the profiles becomes more
advantageous, and the different ways of doing so should not be confused.

Generic Profiles: This group is composed of the generic access profile, which is the root of all
profiles, and the service discovery application profile, which provides a framework for mapping
from the application layer to the SDP layer of the stack.

Telephony Profiles: In the object hierarchy view, these are the profiles that imply the use of
TCS-BIN for telephony control functions. This group includes the cordless telephony and intercom
profiles (in Chapter 13 we consider the headset profile in the telephony group also, although from
the technical perspective it is part of the serial port group).

Serial Port Profiles: All of the remaining profiles are part of the serial port group. However, this
group is further subdivided. Direct derivatives of the serial port profile are the dial-up networking,
fax, headset and LAN access profiles; as well as the generic object exchange profile. The
latter in turn is the parent of the remaining object exchange group profiles, namely file transfer,
object push and synchronization. While we treat this latter group (the object exchange profiles
along with the basic serial port profile) identically in this book, some of the other members of the
serial port profile family are categorized differently. Specifically, as already noted, the headset
profile is examined in the telephony group, and the remaining serial port profile family
members—fax, LAN access and dial-up networking—are treated as a networking family, which is
examined in Chapter 15.

Part 3 Chapter Organization

In each of the remaining chapters of Part 3 we examine a group of profiles as described above.
Each chapter is organized such that it addresses:

• the common elements of the profiles in that group;

• the history of each profile; and
• an examination of each profile, including how it maps to the protocol stack and how
applications might use it.

In addition, wherever possible, we offer insight about the rationale, design thought process and
future possibilities of the profiles based upon our participation in the SIG when the profiles were
being developed.

133
Chapter 12. The Generic Profiles
Our examination of the profiles begins with two that we call the generic profiles because they are
fundamental to Bluetooth wireless communication. The generic access profile, or GAP, is the basis
for all other profiles. It describes the fundamental operations necessary for two Bluetooth devices
to establish communication, including the discovery of devices, link establishment and
configuration and security considerations. The GAP is tightly coupled with the group of Bluetooth
transport protocols described in Chapters 6 and Chapters 7. The service discovery application
profile, or SDAP, describes fundamental operations necessary for service discovery, an operation
often performed soon after a communication link is established. The SDAP maps directly to the
service discovery protocol (SDP) described in Chapter 8.

Most Bluetooth devices are not expected to implement all of the profiles. A data access point, for
example, probably would not implement telephony profiles, while a headset device is unlikely to
implement networking profiles. However, nearly all devices are expected to implement both the
GAP and SDAP; in fact, it is mandatory for all devices to comply with the GAP. Also, the use of
SDP over the group of Bluetooth transport protocols follows the corresponding guidelines outlined
in SDAP. These two profiles do not describe a specific usage case per se but rather define basic
functions that are necessary (or at least highly desirable) for all devices.

Relationships
The relationship between these two profiles may not be evident upon a cursory examination of
the specification. Each deals with considerations that are mostly relevant to different layers of the
protocol stack. The GAP largely addresses lower-layer protocols involved in the most basic
Bluetooth communication functions, while the SDAP focuses primarily on items of interest to
higher-layer applications. However, these two profiles also share many traits.

Neither the GAP nor the SDAP addresses a specific usage case. Many of the other profiles, like
synchronization or cordless telephony, deal with specific, concrete end-user scenarios. For the
most part, the topics covered in the GAP and SDAP are not visible to an end user (with some of
the application interactions excepted), but these profiles define procedures and protocol usage
that are necessary to accomplish all of the other profiles. Indeed, this is why the GAP is the basis
for all other profiles and why its inclusion in Bluetooth devices is mandatory. Similarly, the SDAP
defines methods for exercising protocols for the purpose of service discovery, and service
discovery is a component of nearly all of the other profiles. In some respects, the GAP and SDAP
both define "invisible" operations that are necessary for all other profiles and thus enable those
other profiles.

Even though the GAP and SDAP are concerned primarily with low-level communication functions,
each also has an application facet and thus some degree of visibility to an end user. While much
of the interaction these profiles specify can occur in an automated fashion, mostly hidden from
the user, some operations might involve the end user as well. Examples include "browsing"
applications[1] that present information about devices and services within proximity, and the
presentation to the user of various options available, such as the degree of security to be used
for a particular communication link. In such cases a user interface or application programming
interface could be associated with these profiles. Nevertheless, the device and service discovery
and connection management is always performed in accordance with the specifications of the
GAP and SDAP.
[1]
One example is the "Bluetooth Piconet Minder" application described in Chapter 8.

134
The overall profile creation process started late in the development of the specification, when it
was realized that application interoperability could be best achieved through a formally specified
way to facilitate it. Moreover, the GAP and SDAP were the last profiles to start being developed.
The reason for their late start is that they both establish a basis for all other profiles, and hence
their need became apparent only after common patterns emerged within the other profiles. The
SIG realized that the Bluetooth community would be served better if these common patterns and
procedures were grouped into separate documents for ease of reference. This reasoning led to
the development of the serial port and object exchange profiles as well. More details on the
development of the generic profiles are given within each profile presentation, starting with the
GAP discussion that follows.

The Generic Access Profile

The Generic Access Profile, or GAP, forms a common basis for all Bluetooth profiles and hence for
the common interoperable usage of the group of Bluetooth transport protocols. One of its
important contributions is its definition of a standard set of terminology. Chapter 8 of the GAP
contains four pages of standard terms with crisp definitions. Having this common vocabulary
helps to remove ambiguity in all of the profiles, which is a key element in enabling interoperable
implementations-and interoperability is the overarching goal of the profiles in the first place.

With this common terminology in place, most of the GAP is devoted to defining the procedures
necessary to establish Bluetooth connections. This includes device and name discovery, inquiry
procedures, pairing and bonding (explained below), and link, channel and connection
establishment. For all of these considerations, the GAP provides common and standard
procedures, in some cases including flowcharts. The importance of defining the fundamental
communication operations cannot be overstated: without well-defined, interoperable methods for
basic communication between devices, none of the other profiles could be realized.

GAP Development
Because the GAP is the root of all of the profiles, it is natural to assume that it was the first
profile developed. In fact, the opposite is true: it was one of the last to be defined by the SIG. To
understand why, one must understand the history of profile development in the SIG.

As described in Chapter 1, the SIG's software working group was organized into task forces that
focused on developing one protocol or a set of related protocols. In January 1999 the topic of
profiles was first discussed in depth within the SIG. Profiles were suggested, and later adopted,
as a means to formalize the Bluetooth usage scenarios and to ensure interoperability among
multiple implementations of the protocol stack. Thus the initial set of profiles was based upon the
same usage cases that drove the marketing requirements document, which in turn drove the
development of the protocols. The responsibility for developing the profiles initially fell to the
same task forces that developed the corresponding protocols. For example, the headset and
cordless telephony profiles were developed by those who defined the TCS-BIN protocol; the serial
port profile was written by the same people who defined RFCOMM; and the object push and
synchronization profiles were developed by the group that specified the IrDA interoperability
protocols. Later the SIG formed an interoperability working group, separate from the software
working group, to focus exclusively on the profiles and related issues, although the participants in
the interoperability working group in many cases were still those who helped to develop protocols
in the software working group.

In the months preceding the creation of the interoperability working group and the efforts to
develop usage-scenario-oriented profiles, an activity began within the software working group to
develop standardized man-machine interfaces (MMI). An MMI task force, chaired by author
Bisdikian, was formed in November 1998. Its goal was to enhance the user experience and

135
interaction with Bluetooth devices through standardized usage and connectivity procedures,
nomenclature, and graphic user interfaces (where appropriate), following the paradigm of GSM
cellular phones. However, the variety of devices that could be capable of Bluetooth wireless
connectivity far exceeds the variety of GSM phones; hence the SIG realized that the development
of standardized procedures for all conceivable Bluetooth devices could be too restrictive. Thus,
with the creation of the interoperability working group, the activities in the MMI task force
merged with those of the interoperability group.

As the initial set of profiles progressed and matured, it became evident that each of the profiles
made assumptions about underlying transport protocol layers. Because there was no end-user
scenario that dealt specifically with low-level communication issues it was not initially evident
that a profile was needed to address those topics. Meanwhile the SIG had begun to discuss
security issues in earnest. These two developments resulted in the realization by the SIG that a
profile was needed to address the common communication elements. By May 1999 the
framework of the generic access profile was in place. Considering that the specification was
published the following July, it should be evident that a great deal of work was required in a short
amount of time to complete the GAP.

GAP Examined
The GAP is concerned principally with three items: dictionary, connectivity, and personalization.
The dictionary consists of a collection of terms and their definitions. These terms appear in the
specification, both in its core and profile parts, and the dictionary provides the foundation for
their unambiguous use throughout the specification. Connectivity consists of the operations
performed by devices that allow them to connect, or not, and authenticate, or not, with other
devices. Personalization consists of the elements that identify and customize Bluetooth devices,
like their user-friendly names and PINs. For the last two items, the GAP provides terms that can
be exposed at the user-interface (UI) level, whenever applicable.

This chapter focuses on the connectivity aspects of the GAP, which are used by all other profiles.
They include the connectivity modes, the security modes, and idle mode procedures. The GAP
also has a section on link establishment procedures that summarizes the sequence of operations
used to establish Bluetooth links and L2CAP channels; these procedures are highlighted in
Chapters 6 and 7 and thus are not discussed further here.

Connectivity Modes

As described in the baseband portion of Chapter 6, a device may enter inquiry scan mode or page
scan mode, either to be discovered by other devices that transmit inquiries or to be connected
with other devices that transmit pages to the device, respectively. The baseband specification
does not state the conditions under which a device performs inquiry and page scans and thus it
does not specify when a device allows itself to be discovered or connected. The HCI specification,
described in Chapter 7, includes HCI commands sent by a host to the host controller, and from
there to the link manager and link controller, that instruct the latter to enter the various inquiry
and page states. Thus, it becomes a matter of a user-level (or, more generally, application-level)
defined policy as to when a device enters any of these states. Similarly, a user-level defined
policy also determines whether or not devices shall pair (authenticate) with each other. This is an
important point: user-level decisions determine the degree to which a given device can be
discovered, connected to and paired. One concern often expressed about Bluetooth technology is
that all Bluetooth devices will automatically communicate with each other at any time, but this is
a misconception. Users, or user-level applications, set the connectivity policies that determine
which devices can communicate with each other, and when. These policies could be fixed by the
manufacturers of Bluetooth devices or could be configurable by their users. Thus, device
manufacturers could use the connectivity policies as a way to differentiate their products.

136
The GAP defines the policies for device communication establishment and categorizes them into
discoverability modes, connectability modes and pairing modes.

Discoverability Modes

A Bluetooth device is said to be discoverable if it allows itself to be discovered by other Bluetooth

devices. In particular, a discoverable device executes inquiry scans regularly and responds to
inquiries sent by inquiring devices. There are three levels of device discoverability:

1. General discoverable mode: At this discoverability level, a device enters inquiry scans
using the general inquiry access code (GIAC), which is the inquiry access code (IAC)
generated from the specially reserved lower address part (LAP) '0x9E8B33' of the 48-bit
Bluetooth address, as described in Chapter 6. In this mode, a device responds to all
inquiries and thus it always can be discovered by all other inquiring devices.
2. Limited discoverable mode: At this discoverability level, a device enters inquiry scans
using the limited inquiry access code (LIAC), which is the IAC generated from the specially
reserved LAP `0x9E8B00'. In this mode, a device may respond only to the inquiries that
contain the LIAC and thus it may be discovered only by other devices inquiring using the
LIAC.
3. Nondiscoverable mode: At this discoverability level, a device does not respond to
inquiries and thus other Bluetooth devices cannot discover it.

When a device is discoverable, it must always enter the general discoverable mode, even if it
enters the limited discoverable mode. The latter mode may be entered in parallel with or
sequentially to the general discoverability mode, as described in Chapter 6. A discoverable device
must enter inquiry scans no less frequently than every 2.56 seconds and must remain in inquiry
scan for at least 10.625 milliseconds.

Connectability Modes

A Bluetooth device is said to be connectable if it allows itself to create Bluetooth links with other
devices. In particular, a connectable device executes page scans regularly and responds to pages
sent to it by paging devices.

A nonconnectable device does not respond to pages and thus it cannot create links with other
devices.

The discoverability and connectability modes might be set independently of each other[2];
however, a device that is only discoverable and not connectable may not be very useful.
[2]
There is a host controller interface command that enables inquiry and page scans independently of each other.

Pairing Modes

A Bluetooth device is said to be pairable if it allows itself to be authenticated by another

Bluetooth device, meaning that it can play the role of a claimant during an authentication
transaction. Furthermore, a pairable device, in addition to accepting LMP_au_rand PDUs, must
accept an initial authentication request received from a verifier in an LMP_in_rand PDU, as
discussed in the LMP section of Chapter 6.

A nonpairable device responds to an LMP_in_rand PDU with an LMP_not_accepted PDU, signifying

that the device is not willing to pair with any new devices.

Security Modes

137
Security operations in Bluetooth devices ultimately relate to device authentication and possibly
link encryption. Recall that the former is a mandatory feature of Bluetooth devices while the
latter is not.[3] Three levels of security relate to the "depth" of the security safeguards imposed
upon communicating devices:
[3]
However, some profiles do mandate support for and the use of encryption.

1. Security mode 1: A device that operates in this mode does not have any security barrier.
In particular, it never acts as a verifier and thus never sends LMP_in_rand or
LMP_au_rand PDUs.
2. Security mode 2: A device that operates in this mode places a security barrier at the
L2CAP layer. In particular, it does not initiate any security transaction prior to receiving a
request to establish an L2CAP channel using the L2CAP_Connection_Request signaling
command, as described in the L2CAP section of Chapter 7. This security mode allows a
flexible security model for Bluetooth devices in which security barriers in a remote device
can be raised based upon the particular service that a local device requests from the
remote device.
3. Security mode 3: A device that operates in this mode places a security barrier at the link
manager layer. In particular, it does not initiate data communications involving the upper
transport and higher layers prior to authenticating the device with which it is to
communicate. In other words, authentication occurs before the transmission and receipt of
the LMP_setup_complete PDU, as discussed in the LMP section of Chapter 6.

Note that a device may be in one and only one security mode at any given time. For example, a
device in security mode 3 cannot authenticate other devices selectively; instead it authenticates
all devices that attempt to establish a link with it. A flexible security architecture for Bluetooth
devices is described in [Muller99]. It forms the basis for the security modes included in the GAP.

Idle Mode Procedures

While the connectivity and security modes are associated with activities that a Bluetooth device
follows to react to incoming stimuli (such as inquiries, pages, L2CAP_Connection_Requests, and
so on), the idle mode procedures relate to the device that sends the stimuli. These procedures
include general and limited inquiry, name and device discovery and bonding.

The general and limited inquiries are used to discover devices in general or limited discoverable
mode, respectively. The device discovery process returns, among other things, the user-friendly
name of discoverable and connectable devices. Note that requesting the name could involve just
the LMP layers in two devices without involving the hosts.

Bonding is a pairing procedure executed for the purpose of creating a link key between devices
and storing that key for future use. In general bonding, bonding is combined with additional
communications such as accessing higher-layer services. In dedicated bonding, a device connects
with a pairable device with the sole purpose of creating a bond between the devices without
involving upper-layer transactions.

The GAP concludes with a brief description of a service discovery procedure used to search for
services supported in remote devices. This procedure follows the guidelines for service discovery
found in the SDAP, which is presented next.

138
The Service Discovery Application Profile
As noted in Chapter 8, service discovery is expected to be a key component of most Bluetooth
applications. Nearly all of the profiles include a service discovery element. Like the GAP, the
Service Discovery Application Profile, or SDAP, provides a common and standard method for
performing service discovery using the Bluetooth protocol stack.

Unlike most other profiles, the SDAP describes a standard service discovery application model
and also defines abstractions of service primitives that in some respects resemble application
programming interfaces (APIs). Even though the SDAP deals with the SDP middleware layer
protocol and thus addresses some of the "invisible" operations described earlier, it is aimed
primarily at application writers. It is the only profile with "application" in its title and the only
profile to suggest API-like primitives. As explained in Chapter 8, these primitives could be
mapped to platform APIs in a straightforward manner.

SDAP Development
Both authors have a special interest in the SDAP. Author Bisdikian served as editor of the SDAP
portion of the specification, conceived the original idea for the SDAP and contributed most of its
content, and author Miller chaired the service discovery task force responsible for delivering the
SDAP.

As with the GAP, the need for an SDAP was not originally evident, and thus the SDAP was also
developed late in the specification cycle. Not until January 1999, when most profiles were already
underway, was the question raised regarding whether or not a service discovery profile was
needed. By March of that year the idea of an application profile for service discovery was
accepted and the SDAP development proceeded.

The development of the SDAP is rooted in the fundamental assumptions that led to the formation
of the SIG itself: the diversity and number of devices that would be capable of Bluetooth wireless
communication and the diversity and number of services available through these devices would
steadily increase. To keep a semblance of order in the expected sea of devices and services
available to a user, it was recognized that a standardized procedure should be created that would
allow the user of a device to locate and identify services.

The SDAP does not describe how the service discovery itself is performed; it relies on SDP for this
task. Rather, SDAP describes how an application that uses SDP should be created and should
behave. In particular, it defines the functional characteristics of such an application through a set
of service primitive abstractions, detailed below. Furthermore, the SDAP defines how other
profiles and applications in general must use the group of Bluetooth transport protocols to carry
SDP_PDUs when they need to execute SDP transactions. This latter item was an expansion of the
SDAP's original scope. All of the "nongeneric" profiles contain an SDP section that provides a list
of parameters for the protocol stack that leads to the particular application covered by the profile.
These protocol stack parameters include ones like the RFCOMM data link connection identifier
(DLCI) needed to reach, say, the PPP layer in the LAN access profile. These parameters are
carried as service attributes within SDP_PDUs. However, these other profiles do not specify how
the SDP layer could use the group of Bluetooth transport protocols to carry these SDP_PDUs.
Since the latter process should be identical for all profiles, one idea was to include it in a generic
profile like the GAP. However, the GAP does not focus on the transport of data with a source or
sink above the L2CAP layer. Moreover, the SDP specification itself does not contain the
dependencies of SDP on the group of Bluetooth transport protocols. Even though this may seem
like an oversight, it was a deliberate choice. The Bluetooth service discovery protocol, although
tied to systems that utilize Bluetooth wireless communication, is in principle a transport-
independent protocol. Hence, the SDP specification focuses exclusively on the SDP transactions

139
themselves and the various SDP_PDUs that are used, as well as the type and form of information
that is carried in them. The SDP specification does not particularly focus on how these
transactions are carried over the Bluetooth air-interface. Ultimately, SDAP became the only (and
natural) point of reference for describing how the SDP layers use the group of Bluetooth transport
protocols to carry the SDP_PDUs to each other.

SDAP Examined
The SDAP is unique among the application-oriented profiles, like the file transfer profile, the LAN
access profile, and so on. These other profiles describe how the complementary parts of a user-
level application running on two (or more) devices work together to support a particular usage
scenario. The application in SDAP needs to be present in only one device. This application
interacts with the SDP layer of the stack in the device where it resides to initiate SDP interactions
with one or more SDP layers in other devices, so as to learn about services in those other
devices. Upon the arrival of responses from the other devices, the service discovery application
can make those results available to the user of the device that initiated the transaction(s).

Often, service discovery in non-Bluetooth environments is performed by broadcasting inquiries

for services or inquiries for locating directories of services. In the latter case, when a service
directory is found, it is then contacted to find out about services that are registered there. In a
Bluetooth piconet, broadcasts are entirely unidirectional in that they are exclusively directed from
the master to the slaves of the piconet. Furthermore, broadcast transmissions are not
recoverable in that they cannot be retransmitted following an error in their transmission. Thus,
service discovery in a Bluetooth piconet does not use a broadcast model. Service discovery in
Bluetooth piconets is closely associated with device discovery. Service discovery is executed only
between fully identified pairs of devices and only after they have discovered each other and have
created a Bluetooth link (up to and including an L2CAP connection) between them.

According to the SDAP, devices participating in service discovery may have either of the following
roles:

• Local device: This device implements the service discovery application, like the service
browsing application referred to in Chapter 8. It also implements the client portion of the
SDP layer. A local device initiates SDP transactions as shown in Figure 8.3.
• Remote device: This device is contacted by a local device to inquire about services. A
remote device implements the server portion of the SDP layer. It responds to SDP
transaction requests from a local device. To produce its responses, the remote device
maintains, explicitly or implicitly, a database[4] that contains service records for the
services available via the remote device.
[4]
The specification does not define the format of this database, leaving that choice to implementers. Moreover, this
need not be a "database" in the classic sense; it is simply a collection of information maintained by the SDP server in
a format suitable for the device.

Even though some devices may act only as local or as remote devices, these device roles are, in
general, temporary and meaningful only when an SDP transaction between two devices is under
way. A device can be a local or remote device at different times or even at the same time,
depending upon when it creates service inquiries or responds to them. The SDAP device roles
bear no relation to the baseband roles of master and slave, as the latter roles are meaningless
above the link manager layer. A local device could be either a master or a slave in its piconet, as
could a remote device.[5]
[5]
Often a local device acts as master of a piconet, since typically it would be the device that desires to create connections with
other devices and search for and use services on them. However, this does not mean that a local device must be a master to
perform service inquiries. A slave device could equally well initiate such inquiries.

140
The SDAP is the only profile that uses the term application in its title. However, the SDAP does
not define any particular application. Such a definition would be very much platform dependent
and possibly too restrictive for application developers, neither of which is a desirable objective for
a specification. However, the SDAP specifies the services that a service discovery application
should provide to its users to be useful. These services are summarized in four service primitive
abstractions. These primitives could be mapped to an appropriate set of APIs based upon the
underlying software and/or hardware platform in which an SDAP application is instantiated. An
example mapping of these primitives to the Salutation APIs is given in [Miller99]. These
primitives are:

• serviceBrowse: This service primitive is utilized when a local device wants to perform
general service searches, referred to in Chapter 8 as service browsing. These searches
might take the form of queries about what services in general or what services of type S
are available, if any, via a selected set of remote devices. This application-level service
primitive results in SDP_PDU transactions initiated by any one of the three basic request
SDP_PDUs presented in Chapter 8: SDP_ServiceSearchRequest,
SDP_ServiceAttributeRequest, or SDP_ServiceSearchAttributeRequest. Optionally, the
LMP_name_request PDU could also be sent to learn the user-friendly name of the remote
device.
• serviceSearch: This service primitive is utilized when a local device wants to perform
searches for a specific type of service. The search could take the form of queries about
what services of type S with attributes A1 and A2 are available, if any, via a selected set
of remote devices. Similar to the previous primitive, this application-level service primitive
results in SDP_PDU transactions initiated by any one of the three basic request SDP_PDUs
previously mentioned.
• enumerateRemDev: This service primitive is used when a local device wants to search
for remote devices in its vicinity. The search can be restricted with a class of device (CoD)
qualifier to search only for devices belonging to the specified class. This application-level
service primitive results in the local device executing inquiries to learn about devices,
primarily any new devices, in its vicinity. If, in the future, CoD-specific dedicated inquiry
access codes (DIACs) are standardized, then the inquiries for this primitive could be
generated according to these DIACs. Otherwise, the generic inquiry access code (GIAC) is
used and the local device needs to filter the received responses according to the
information included in the CoD field in the FHS BB_PDUs received from the responding
devices.
• terminatePrimitive: This service primitive results in the termination of the operations
invoked by the previous primitives.

The first and second primitives above relate directly to transactions involving SDP_PDUs. The
third primitive could be satisfied merely by requesting that the device enter the inquiry mode
with the sole purpose of searching for any other devices in the inquiry scan state (as described in
the baseband section of Chapter 6). The last primitive simply terminates any ongoing actions
resulting from the use of any of the other primitives.

The SDAP requirements on the Bluetooth stack are straightforward. To implement this profile one
needs to use nothing beyond the default settings for all the protocol layers below the SDP layer.
In particular, devices that connect for the sole purpose of performing service discovery do not
need to authenticate each other or encrypt their Bluetooth link.[6] The SDP transactions are
carried over the ACL baseband link between the devices. At the L2CAP layer SDP transactions are
carried over connection-oriented channels configured to carry "best effort" traffic.
[6]
This does not imply that device authentication and/or link encryption should not be performed. This statement simply implies
that the SDAP imposes no security precautions for its execution. Security is as much a usage scenario requirement as a user-
level settable policy, as discussed in the GAP. Security precautions may still be taken for reasons outside the scope of SDAP.

141
An additional distinction of this profile is that it identifies the conditions under which L2CAP
channels carrying SDP traffic are torn down. This is so because SDP does not define a session or
a transport protocol for carrying SDP_PDUs. SDP itself is in essence a connectionless protocol. To
run the connectionless SDP request/response transactions, the L2CAP layer needs to maintain the
L2CAP channel that carries the transactions at least for the duration of the transaction. For
efficient use of the transmission resources, the L2CAP channel between an SDP client and an SDP
server should be maintained even longer. Ultimately, it is the application on behalf of which SDP
transactions are executed that should open and maintain, for as long as necessary, the L2CAP
channel for SDP transactions between two devices.

Summary
In this chapter we have highlighted the two generic Bluetooth profiles: the GAP and the SDAP.
The GAP describes the connectivity and security modes of operation for a device that permits it to
discover, be discovered by, and create trust bonds and Bluetooth links with other devices. These
modes of operation are user- (or application-) settable device policies that specify how the device
should wbehave relative to other devices with which Bluetooth communication might ensue.

The SDAP describes the functional characteristics of a service discovery application. Furthermore,
and equally importantly, the SDAP describes the way that the SDP layer must use the group of
Bluetooth transport protocols to carry SDP transactions. This aspect of the SDAP also forms the
basis for executing service discovery within the other profiles.

142
Chapter 13. The Telephony Profiles
Continuing our examination of the profiles, we now visit those that are based upon telephony
functions. We include here the cordless telephony, intercom and headset profiles. As described in
Chapter 10, the fax and dial-up networking profiles also make some use of telephony protocols,
but we consider these part of the networking group that is covered in Chapter 15. All three
telephony profiles discussed here primarily address voice telephony functions. They all target
telephony devices (mostly mobile phones and headsets) and thus they exist largely for use by
telephones.[1] In fact, the intercom and cordless telephony profiles instantiate two different
aspects of the three-in-one phone usage scenario introduced in Chapter 3, although the cordless
telephony and headset profiles explicitly address the use of computer audio in addition to
telephone audio.
[1]
We suppose that other types of devices could implement these profiles. There is no reason that, say, a computer could not
provide intercom profile function if it had the appropriate voice and TCS-BIN support. But in general the telephony profiles
center around telephones.

These telephony profiles, then, are expected to be implemented in many mobile telephones and
other telephony equipment used with phones, like headsets and voice access points. All are
intended to carry voice traffic, and in fact it is this common element that caused us to group
them for this chapter's discussion.[2]
[2]
These profiles could have been referred to as "telephony audio" or "voice telephony" profiles but we opted for the briefer yet
still descriptive "telephony profiles."

Relationships
Voice telephony is a common element shared by these three profiles, but from a technical
perspective (refer back to Figure 11.1) they inherit from two different profile families. The
cordless telephony and intercom profiles are part of (and indeed all of) the TCS-BIN family (even
though there is no TCS-BIN profile per se) while the headset profile derives from the serial port
profile. Yet from an end user's perspective, the most visible feature of all of these profiles is the
ability to route and process telephony-grade audio traffic using Bluetooth wireless
communication.

The cordless telephony and intercom profiles are both part of the three-in-one phone usage case.
Recall from Chapter 3 that the three types of usage for a mobile telephone in this scenario are as
(1) a standard cellular phone; (2) an intercom or "walkie-talkie"; and (3) a cordless phone using
a cordless base station, or voice access point. Standard cellular phone operation is addressed by
protocols like GSM, CDMA, CDPD and others, using a wide area radio in the handset; Bluetooth
wireless communication is not used for the standard cellular phone operation. Standard cellular
phone usage is not discussed further.

The profiles for the remaining two aspects of the three-in-one phone usage model, both of which
use the TCS-BIN protocol, are unusual among the version 1.0 profiles in that they define only
part of a usage case. Most profiles (fax, dial-up networking, synchronization and so on) map one-
to-one to usage cases. But in the case of the three-in-one phone usage case, there are two
separate profiles—cordless telephony and intercom—that define the two separate parts of that
single usage case that are relevant for Bluetooth wireless communication. In this case there are
good reasons to separate the two distinct functions. While they can be combined to realize the
three-in-one phone scenario, cordless telephony and intercom also can be of value individually,
and a robust implementation of cordless telephony is much more involved and complex than is an
implementation of intercom. As we will see below, cordless telephony often involves advanced
functions of TCS-BIN, while intercom communications can be much simpler in comparison.

143
Therefore it could make sense in some devices to implement just an intercom function without
cordless telephony function. By separating these functions into individual profiles, such devices
can conform to the intercom profile, which is useful in its own right, without implementing the full
three-in-one phone usage case, which would require additional cordless telephony support.

While the intercom profile is simple in comparison to cordless telephony, the headset profile is
intended to be even more straightforward and less complex—it is perhaps the simplest of all the
version 1.0 profiles. This is by design, since Bluetooth headsets are generally expected to be
simple, low-cost accessory devices; thus the requirements of the headset profile need to be
minimal to enable such lightweight devices. This is one reason that the headset profile, even
though it is involved in audio telephony, belongs to a different profile family than do the cordless
telephony and intercom profiles. Recall from Chapter 11 that the headset profile is a derivative of
the serial port profile. The SIG felt that requiring wireless headsets to implement the TCS-BIN
protocol (as the cordless telephony and intercom profiles call for) would be too burdensome for
headsets. For the version 1.0 headset function, only audio transfer (which occurs directly over
the baseband link) and some very simple control functions are needed. TCS-BIN is excessive for
these simple control functions for headsets, so a minimal set of AT commands was chosen for
headset control. These commands can be used over the RFCOMM virtual serial port as described
in Chapter 10. Thus headsets need only contain a minimal implementation of the RFCOMM
protocol, so there is no requirement for them to implement the TCS-BIN protocol.

So we see that even though these three profiles exist on two different branches of the protocol-
based "profile family tree," their common bond is that of supporting some form of voice
telephony. Each is concerned with the rendering and transporting of audio traffic (SCO packets)
over the Bluetooth air-interface.

The Cordless Telephony Profile

As already noted, the cordless telephony profile, or CTP, defines the "cordless phone" facet of the
three-in-one phone usage case, but more generically it defines cordless telephony. The CTP not
only allows a cellular telephone to use Bluetooth technology for short-range wireless voice
communication, but it also addresses handsets that exclusively use Bluetooth wireless
communication to act only as cordless telephones. These telephones are not cellular phones; they
are solely cordless handsets for use with a local base station. The CTP also includes computers
that could accomplish cordless telephony using Bluetooth wireless communication, through
support for the TCS-BIN protocol and audio traffic management using the microphone and
speakers of the computer.

The cordless telephony usage scenario drove most of the requirements for the Bluetooth
telephony control protocol. Cordless telephony introduces the notion of terminal devices and
gateway devices and hence the requirement for control functions for these devices, such as group
management. Furthermore, cordless telephony also introduces the need for reasonably
sophisticated call control functions. For example, a base station needs to communicate call
control information to and from a remote handset to enable the handset to receive ring tones for
incoming calls and to dial through the base station for outgoing calls. Finally, advanced features
found on many existing cordless telephones, like multiple handsets for a single base station,
speed dialing, directory and caller identification information and so on drive the expectation that
these same sorts of features can be accommodated in Bluetooth cordless telephony. Thus the
functions required for cordless telephony helped to drive the selection of TCS-BIN, which is the
primary protocol used by the CTP (recall from Chapter 10 that TCS-BIN provides call control,
group management and connectionless TCS functions, all of which are important in satisfying the
requirements outlined above).

CTP Development
144
Until March 1999 there was only a single three-in-one phone profile that encompassed both
cordless telephony and intercom functions. As the profile development progressed, the SIG
decided to split the cordless telephony and intercom functions into two profiles because, as we
observe above, these functions might be implemented independently. Both profiles today still
state that they apply for devices implementing the three-in-one phone usage case, but they also
acknowledge that each addresses one specific function of that usage case.

Even though it is one of the more involved profiles, the CTP, at least in its incarnation as the
three-in-one phone profile, was one of the first to be started and thus one of the first to mature
and reach completed status.[3] This is due at least partly to the fact that the three-in-one phone
scenario requirements had been studied for quite some time and had resulted in the selection of
TCS-BIN as the telephony control protocol for this scenario. Thus the mapping of cordless
telephony functions back to TCS-BIN (which is what the vast majority of the CTP deals with) was
rather straightforward.
[3]
Technically, nearly all of the profiles were completed, or formally ratified, at about the same time. But at that point some
profiles had already been largely completed for some time while others were still being finalized.

CTP Examined
The three-in-one phone usage scenario heavily influenced the development of TCS-BIN in the
protocol stack, and therefore the CTP makes heavy use of TCS-BIN. Most of the CTP is devoted to
TCS-BIN interaction. A study of the TCS-BIN protocol is useful in understanding both the CTP and
the intercom profile (described below). The CTP contains a detailed description of procedures and
TCS-BIN messages used in cordless telephony applications; these are not repeated here. Instead
we highlight some of the key aspects of the CTP, including the rationale for those design points.

The CTP first makes the important distinction of device roles, as either gateway or terminal
devices. Nearly all of the remainder of the CTP is based upon this distinction. In general the
gateway device can be viewed as the "server" of a piconet (and in fact is defined to be the
piconet master in most cases), with various other devices, including cellular handsets, specialized
cordless handsets and perhaps even computers or advanced headsets,[4] as "clients" of the local
voice network (piconet). Figure 13.1 illustrates a cordless telephony piconet; a similar figure
exists in the profile specification, but we include our own version, as we elaborate on the
concepts and terminology shown here in following sections.
[4]
In this case, such headsets would not be the same as those developed to comply with the headset profile, which is based
upon the serial port profile. Cordless telephony headsets would functionally resemble handsets and would need to comply with
the cordless telephony profile (instead of or in addition to the headset profile).

Figure 13.1. Cordless telephony piconet with gateway device and

terminal devices.

145
Note that because the voice telephony network is a piconet, only seven slaves, or terminal
devices, can be active at one time. This is still an improvement over many of today's cordless
telephone systems, which often associate only one handset with a single base station. As the CTP
points out, more than seven terminal devices are possible; as one might expect, this is
accomplished through the use of parked slaves. Since the gateway is the master of the piconet, it
would be responsible for managing up to seven active slaves versus some number of parked
slaves in the case where there are more than seven terminal devices. To allow the development
of gateways with varying features and complexity, managing more than seven terminal devices is
not mandated (it is an optional capability and thus need not be implemented in every gateway
device).

The CTP is one case in which the master-slave role switch described in Chapter 6 is used. The
gateway device is the master of the piconet. New terminal devices (perhaps a mobile phone that
is brought into the home) are added to the piconet when the new terminal device pages the
gateway device (base station). Once the gateway device accepts the page, the terminal device
then, by default, becomes the master of that link. However, this is the opposite of what is needed
for normal operation of this voice piconet, so a master-slave switch (role reversal) must be
performed immediately. One alternative that might have been used, which could have removed
the need for a master-slave switch, is a model in which the gateway device pages the terminal
devices. For well-known terminal devices (say, those handsets that are always associated with
the base station), this might be a reasonable method to use. However, for transient devices that
might need only temporary access to the gateway (consider visitors to a home or office who
might be granted temporary use of the gateway, or a public voice access point that permits
devices in proximity to connect to it), the SIG chose a model in which the client, or terminal
device, initiates a request to connect to a gateway device. This model takes into account the
needs and desires of the user of the client device and seems preferable to a scheme in which a
gateway attempts to communicate with every potential terminal device that might wander into
proximity; many such devices might have no desire or even capability to participate in the voice
network. Thus the process of joining the cordless telephony piconet is client initiated and
therefore necessitates a master-slave role switch after a new member joins.

An important aspect of cordless telephony is security. The CTP requires that all devices in the
voice piconet be authenticated. While one may wish to allow a trusted friend to have access to
one's own gateway via the friend's handset, one certainly wouldn't want to offer this capability to
146
any device that happened to be in range, since access to the gateway implies the ability to make
telephone calls through it. The CTP allows for only trusted terminal devices to connect to the
gateway.[5] The CTP also calls for encryption of all the traffic within the piconet. A common
shortcoming of very early cordless telephone systems[6] was the ability of others to easily
eavesdrop on the voice traffic transferred over the air. As noted in Chapter 1, the FHSS nature of
Bluetooth communications adds one degree of protection from eavesdropping, but the use of the
encryption inherent in the technology enables even more secure communication.
[5]
Here is but one of many examples of the value of the common vocabulary of the GAP, discussed in the previous chapter. The CTP states that only
trusted devices can connect to a gateway; without the GAP, which defines a trusted device, this term might be interpreted in different ways.

[6]
In the United States, 900 MHz cordless telephones (and similar systems such as baby monitors) without any encryption or spread spectrum
capabilities were quite popular. With these systems it was easy to eavesdrop (intentionally or not) on conversations of neighbors. While many newer
systems use spread spectrum, which can mitigate the eavesdropping problem, many older systems still remain in use.

When a CTP piconet is formed, there exists a group of devices that all implement the TCS-BIN
protocol (since this is necessary for conformance to the CTP). Recall from Chapter 10 that when
such a group of devices is formed, a WUG (wireless user group) can also be formed to make use
of the TCS-BIN protocol to provide additional features enabled by the protocol. In the case of the
CTP, the WUG is employed to facilitate use of cordless telephony features in a secure manner. As
would be expected, the gateway device acts as the WUG master (in addition to being master of
the piconet). Because WUGs allow all participating devices to be known to and to interact with
each other (an additional capability beyond the point-to-point master-slave communication),
cordless telephony piconets have some unique advantages. For example, once a new device has
been authenticated with the gateway (master) device, it need not authenticate individually with
every other WUG member, since the master will by proxy authenticate the new device when it
informs all the WUG members that the new device has joined. This could be useful if the device
later initiated an intercom conversation (described below) with another member of the WUG. Not
only would the device know about all of the other devices in the WUG, it could easily establish
direct communication with any of them.

When a terminal device connects to the gateway, it establishes and maintains an L2CAP
connection for as long as it remains in the piconet. So, when a call is made or received, it is not
necessary to incur the overhead involved to establish a transport layer connection, which in some
cases could take up to several seconds, to process the call. Only the TCS-BIN protocol needs to
be initiated over the already existing L2CAP connection.

CTP Usage
Clearly the sorts of applications that implement the CTP would be telephony applications that
manage telephone calls. While the specification does not define APIs, TCS-BIN establishes a well-
defined functional interface for making and receiving calls and for transferring information like
DTMF tones or caller identification data. Because TCS-BIN is based upon the ETSI Q.931 standard
[ITU98], existing telephony APIs on many platforms should map easily to those of TCS-BIN.

The CTP adds more guidance to the telephony application developer by specifying which of these
call primitives are mandatory and which are optional for Bluetooth cordless telephony.
Applications on devices claiming to conform to the CTP must at least implement the basic set of
functions described in section 2 of the CTP (these include on-hook, connection management,
outgoing and incoming call management and others). Some more advanced features are
optional. And like all profiles, vendors can add their own differentiating features beyond those
specified in the profile. This is especially true in the case of the CTP, since it uses TCS-BIN, which
includes the connectionless TCS feature described in Chapter 10. This feature directly enables
vendor-specific features and extensions.

147
The Intercom Profile
For convenience, we will continue our custom of shorthand notation for the profiles. In the case
of the intercom profile we use the term IntP (rather than IP, which might be confused with
Internet Protocol and IP networking). The IntP is the other profile that is based upon TCS-BIN,
and it also defines the final aspect of the three-in-one phone scenario. Intercom, or "walkie-
talkie" operation, generally is an easily understood concept, since it is a direct voice connection
between two devices that many people have experienced. The intercom profile is thus
unsurprisingly simple and straightforward.

With the intercom profile, two devices that both support TCS-BIN can make a direct voice
connection using the Bluetooth air-interface, without any third-party carrier required. In the
specification the IntP includes a figure that shows such a connection between two cellular phones.
While this is the most obvious (and probably most common) situation, other devices that have
audio and TCS-BIN support could also participate in the intercom usage model. As shown in
Figure 13.1, specialized cordless handsets, CTP-compliant advanced headsets and computers
might all include audio and TCS-BIN protocols and therefore could implement the IntP. In fact,
one could build a true Bluetooth walkie-talkie that is dedicated solely to the intercom scenario.[7]
[7]
Although this is possible, it seems unlikely, since even with the optional radio the range of Bluetooth wireless communication
is limited to 100 meters, which is less than that of existing walkie-talkies using other radio frequencies. The value of the
intercom usage case is the utility it provides by adding another function to an existing device rather than enabling a new class
of device.

IntP Development
As noted in the preceding discussion of the cordless telephony profile, the CTP and IntP were split
from a single three-in-one phone profile during profile development. The IntP is really a special
case of cordless telephony, and intercom calls are still referenced in the CTP, although in these
cases they refer to the IntP for details. When the history of these profiles is known, it becomes
quite evident that the CTP and the IntP are closely related. From a structural point of view, the
two profiles mirror each other almost exactly.

Like the CTP, the IntP was one of the first profiles to be started and thus one of the first to be
completed, or at least to reach a level of stability such that it was declared ready for publication.

IntP Examined
For the intercom usage case, the IntP indicates that there are no prescribed device roles. Unlike
the CTP, where it is important to define a master (gateway) and slave (terminal) device, the
devices in the intercom scenario are peers. Either device could be master of the piconet.

There could have been multiple ways to establish a direct voice link with Bluetooth wireless
communication. The IntP chooses to make use of TCS-BIN for this scenario, so the intercom
function is still very much a "telephone call" sort of operation. Data flows as SCO packets, which
is the norm for voice traffic, and control is provided via TCS-BIN. This control might have been
provided through some other means, but because TCS-BIN is used in the CTP, which is also part
of the three-in-one phone usage model, the use of TCS-BIN for the IntP is natural. Furthermore,
TCS-BIN's group management functions provide an environment in which it is relatively easy to
establish an intercom call. Through the WUG enabled by TCS-BIN, each device in the voice
piconet is aware of every other device. In addition, as a result of their authentication with the
master, all of the devices are trusted by each other. Thus it is a straightforward operation for one
device to locate and establish a communication link with any other device in the WUG (which
overlaps entirely with the piconet) to perform an intercom call. The master need not be

148
involved;[8] any device can directly page any other device to set up an intercom call. Note that
this means that these devices temporarily leave the existing piconet to form their own new
piconet, but rejoining the original piconet is also made easier through the WUG/TCS-BIN group
management functions.
[8]
Except to set up the intercom paging scenario, as described in Chapter 10.

One important aspect of the intercom usage case not addressed by the IntP is that of 10-meter
versus 100-meter operation. As pointed out in Chapter 3, the intercom scenario with the
standard 0 dBm Bluetooth radio is somewhat uninteresting. With the standard radio's range of
about 10 meters, two parties who might use the intercom function are likely to be close enough
to each other that they can talk without the benefit of radios. However, there certainly are
situations in which intercom communications are useful even with a 10-meter range. Consider,
for example, the parties being on different floors of a house or an office, or perhaps needing to
communicate with the benefit of radios even when they have a line of sight between them (one
example of the latter case given in Chapter 3 is that of audio/video technicians in a crowded
auditorium during a conference presentation). However, intercom communications become even
more interesting when the 20 dBm optional radio with its 100-meter range is employed. The
ability to make a direct call to another device without using any third-party carrier, and thus
without incurring any airtime usage charges, is quite attractive. Think about being able to use
your mobile phone to contact your spouse or friend in their seat at a crowded sports arena while
you are at the concession stand, without having to dial through your service provider. Other
applications could include those where medium-range wireless voice communication is used
today—security and maintenance workers, for example, who need to stay in communication
within a local area such as a hotel or small campus area. In these cases, Bluetooth wireless
communication might be used in place of other RF solutions, one benefit being that a single
device could be used both for the local medium-range RF voice communication and for some
other function (such as a cellular phone or computer usage), obviating the need to carry another
device just for wireless voice communication.

IntP Usage
An IntP application is likely to be part of a general cordless telephony application. As previously
noted, it seems unlikely that Bluetooth devices dedicated exclusively to functioning as intercoms
or walkie-talkies will be prevalent. Thus it would seem unlikely that a separate application
dedicated to intercom function would be developed. Since the IntP uses TCS-BIN, as does the
CTP, we would expect that a cordless telephony application that implements the CTP could be
easily extended to also incorporate the IntP. In fact, while these two profiles need not be
implemented together (recall that the SIG overtly chose to split them), in many cases, such as in
support of the three-in-one phone usage model, it would make sense to do so.

As with the CTP, the IntP provides guidelines for application developers, including optional versus
mandatory functions. As would be expected, the intercom function specified by the IntP is
relatively simple and straightforward, and in fact for the most part is a subset of the TCS-BIN
function that is needed to realize the CTP. This is another reason to expect the IntP to be
implemented alongside the CTP in many cases—once the CTP application is complete, nearly all
of the work required to realize the IntP would also already have been completed.

149
The Headset Profile
For reasons previously stated, we consider the headset profile, or HSP, to be part of the
telephony group of profiles, although it should be reiterated that the HSP is not directly related to
the IntP or CTP. The HSP is a derivative of the serial port profile; it is not one of the TCS-BIN-
related profiles. Nevertheless, the HSP also addresses voice traffic and its control.

In the CTP discussion we noted that one possibility for a cordless telephony device was a
headset. Such an advanced headset would need to comply with the CTP, including support for all
of the required parts of TCS-BIN. It would tend to resemble a telephone handset from a
functional point of view and would probably be more sophisticated than the type of headset that
the HSP deals with. A headset conforming to the HSP need not implement TCS-BIN at all; the
simple telephony control functions needed for an HSP headset are accomplished using AT
telephony control over RFCOMM. Thus the HSP defines a device that primarily serves as an audio
peripheral to some other device (most popularly, but not exclusively, a telephone).

HSP Development
Like the other telephony profiles, the HSP was one of the first to be started and thus one of the
first to reach stability for version 1.0 publication. The wireless headset, or ultimate headset as it
is called in the Bluetooth usage model (see Chapter 3), has always been an important scenario.
The use of wireless headsets with mobile telephones was one of the driving forces behind the
invention of the Bluetooth technology. Even though the HSP is not directly related to the CTP and
IntP, it is evident from the structure of these profiles that all were developed by the same group
of people.

Once the fundamental case of headset use with a mobile telephone had been covered, the profile
was expanded to cover the computer device class. A Bluetooth headset could easily be used as
the source and destination for a Bluetooth computer's audio traffic in the same manner as it is
used with a phone, and the profile acknowledges this usage case. There was some discussion of
the use of a headset with other devices (as noted in Chapter 3, future devices could include not
only other types of phones but also other types of audio devices such as stereos, portable music
players and so on). In version 1.0, the HSP does not address any headset usage other than with
a mobile telephone or a computer; but since the specification defines a standard method for
audio transfer and control, it is not expected that significantly different operation would be
required for other types of devices. There is no particular technical obstacle that prevents the use
of a Bluetooth headset with Bluetooth devices other than computers and telephones, but the HSP
addresses just these latter two classes of devices in version 1.0 of the specification.

HSP Examined
Of all the version 1.0 profiles, the HSP targets the simplest sort of device. In fact, the driving
requirements behind the HSP included the capability to develop a low-cost, simple and
lightweight headset. If such a device is overburdened with functional requirements that need
sophisticated software (which in turn requires more processing power and/or on-board memory
along with the associated increase in power consumption), then a low-cost device becomes more
difficult to realize. This is one reason that the HSP is based upon the serial port profile rather
than the TCS-BIN protocol—TCS-BIN is robust and quite useful for telephony applications, but a
rich and full TCS-BIN implementation could be relatively expensive as compared to a simple
RFCOMM implementation. Moreover, TCS-BIN includes much more function than is needed for a
headset as defined by the HSP. Note that the headset device of the HSP is quite different from
the hypothetical CTP-compliant advanced headset depicted in Figure 13.1. The HSP describes a

150
much simpler headset that uses AT commands over an RFCOMM link, and the HSP-style headset
is expected to be the more prevalent device. Figure 13.2 illustrates typical HSP operation.

Figure 13.2. Typical headset profile operation.

The HSP does not prescribe any particular role for the headset or its associated (phone or
computer) device—either can be master.[9] It defines a gateway device and a headset device, but
unlike the CTP it does not designate either as master. There are only a very few control
functions, including making a call (it is assumed that the headset has some minimal user
interface, perhaps a button, to initiate a connection with the associated gateway device),
receiving a call and (optionally) controlling volume. Unlike the IntP and CTP, these functions are
controlled via AT commands (listed in the HSP) over RFCOMM rather than through TCS-BIN PDUs.
While they may overlap functionally, they are entirely different means to similar ends.
[9]
There was a significant amount of debate in the SIG about this design choice. There are good arguments for denoting the
headset both as master and as slave, depending upon the specific usage—either the headset or the associated device could
initiate the communication; consider both outgoing and incoming calls. The final resolution was to leave the master/slave roles
unspecified in the profile, leaving them to the choice of the implementers.

The HSP does not mandate any level of security, leaving it up to the implementation as to
whether or not a secure connection (including authentication and encryption) is used.

HSP Usage
The headset is a specialized usage case. Most headset applications are expected to be embedded
in headset equipment. Within a computer or a telephone, an application might support a headset
peripheral, including the capability to route audio for incoming and outgoing calls to and from the
headset and to remotely control the volume, if that feature exists.

While the HSP considers only headset function, the audio control and routing used for headsets
probably could be generalized to other cases which are similar but use different hardware—things
like the speaking laptop usage case described in Chapter 3 or audio routing to other external
systems like those in an automobile.

151
Chapter 14. The Serial and Object
Exchange Profiles
We call this group the serial profile family, and it is composed of the serial port profile (SPP) itself
along with the object exchange class of profiles. The object exchange group consists of the
generic object exchange profile, the object push profile, the file transfer profile and the
synchronization profile.

To be sure, many other profiles use the SPP; in fact, most of the version 1.0 profiles do. We
include one such group in this chapter; other profiles that inherit from the SPP are treated in
other chapters as part of other functional categories. In fact, each of the final three chapters of
Part 3 includes at least one SPP-based profile. In this chapter we discuss the object exchange
profile family and the serial port profile itself.

The SPP maps directly to the RFCOMM protocol and thus is used in many cable-replacement
usage scenarios. Because so many of the version 1.0 usage cases employ RFCOMM, the SPP
could be the most widely implemented and used profile of all in early Bluetooth device
implementations. Even though the SPP itself does not embody a specific usage scenario, it
enables many of them.

The object exchange profiles (generic object exchange, object push, file transfer and
synchronization) are likely to be implemented in both computing and telephony devices.
Wherever IrDA devices are used, the same applications are likely to apply in Bluetooth
environments. Bluetooth technology provides a convenient way for devices like notebook
computers to exchange files, and object exchange applications like electronic business card
exchange are likely to be found wherever an electronic address book is kept—on PDAs, mobile
phones and notebook computers, for example.

Relationships
As shown in Figure 11.1 in Chapter 11, the serial port profile is the root of many profiles. Within
the group of five profiles discussed here are two abstract, or "parent" profiles, from which others
inherit. One of these is the SPP, the other the GOEP, with the latter descending from the former.
The object push, file transfer and synchronization profiles all derive from the abstract GOEP,
which addresses the common use of OBEX operations that apply to these three profiles. This
group of profiles maps to the IrDA interoperability layers of the protocol stack.

In this chapter we discuss only a subset of the SPP family, but the RFCOMM serial port
abstraction is also used for AT command telephony control in the dial-up networking and fax
profiles (described in the next chapter) as well as in the headset profile (described in the previous
chapter); the serial port is also used to enable a form of IP networking in the LAN access profile
(also described in the next chapter).

The Serial Port Profile

The serial port profile, or SPP, is a transport protocol profile that defines the fundamental
operations necessary to establish RFCOMM communications between two peer devices. Such a
link is required for many of the concrete usage scenario profiles. In this respect the SPP is
somewhat like the GAP, in that it describes how to establish necessary communication links that
are in turn needed by other profiles. The SPP serves as a profile "building block."

152
SPP Development
We observed in Chapter 8 that the RFCOMM specification contains some elements that typically
are found in profiles, so it seems as though the SPP was at least conceptually in development
since near the beginning of the SIG's existence. Its completion was neither particularly early nor
particularly late in the profile development cycle. The SPP was not always by design the basis for
so many other profiles. Like the SDAP and GAP, it was not immediately evident that a profile
relating to the RFCOMM protocol layer was merited. Even after it was created, the SPP originally
was not the basis for all other profiles that might use the RFCOMM protocol. For instance, in
March 1999 there was still debate as to whether or not the object exchange profiles discussed in
this chapter would use the SPP. At that time the GOEP (and its derivatives) all specified their own
use of RFCOMM. The serial port profile existed but focused mostly upon transporting AT
commands for the headset, fax and dial-up networking profiles and serving as a conduit for PPP
for the LAN access profile. When it was observed within the SIG that the SPP might be a good
basis for the GOEP, the differences between the GOEP and the SPP, in terms of specification and
usage of the RFCOMM protocol and related stack layers, were identified. The SPP was then
updated to accommodate the GOEP usage of the serial port abstraction as well. This is how the
SPP came to be the foundation for so many other profiles.

SPP Examined
SPP defines peer device roles for serial communication. It does not define a specific device role
for master or slave, nor does it define device roles for DTE/DCE devices (analogous to typical
wired serial communication). The devices are peers, and it does not matter which is master and
which is slave. In fact, the SPP just calls them "Device A" and "Device B," the only distinction
being that Device A initiates the serial communication link. The SPP further states that even this
distinction is of little consequence as far as the profile is concerned.

The SPP outlines the steps necessary to establish an RFCOMM emulated serial port connection;
these are illustrated in Figure 14.1. Interestingly, these are the sorts of functions that one might
expect to find in a Bluetooth adaptation layer of software as described in Chapter 5. That is, the
SPP describes precisely how to use the Bluetooth protocols to establish a virtual serial
connection; once this connection is established, serial data can flow across it. Thus for a legacy
application that uses a serial port, the functions described in the SPP are just what is needed to
replace a wired serial interface with a wireless one. Once the procedure outlined in the SPP is
completed, the fact that a Bluetooth emulated serial connection is being used rather than a
traditional wired serial connection should be transparent to an application. In fact, in the SDP
service record of the SPP, the example service name shown is "COM5," an indication that the SPP
could be used to set up emulated serial links for applications expecting to use "COM" port-style
interfaces.

Figure 14.1. Typical serial port profile opertion.

153
In addition to the link manager operations necessary to establish a baseband link between
devices, SPP makes specific mention of two other protocol stack layers needed to establish the
RFCOMM link. The first, L2CAP, has already been mentioned. RFCOMM communicates over
L2CAP, and an L2CAP connection using the RFCOMM PSM value must first be established. The
other protocol needed to establish an RFCOMM channel is SDP. SDP is used in setting up an
RFCOMM link, to find the appropriate RFCOMM server channel[1] to use. Server channels are used
to multiplex RFCOMM connections. SDP is used to choose the appropriate server channel, which
might correspond to a given service (somewhat like "well-known port numbers" in TCP/IP). In
any case, the service of interest must specify the appropriate server channel number to use to
connect to that service. This channel is the one used in the resulting RFCOMM connection over
which the SPP operates. After the server channel number is known, setting up the RFCOMM
connection is straightforward: an L2CAP connection is established, over which the RFCOMM
connection is established. Optionally, the devices might require some degree of authentication,
and perhaps also encryption, prior to establishing the links between them. The SPP specifies that
these security considerations are optional, because the SPP is a generic profile upon which others
are built. Some applications that use the SPP may require authentication or encryption (which in
turn requires authentication) while others may not. The SPP leaves it to the more specific profiles
to describe security requirements.
[1]
Server channels are constructed using the DLCI values described in Chapter 8.

SPP Usage
As an abstract profile, the SPP is more likely to be used by middleware than directly by
applications. Bluetooth adaptation software might use the SPP to instantiate a virtual serial
connection for an application that expects to use serial communications. The application need not
know that the serial port is an emulated wireless one, so long as the emulation is sufficiently
accurate.

Thus applications most likely will implement some other profile that makes use of the SPP—
perhaps headset or dial-up networking. A device might support the SPP generically in
middleware. But an application is likely to follow the standard procedures for a given platform to
open, configure, make use of and close a serial connection, as opposed to specifically following
the Bluetooth protocol stack methods for performing these functions. Thus it seems likely that
some sort of platform middleware will transform the platform APIs into the corresponding
functions of the SPP necessary to use RFCOMM over Bluetooth transports.

154
The Generic Object Exchange Profile
Like the SPP, the generic object exchange profile, or GOEP, is an abstract profile upon which
concrete usage case profiles can be built. In this case the remainder of the GOEP family is the set
of IrDA interoperability profiles, namely file transfer, synchronization and object push, each of
which is examined below. The GOEP defines all of the elements common to these other three
usage cases, including device roles, security considerations and how the OBEX protocol is used in
general.

GOEP Development
The origin of what came to be known as the GOEP was the synchronization usage model. Since
early in the SIG's history, synchronization was the driving force behind the use of the OBEX
protocol and its related scenarios. Indeed, synchronization was one of the original usage models,
and the group that produced the IrDA interoperability protocols and profiles in the SIG was called
the synchronization working group during most of its existence.

The synchronization usage case drove the use of OBEX and IrMC; the use of these protocols in
turn drove the additional usage cases of electronic business card exchange (represented in the
object push profile) and object transfer (represented in the file transfer profile). Once the IrDA
OBEX model was chosen for synchronization, it was evident that the other usage models enabled
by the IrDA protocols applied to the Bluetooth protocol stack as well, so the relevant ones were
adopted (resulting in the two additional profiles described in the sections that follow). Further,
this selection spawned the whole idea of IrDA interoperability, which became the central theme of
this family of profiles.

So in this case the evolution was from the specific category of synchronization to the broader
category of IrDA interoperability, including object push and file transfer. During this
generalization process the GOEP was developed. As the synchronization, file transfer and object
push profiles progressed, it was evident that they shared a foundation of common elements,
especially those related to the use of OBEX. These common elements were gathered into the
GOEP.

GOEP Examined
The GOEP defines very specific device roles for all OBEX-related profiles. Unlike many of the other
profiles, where the devices act as peers and there is little distinction between them, the GOEP
and its derivatives define a client role and a server role. The client device is the one that pushes
or pulls objects to a server, while the server is the one that provides the object exchange service,
which allows those objects to be pushed to and pulled from it. At one level, this distinction might
not seem clear: if objects are being exchanged, both sides may be pushing and pulling objects
from the other, so a client or server role becomes somewhat ambiguous. However, in the OBEX
model, there is a distinction. While both devices can indeed push and pull objects, it is the client
that initiates the operation and locates a server with the desired object exchange service. Hence,
the client and server roles are significant in the GOEP model. However, this does not imply any
master or slave role. The client and server roles are relevant at the OBEX protocol layer, but they
have no specified relationship to a device master or slave role; the GOEP client could be either a
master or a slave device, as could the GOEP server.

The GOEP assumes a form of authentication called bonding (as defined in the GAP). To
accomplish any of the object exchange usage models, the two devices engaging in the
transactions must be known to and trusted by each other. All of the object exchange profiles

155
assume this trust relationship. Additional forms of security, such as encryption or application-
level authentication (beyond that done at the Bluetooth transport level) are optional.

The GOEP defines the primitives for object exchange, two important ones being object push and
object pull. These operations are used in different combinations under different sets of
circumstances in all of the object push, file transfer and synchronization profiles. The simplest
form of generic object exchange, one-way data transfer, is instantiated in the object push profile.
[2]
Bidirectional data exchange occurs in the file transfer profile, which can be considered to be a
user-initiated object exchange, and in the synchronization profile, which acts as a rules-based
object exchange. In addition to the fundamental OBEX operations, the GOEP defines how to
establish and terminate OBEX connections and how to use common OBEX functions.
[2]
As noted in the OPP discussion below, this is not always strictly one-way transfer but it is based upon a model of pushing
data.

GOEP Usage
Like the SPP, the GOEP is not expected to be used directly by most applications. Instead, it
provides a foundation for other profile applications. In fact, the set of IrDA interoperability
protocols and profiles are intended to promote interoperability at the application layer for
applications that can use both IrDA and Bluetooth transports. Thus there could be many existing
applications that already implement file transfer, object push or synchronization functions using
OBEX. These applications should run with little or no change from IrDA to Bluetooth
environments.

New applications or middleware layers might implement the GOEP in support of accomplishing
the more concrete object exchange profiles; however, it would be of little value to implement just
the GOEP itself without at least one other concrete profile. The GOEP is a set of common
elements that enable the other object exchange profiles, not a usage model unto itself.

The Object Push Profile

The object push profile, or OPP, is the simplest of the object exchange profiles. As its title
implies, it essentially defines a one-way object transfer, although this is somewhat misleading.
The primary motivation behind the OPP is that of exchanging electronic business cards. OPP uses
OBEX, as do all of the object exchange profiles. The vCard object format mentioned in Chapter 9
can be used to represent a business card that can be exchanged using the OBEX protocol.
Certainly other types of objects besides vCards (including notes, messages, calendar entries and
in fact any object that could be exchanged using OBEX) can be used with the OPP, but the
rationale behind the OPP is the business card exchange usage model.

The OPP assumes compliance with the GOEP and then further details the scenarios, functions and
application considerations associated with object push. While it makes allowances for pushing
(and in certain circumstances pulling) generic objects between a client and a server, the OPP
focuses on pushing business card objects.

OPP Development
The OPP was the last of the object exchange profiles to be defined. Synchronization and file
transfer are fundamental usage models that have existed since the SIG was formed; thus they
were obvious profile candidates. Originally only these two profiles were defined within the object
exchange family. It was not until January 1999 that the SIG made a distinction between two
types of object exchange: a simple object push model and a folder-based browse, push and pull
model. The former supports a "business card exchange" usage scenario, and this concept of
156
unidirectional[3] object transfer eventually grew to become the OPP, although it was not originally
called object push. The folder-based file transfer model is embodied in the file transfer profile,
discussed below.
[3]
The previous footnote applies here also. The OPP can generally be thought of as a unidirectional object push, although
limited object pulling is also possible, as explained in following sections.

One key difference between the OPP and the file transfer profile is that the OPP instantiates a
usage case in which data objects might be offered in an unsolicited fashion. File transfer (and
synchronization too) normally are motivated by a desire of at least one party to acquire new or
updated information, and they often involve user intervention. Pushing objects is a different
model: at least one party might offer data without being asked, and that data is simply pushed to
a static location (think of an in-box) without any application knowledge of file or directory
structure. In some situations, [4] a user might configure her device to offer her electronic business
card to any other device that comes within proximity and has the ability to take the business
card. [5] This aspect is unique to the OPP and was one of the main reasons that business card
exchange, or object push in general, was developed as a separate profile.
[4]
Consider, for example, meetings and trade shows where business cards are xchanged; or any event at which a person miht
register herself by providing information typically contained in a business card (name, address, telephone number and so on).

[5]
The OPP does warn against automating the object push operation, though, and suggests that user intervention should be
required to initiate the object push and pull functions.

OPP Examined
Inheriting from the GOEP, the OPP defines a client and a server role, but further refines these
roles to those of a push client and a push server. Just as in the GOEP, the push server is the
device that provides the object exchange service, while the client is the device that does the
pushing (and perhaps pulling) of objects. Of course these operations can be viewed as
symmetric, in that if one device is pulling an object the other device might be considered to be
pushing that same object. As explained for the GOEP, however, the OBEX model does distinguish
between a client and a server, and the OPP maintains this distinction. As in the GOEP, the client
and server roles do not imply anything about the underlying baseband master and slave roles.

One of the first concepts introduced in the OPP is that of pulling business cards, which for a
profile dealing with pushing objects might seem unusual. Indeed, the OPP talks about push
clients that can both push and pull objects to and from push servers; this apparent dichotomy
merits further exploration. The key is found in the unique aspect of the OPP, noted above, that
involves offering (pushing) unsolicited data objects. From the viewpoint of the push client,
objects are always being pushed to a push server. In fact, during the errata process of the
version 1.0 specification, a clarification was added to the OPP (present in the version 1.0B
specification) explicitly stating that the push operation involves the client pushing an object to
the server. Yet the same push client can also pull certain objects, as described below, from the
push server. This concept is rooted in the OBEX transaction model, which has fundamental
elements of pushing and pulling objects as well as the notion of a client and a server. One way
that objects might be exchanged only through pushing is for a client to push an object to a
server, then have the devices exchange roles, then have the new client (old server) push an
object to the new server (old client). This would maintain a "push-only" purity but seems
unnecessarily complex, given that the underlying protocol supports both push and pull
operations. Thus OBEX and the OPP allow a "push centric" usage model that also includes an
optimization for pulling certain objects from a push server, although push servers are not
required to support this feature. This optimization removes the need for a client-server role
switch while still permitting the idea of a push-based usage model.

157
The OPP defines three functions: object push, business card pull and business card exchange.
Object push is, of course, the fundamental operation and the only mandatory function within the
OPP. The other two functions are optimizations of the type noted above, whereby the underlying
OBEX pull operation is used to extract a specific object, namely the owner's business card, from
the push server. The pull operation is optional for push servers to support; note that the pull
operation in the OPP is restricted to pulling only owner business cards and not other objects,
while the push operation can push any object (the file transfer profile, discussed below, provides
a more general bidirectional object exchange). The business card exchange function is really just
a composition of a business card object push and a business card pull function; thus it too is
optional. Figure 14.2 illustrates the typical operation of the OPP.

Figure 14.2. Object push profile typical operation. Note that business
card exchange is just a business card push along with a business card
pull.

Within the OPP are the procedures necessary to accomplish each of the object push, business
card pull and business card exchange functions. The object push operation allows several types of
objects to be pushed from the push client to the push server: vCard (version 2.1 of vCard is
required), vCal, vMessage and vNote. The SDP service record of the OPP also allows a value for
"any type of object," which would permit two devices to exchange objects other than those noted
above, assuming that both devices understand the object format to be exchanged. The business
card pull and business card exchange functions take advantage of the OBEX default get object,
which is an object that can be pulled by type rather than by name. By specifying that the default
get object contains the device owner's business card, the special case of pulling the default get
object allows the business card pull and exchange operations to be accomplished within the
context of the OPP.

The final point discussed here about the OPP is that of security. While exchanging objects
between devices can be very useful, it also could be dangerous when one considers security
exposures like viruses, violation of privacy and denial of service. All of these could be concerns if
devices exchanged objects without any precautions. The OPP discusses at least two types of
security precautions: the use of underlying Bluetooth transport security and user interaction. The
OPP indicates that authentication and encryption at the baseband level must be supported,
although they need not be used for every transaction. In addition, bonding (described in the
GAP), which requires a trust relationship between the two involved devices, must be supported,
but again need not be used for every transaction. If used, these security features can
significantly reduce the exposures noted above, since objects can be exchanged securely, and
only with devices that are known and trusted. Beyond this, the OPP mentions numerous times
that user intervention is recommended for many of the steps required to accomplish object push
and pull operations. The procedures in the OPP that outline each of the push, pull and exchange

158
functions all include steps where it is recommended that the user decide whether or not to accept
an object being pushed or to allow an object to be pulled.

OPP Usage
As discussed in the GOEP section above, middleware that implements the GOEP can provide a
foundation for applications that implement the other object exchange profiles. Since all of these
profiles share the common elements of the GOEP, it would not be uncommon to implement
synchronization, file transfer and object push all in the same device. Much of the code—that
which instantiates the GOEP—could likely be reused in each of the remaining profiles.

In fact, the OPP, from an application perspective, can be considered to be a special case of file
transfer. Like file transfer (discussed below), the OPP pushes (and perhaps pulls) objects between
a client and a server. The OPP restricts the types of objects that can be pushed and the
circumstances under which specific objects can be pulled, so in some respects[6] it is a subset or
restricted case of file transfer. Synchronization (also discussed below) could require significant
additional logic beyond the object transfer functions, but file transfer and object push, in many
cases, might be implemented in the same application (although the functions might be presented
to the user as two separate applications).
[6]
At least from an implementer's view, although perhaps not from an end user's view.

Application considerations for OPP include the provision of a user interface to allow the required
user intervention to occur. The user is the final arbiter of which objects are permitted to be
pushed onto and pulled from his device, so the application needs to permit this sort of user
interaction. Some of these functions might be candidates for integration with a general device
control application such as the Bluetooth piconet minder application described in Chapter 8.

The File Transfer Profile

The file transfer profile, or FP, [7] is the second of the three profiles in the object exchange family.
Like synchronization and object push, the FP uses OBEX to exchange objects, in this case files
and directories (or folders). During the early phases of the specification development, the
definition of TCP/IP over Bluetooth links was investigated (see the discussion of OBEX over
TCP/IP in Chapter 9) and thus the IETF file transfer protocol (FTP) was a candidate for a file
transfer profile. In the end, the version 1.0 specification did not address generic IP networking
over Bluetooth links, so FTP is not a part of the version 1.0 file transfer profile, although in the
future this almost certainly will be an alternative method for file transfer. Within the version 1.0
realm, though, file and object transfer is via OBEX.
[7]
We use FP rather than FTP to remove any confusion with the Internet file transfer protocol.

The FP can be considered to be a less restrictive, more robust form of the OPP in that it supports
full bidirectional pushing and pulling of objects, yet it supports only two object types: file and
folder. The FP does not directly address exchanging other object types like vCard, vCal and so on,
although those object types could certainly be packaged as files and could be transferred using
the FP.

FP Development
The OBEX protocol was originally adopted from the IrDA to support the synchronization usage
model. But OBEX also supports general file transfer, which has been used in IrDA for some time.
File transfer has been a fundamental Bluetooth usage scenario since the SIG was formed,

159
although it originally fell under the conference room scenario. As noted in the OPP discussion
above, the FP originally was an all-encompassing profile for object exchange but eventually was
split into the two distinct applications of object push, covered in the OPP, and folder-based
browsing, pushing and pulling that remains in the FP.

FP Examined
Client and server roles are defined by the FP in a manner similar to the other object exchange
profiles. In this case, the client is the device that initiates transactions and presumably will be
pulling files from the server, although the client might also push objects to the server as
described below. The server is the device that exports a folder to the client, which the client can
browse to initiate requests to pull files (or other folders) from the server. The server also accepts
other data from the client, including files that the client might push and requests to create or
delete objects on the server. While the client and server role definitions are important for
execution of the profile, many of the operations are symmetric, and it therefore seems likely that
many devices can and will implement both client and server functions of the FP. Indeed, the FP
notes that a device can support either role or both.

The operations defined by the FP are typical file manipulation operations, and they include:

• Pulling files and folders

• Pushing files and folders
• Browsing and navigating folders
• Deleting files and folders
• Creating new files and folders

Each of these operations is described from the client's viewpoint. Server operations occur in
response to the client operations, and include supplying requested files and folders and
responding to requests to delete and create objects. The folder browsing and file transfer
(pushing and pulling) operations are mandatory for both client and server, and these allow the
simplest form of file transfer, consisting of pulling a folder (the description, not the entire
contents of all files in the folder), selecting one or more files in that folder, and pulling those files.
Other operations that provide more advanced functions are optional; these include the ability to
pull entire folder contents (which could be accomplished with an iteration that pulls all files in a
folder, using just the basic folder browsing and file pulling operations) and the ability to create
and delete objects. The FP includes procedures to follow for both client and server to accomplish
these operations, along with the corresponding OBEX operations of the GOEP used in those
procedures. Figure 14.3 depicts typical FP operation; two different types of devices are shown to
illustrate that this usage scenario is not restricted only to traditional computers. Any two devices
with compatible file representations could use the FP for file transfer.[8]
[8]
Consider also devices such as digital cameras with distkette drives. Today pictures are transferred as files using the diskette.
Since the camera must have a file system, the diskette drive could be removed and the files could be transferred using the
Bluetooth FP.

Figure 14.3. Typical file transfer profile operation.

160
The FP assumes user interaction for all file transfer operations. In addition to mandatory support
(but optional use) of authentication and encryption, the FP mandates user intervention to initiate
file transfers. As in the OPP, security exposures could surface when files are moved to a new
device. Therefore the FP also requires user intervention to accept files from another device and to
pull files from other devices. The FP assumes that a user interface will be presented on a device
as a result of pulling a folder description. That user interface allows the user to browse and select
files to pull; similarly, local files can be browsed and selected for pushing to another device. So
while the protocol stack includes security features that can be used in file transfer operations, the
FP leaves to the end user the ultimate choice of which files to accept.

FP Usage
As described in the OPP section, it seems likely that both OPP and FP might be implemented
together in many devices. Once the GOEP support is in place, the additions needed to support
OPP and FPP are similar, and indeed might use the same code.

As noted in Chapter 3, file transfer is one of the most fundamental and useful functions of data
networking. Many device manufacturers believe that transferring files and other objects is one of
the most important scenarios to support in wireless communication, since most users are likely to
expect and make use of this function. Thus the FP plays an important role in helping to ensure
that file transfer can be accomplished in an interoperable fashion using Bluetooth technology.

Most devices that are likely to support the FP already have a file system and some sort of user
interface for that file system; in addition they probably already include some notion of
transferring files. While the mechanism used may or may not include OBEX file transfer,
implementations of OBEX that meet the requirements of the GOEP can probably be procured or
developed in a straightforward manner. With GOEP-compliant OBEX support in place, and with a
Bluetooth adaptation layer in the device's software stack that permits the use of Bluetooth links,
it should be possible in most cases to link (or perhaps adapt) existing file system user interfaces
for use with the Bluetooth FP.

An integrated user interface for FP (and also for OPP) might include a Bluetooth piconet minder
application like that described in Chapter 8 that allows users to select devices and services in
proximity. One option for a device that is selected in this way could be to obtain file folders from
that device and initiate file transfer (or business card exchange in the case of OPP as discussed
above). This seems to provide an easy, straightforward and intuitive method for extending the
existing functions of a given device or platform to take advantage of Bluetooth wireless
communication between two cooperating devices.

161
The Synchronization Profile
Synchronization is a popular data communications application and it has been one of the
Bluetooth usage models since the SIG was formed. The final member of the object exchange
family of profiles is the synchronization profile, or SP. The SP also builds upon the GOEP and uses
the IrMC protocol to synchronize objects.

Synchronization can be considered to be a special case of object transfer in which programmatic

decisions about which objects to transfer in which direction are made by synchronization software
logic. The actual synchronization process can range from very simple (unidirectional pushing or
pulling of a group of objects without any special treatment of those objects) to very involved
(selective exchange of objects or even partial objects using principles like differencing and
conflict resolution). Bluetooth synchronization as defined in the SP tends to more closely
resemble the former, although application logic can be added to the basic operations of the SP to
achieve more sophisticated synchronization models. Data can be synchronized between any two[9]
entities, including devices and networks.
[9]
In fact it is possible to synchronize data among more than two device, but we focus here on synchronizing between a pair of
devices, which most closely matches the Bluetooth communication model.

SP Development
Even though synchronization is probably the most complex of the object exchange scenarios, the
development of the SP preceded that of the FP and OPP. The group that developed the IrDA
interoperability protocols and their corresponding object exchange profiles was known within the
SIG as the synchronization group.

Since the SIG's beginnings, synchronization among many classes of devices (phones, PDAs,
notebook computers and others) has been a key usage case. In mid-1998, shortly after the SIG's
formation, the possibilities for automated synchronization (described more fully in Chapter 3) had
already been identified and the use of OBEX to accomplish these scenarios had already been
proposed. The incorporation of OBEX into the Bluetooth protocol stack was primarily intended to
support synchronization but, as we have seen, it also permits business card exchange, file
transfer and other object transfer usage cases. A fundamental requirement was to be able to
synchronize at least calendar and address book entries, although we will see that other data
types can be synchronized as well.

The synchronization task force within the SIG was unusual (although not unique) in that, in
addition to the five promoter companies, other contributing adopter companies (namely
PUMATECH™ and Extended Systems™, both of whose primary business is in the area of data
synchronization) participated in the specification's development.

Because synchronization from the outset was one of the main usage models, the SP was one of
the first profiles to be developed. It was not completed any sooner than most other profiles,
though, owing mostly to the fact that new enhancements to the profile (like provision for
automated synchronization and the addition of new and updated object formats) were added
after it reached an initial level of stability. One interesting aspect of the SP's development is that
it, along with the other object exchange profiles, was the first to add a section on service
discovery, with service record and SDP transaction information. In this respect it served as a
model for the other profiles, all of which (except for the "generic" ones) contain such information
in the version 1.0 specification.

SP Examined

162
The SP first defines device roles, which once again derive from the GOEP and consist of a client
and a server role. The client is the device that pulls data from the server, synchronizes that data
against its own local objects, and pushes the resulting synchronized data back to the server. The
server must support an object exchange service based upon the GOEP. As with the other object
exchange profiles, these roles have no bearing on the underlying baseband master and slave
roles. The SP indicates that the server is usually a phone or a PDA, with the client usually being a
PC. This is curious, since servers traditionally are considered to be the more robust and capable
machines. For the SP, it is the client that must contain the synchronization logic that determines
how to process the objects to achieve a synchronized version of them. Thus the SP describes a
PC as a typical client, since a PC is more likely to have available storage and processing power to
operate a synchronization engine. However, this need not be the case—any device could take on
the role of client or server, as appropriate. But today's typical synchronization models usually
synchronize a "small" server, such as a PDA or phone, against a "large" client like a PC or even a
network synchronization service. This model is preserved in the typical SP operation, which is
illustrated in Figure 14.4.

Figure 14.4. Typical synchronization profile operation.

The SP does not directly address the rules and processes necessary for a synchronization engine
to actually synchronize the objects with each other. Instead it defers to the IrMC specification
[IrDA99b] for that level of detail, since there is no particular reason to modify these aspects of
synchronization for use in Bluetooth environments. Instead the SP focuses on the procedures
needed to initiate and control the synchronization process. The SP discusses both client- and
server-initiated synchronization and provides procedures to follow for these. In the former case
there are two distinct scenarios: one for when the two devices are not yet known to each other
and another for when the devices have already bonded (that is, are known to and trusted by
each other). The second case is an optimization that takes advantage of the fact that the devices
have already bonded. Another procedure is supplied for automated synchronization, which is a
special case of client-initiated synchronization that is started without user intervention. Only
bonded devices can synchronize automatically.

Several different object types can be synchronized using the SP; the profile does not mandate
which object types must be supported. Instead it mandates that at least one of the defined object
types—phonebook (or address book), calendar, notes and messages—be able to be synchronized.
SDP is used to discover the supported object type(s) for the synchronization service.

The SP relies heavily on the GOEP and GAP, making use of several of the definitions and functions
in each. In particular, some of the features defined in the GAP and GOEP are used for security.
The SP mandates one of the highest security levels among all of the version 1.0 profiles. It
restricts synchronization to bonded, or paired, devices and requires the use of authentication and
encryption. Further, the OBEX-level authentication discussed in the GOEP optionally may also be

163
used. Unlike the FP and OPP, the SP does not call for user intervention as a security measure. A
user may initiate the synchronization transaction (although in the case of automated
synchronization, even this user interaction is unnecessary) and may be informed of the status
and results of the synchronization operation, and might even be consulted about desired actions
(say, for conflict resolution) during synchronization. But the user typically does not authorize
individual pushes and pulls of objects as in the FP and OPP (although the user might identify a set
or class of objects that are to be synchronized). Since the SP does not rely on the user as a
security arbiter, it specifies a relatively high level of other security functions from the protocol
stack.

SP Usage
Synchronization is a somewhat specialized application, although a popular one. It is a bit different
from file transfer and object push, although the SP uses many of the same underlying constructs
and functions that the FP and OPP use. Since the SP builds upon the GOEP, an SP implementation
could reuse OBEX middleware that is also used for FP and OPP. But unlike FP and OPP, which
could be very similar (if not the same) applications, SP would not necessarily be expected to be
implemented on all of the devices where FP and OPP are implemented. A digital camera, for
example, might implement a file transfer function, as described in footnote 94 above, but the
synchronization function on a camera seems less likely. As the SP notes, the devices most likely
to use synchronization are notebook computers, phones and PDAs; these are devices that
typically contain address books, appointments and other information (often called "PIM" or
personal information management functions).

The SP does not provide any detailed description of the synchronization process itself;
applications must look to the IrMC specification for guidance. Even beyond what is specified by
IrMC, though, there is room for application differentiation. Synchronization applications can add
value through enhanced user interfaces, optimized methods for exchanging and synchronizing
objects and the like.

In the case of automated synchronization that is enabled by Bluetooth proximity networking, an

application is still required, even though it may not be visible to the user at the time
synchronization is performed. First, a user presumably will wish to configure his device for
automated synchronization (just because this function is possible does not mean that every user
will wish to take advantage of it; some users might want to use this feature selectively). In
addition, some application software is needed on both the client and the server to discover the
automated synchronization capability and to start and carry out the synchronization operation. In
many situations it is also advisable to provide some sort of indication to the user that the
automated synchronization is underway (this probably should at least be a user-configurable
option, because many users are uncomfortable having their personal devices engage in nontrivial
communications with other devices without their knowledge).

A final application consideration in the case of automated synchronization[10] is how to deal with a
device that leaves the proximity range before the synchronization operation completes. Consider
a case where a user walks into an office with a PDA in a pocket or purse. If appropriately
configured, the PDA might begin synchronization with a PC in the office without the user being
aware of it. The user might leave the office in the middle of the synchronization process. Thus the
synchronization application needs to somehow account for this possibility, perhaps through a
checkpoint and restart process of partial synchronization or some other means.
[10]
This consideration also applies for user-initiated synchronization, but less so. When a user initiates synchronization, she is
probably likely to ensure that the devices being synchronized remain in range of each other until the operation completes.
When the synchronization is started automatically, however, a user might not even be aware that it is occurring (see "Hidden
Computing" in Chapter 3) and thus might very well walk into and then back out of proximity range before synchronization
completes.

164
Chapter 15. The Networking Profiles
The final group of version 1.0 profiles is what we term the networking profiles. This group
consists of the LAN access, dial-up networking and fax profiles. As noted in the preceding
chapters, each profile includes the aspect of a serial port, and the dial-up networking and fax
profiles include an element of telephony. But to our way of thinking the primary focus of these
profiles is on multihop (long-haul) data communications and networking. Clearly both dial-up
networking and LAN access are intended to facilitate data networking, and the fax profile seems
to have more in common with data networking (especially of the dial-up kind) than it does with
voice telephony. All of the profiles in this group include an element of access to a wide area
network for data communication.

All three of these profiles are intended to take advantage of Bluetooth wireless communication to
make a well-known existing task easier by removing the need for cables. Using a fax or accessing
a network, either directly or through a dial-up connection, are common tasks for many people.
The profiles examined here define how to do these tasks in Bluetooth environments, without
wires.

Each of these profiles, being more oriented to data than to voice, tends to be centered more
around a computer of some sort than around a phone. However, just as the telephony profiles
were applicable mostly to phones but also had aspects relevant to computers, the networking
profiles are mostly for computers but also have aspects relevant for phones. Indeed, the dial-up
networking and fax profiles can include both a computer and a mobile telephone, with the phone
being used as a fax or data modem. So these profiles are expected to be most useful for, and
most often implemented by, computers (stationary as well as mobile), but mobile telephones can
provide services that gain them a key role in some instances of these profiles.

Relationships
As shown in the profile relationships diagram (refer back to Figure 11.1), all three of these
profiles derive from the serial port profile, or SPP, that was described in the previous chapter.
This is not surprising, since the SPP and its associated RFCOMM protocol are intended to allow
legacy applications to make use of Bluetooth wireless transports, and all three of these profiles
instantiate legacy applications (that is, they define how to do existing tasks without wires). So
these profiles are a logical fit as members of the SPP family, which is the basis for the version 1.0
cable-replacement scenarios. They are also a good fit with the SPP technically, since all three
profiles involve applications that most likely will include the notion of communicating over a serial
port. In the case of dial-up networking and fax, the use of a serial interface is obvious, since both
use a modem (or at least the abstraction of a modem) to communicate over a telephony
network, and the most prevalent way to access nearly all modems is via a serial port. In the case
of LAN access, the use of the serial interface might not be directly evident, since a direct network
access cable is not necessarily modeled on a serial port. However, since the version 1.0 LAN
access profile uses the point-to-point protocol (PPP), this sort of LAN access tends to resemble
dial-up networking, and PPP maps well to a serial communication layer. Thus all three of the
profiles derive from the SPP and use a serial port communication model.

The dial-up networking and LAN access profiles together make up the Internet bridge usage
model. As described in Chapter 3, two similar yet different methods are defined for using
Bluetooth links as a bridge to a larger network like the Internet. Those two methods are defined
by the dial-up networking and LAN access profiles, respectively. Curiously, the fax profile has no
specific publicized usage model behind it. So in a way the fax profile is not related to any of the
other version 1.0 profiles except in being part of the SPP family tree. Indeed the fax profile is an
example of the SIG's defining a formal specification for the use of Bluetooth links to perform

165
easily understood usage models. In this respect the fax profile might be more similar to a printing
or scanning profile, neither of which exists in the version 1.0 specification although they might be
generated in the future. Since it does not derive from a common usage case, the fax profile is
related only indirectly to any other version 1.0 profiles. It does, though, have some similarities
with the other two networking profiles discussed in this chapter, which is why we include it here.

The Dial-Up Networking Profile

The dial-up networking profile, or DUNP, specifically calls for both computing and telephony
devices. Indeed, dial-up networking is an area where computing and communications overlap. In
this case telephony devices access telephone networks so that computing devices can use that
connection to access data networks. As compared to a typical wired scenario, the use of
Bluetooth wireless communication could enable two kinds of cables to be replaced: one between
the computer and the telephone and one between the telephone and the telephone line
(assuming the use of a cellular mobile phone in the DUNP). Dial-up networking is possible with
many mobile telephones today, without the use of Bluetooth technology, but normally a cable is
needed between the computer and the telephone, even though the wide area network access via
the mobile phone is wireless. The use of Bluetooth wireless communication removes the need for
this last cable in dial-up networking, enabling a completely wireless[1]solution.
[1]
No cables are needed for communications. We ignore wires that may be needed to supply electrical power, since most
mobile devices can operate for some period of time untethered from an electrical power supply.

Dial-up networking involves the use of a telephone—in this case a mobile phone with Bluetooth
technology—as a data modem. The computer uses the modem service of the telephone (probably
unaware that a physical wired modem is not present) along with network dialing software to
reach the network's access point that is connected to the (probably wired) telephone network.
The DUNP even explicitly addresses the use of a physical modem, rather than a mobile telephone
with a modem service, to perform dial-up networking. In this case such a modem would
presumably be connected to a wired telephone line while providing a wireless Bluetooth link to its
client(s). In this respect such a modem would resemble a voice or data access point (as are used
in the cordless telephony and LAN access profiles, respectively) in that it offers a specific type of
wireless access to some back-end network. Regardless of the physical device used, the computer
is using a modem service to access a traditional telephone network that in turn offers access to a
data network such as the Internet.

DUNP Development
The evolution of the DUNP (and its associated profile, the LAN access profile) is interesting.
Originally there was a single Internet bridge profile, just as there is an Internet bridge usage
model. As the marketing requirements document (MRD) was refined and additional thought was
given to the topic of network access, two types of network access distinguished themselves. The
MRD defined the concept of data access points and split these into two types: wide area network
access, using modems, satellites, cellular networks and the like; and local area network access,
using an access point to directly connect to an Ethernet, token-ring or similar LAN.

At first the Internet bridge profile attempted to cover both of these types of data network access.
It later became clear that the two scenarios, while similar from an end-user perspective (and
thus both considered to be part of the Internet bridge usage case), had different technical
underpinnings and would probably require quite different implementations in devices. Thus the
Internet bridge profile (like the three-in-one phone profile discussed in Chapter 13) was split into
its two constituent parts: dial-up networking (now the DUNP) and LAN access (discussed below).
The DUNP was developed by the telephony control task force within the SIG, since much of the
profile dealt with telephone call control (recall that at this time a telephony control protocol called

166
TCS-AT still existed—Chapter 10 discusses this topic further—and much of the DUNP deals with
AT commands over RFCOMM to set up and manage the modem service). The LAN access profile,
on the other hand, was developed by the SIG's networking task force, since telephony was not
really relevant to that profile. Even though both of these profiles spring from a common usage
model and they do have some technical similarities, they also have some differences at the
implementation level.

DUNP Examined
The DUNP defines device roles for a gateway device and a data terminal device. The gateway is
the device that offers a modem service to allow connection to the network that is being accessed;
gateways typically are modems or mobile telephones. The data terminal is the device, usually a
computer of some sort, that is using the modem service of the gateway device to access a data
network. While dial-up networking is usually thought of from the viewpoint of the data terminal
device accessing a network, the DUNP also notes that the reverse situation that allows the data
terminal device to be dialed up via the modem device is also supported. Normally the data
terminal device wishes to obtain access to a network, rather than to permit dial-up access to
itself, although there are cases where the DUNP might be used for incoming connections. These
gateway and data terminal device roles have no implications for the baseband master or slave
roles.

Recall that while we consider the DUNP to be part of a networking group of profiles, it is a
derivative of the serial port profile. The RFCOMM protocol is used to transport modem AT
commands between the data terminal (computer) device and the gateway (phone or modem)
device to establish and manage the connection to the network. The DUNP identifies a small
subset of standard AT commands as defined in the ITU-T V.250 standard [ITU99] that are used
to set up and manage the modem functions of the gateway device.

The DUNP addresses optional support for audio feedback. While its primary purpose is to support
data calls, the audio capabilities of Bluetooth wireless communication permit a richer emulation of
a wireline modem call by allowing for audio feedback. If audio feedback is supported, the modem
tones associated with the call can be transmitted back to the data terminal device for playback
through its audio output channel. Audio feedback can provide information to the end user about
the call's progress, allowing the "squeaks and squawks" that many users have become
accustomed to with dial-up networking also to be present, if desired, when using Bluetooth
wireless links. The service record of the gateway's modem (dial-up networking) service indicates
whether or not audio feedback is supported, so SDP can be used to determine whether or not this
feature is available when the connection between the gateway and data terminal is established.
Typical DUNP operation, including optional audio feedback, is depicted in Figure 15.1.

Figure 15.1. Typical dial-up networking profile operation. Note that the
gateway device also could be a wireless modem access point connected
to a wired telephone network.

167
Security in the DUNP is handled at several levels. Support for baseband pairing is mandatory,
although it need not be used for every connection. However, since the most common case of dial-
up networking with Bluetooth technology is likely to be a computer using a mobile phone to
access the network, charges are likely to be incurred from the phone service provider for the
wide-area cellular connection of the phone call. Thus pairing is advisable, since it can restrict use
of the phone's modem service to known and trusted devices. A phone's owner may wish to make
his phone's modem service available to his own computer(s) but probably not to anyone else's
computer that happens to be in range. The DUNP also calls for the use of baseband
authentication and encryption functions. At an application level, additional authentication such as
a user identifier and password are likely to be required to access the network, once a connection
to it is established.

DUNP Usage
The intent of the DUNP, like that of most other serial profile family members, is to enable legacy
applications to take advantage of Bluetooth wireless links for existing functions. Dial-up
networking is a common usage scenario, with many applications available for using modems to
access networks. Through the use of RFCOMM serial port emulation and a minimal subset of well-
known and standard AT commands, the DUNP provides dialer applications with a functional
interface that is virtually identical to that which they use in the wired world. With the use of
Bluetooth adaptation software, as described in Chapter 5, it should be possible for legacy
applications to conform to the DUNP with little, if any, change.

Once dialing software has established the connection to the network, multitudes of applications
that use standard networking protocols (like TCP/IP, HTTP, FTP and so on) can execute using the
dial-up network link and the services available in the network. Hence the DUNP enables other
applications such as browsers, e-mail and the like.

For more information about how the DUNP is used and how it relates to the LAN access profile,
discussed below, see the following section "DUNP and LAP Compared."

168
The LAN Access Profile
The LAN access profile, or LAP, is the second profile that, along with the DUNP, instantiates the
Internet bridge usage case. Like the DUNP, it uses established networking protocols over a
Bluetooth wireless link to enable a computing device to obtain access to a data network. In the
case of the LAP, a network data access point is used to connect to the network rather than a
phone or modem used with a dial-up connection. Use of the LAP is analogous to directly
connecting to a data network with an Ethernet (or similar) cable, although the usage is restricted
to the use of the IETF point-to-point protocol, or PPP, over the Bluetooth link.

Like the DUNP, the LAP is based upon the SPP and is aimed at cable replacement. In this case the
network access is local area, rather than wide area as in the DUNP. The LAP notes that this
version 1.0 profile defines just one method for accessing networks via data access points, with
others likely in the future (Chapter 16 describes some other Bluetooth LAN access possibilities).
The most commonly described usage case for the LAP is for a computer to access a LAN,
although the LAP does enable the development of data access points that could be used
simultaneously by multiple Bluetooth clients. A specialized case of the LAP is its use to directly
connect two devices for PPP communication between them rather than to access a larger
network.

LAP Development
As noted in the DUNP discussion, the LAP was originally part of a single Internet bridge profile.
When that profile was split, the LAP was developed by the SIG's networking task force. Even
though the LAP and the DUNP both describe a method of realizing the Internet bridge usage case,
they have some technical differences, because dial-up networking is a bit different from direct
LAN access using PPP.[2]
[2]
Although, as the LAP notes, once a PPP connection is established between two devices, further interaction can occur much
as it does for dial-up networking, which in turn often uses PPP internally.

The networking task force in the SIG was at one time called the TCP/IP task force, since its
original mission was to define methods for traditional IP networking in Bluetooth environments.
The group later decided that a more appropriate name for the task force was Bluetooth
networking, since not all of the networking considerations were related to TCP/IP, although
clearly IP networking is especially important. Unlike most other task forces, this group did not
define any protocols in the stack but rather investigated ways to use traditional networking
protocols, such as those defined by the IETF, over Bluetooth links. Thus there is no corresponding
protocol stack layer in the core specification for the LAP. It is only this profile that defines LAN
access with Bluetooth wireless communication, and it uses the RFCOMM protocol and the IETF's
PPP. The LAP forms an important foundation for more robust future networking profiles, and it
has always been considered to be an initial solution, but not an exclusive solution, for Bluetooth
networking.

At first glance, it might appear that the solution developed by the networking group for LAN
access is not as robust as might be expected, especially for peer-to-peer communication in LAN
environments. However, the group's choice was not made lightly. This direction was chosen after
long deliberations that considered the feasibility of other solutions, the time to market, and the
time constraints for developing and publishing the version 1.0 specification. Peer-to-peer
communication in purely ad hoc, wireless networks is an area that is not yet mature. While many
industry and academic efforts are underway, there is no robust, fully tested, widely accepted
method for achieving it, especially one that is suitable for resource-constrained devices like many
of those used in Bluetooth wireless communication.

169
The SIG's networking group seriously contemplated IP networking issues like address
assignment, name resolution, default router assignment, and so on. In an ad hoc network with
no infrastructure services such as DNS and DHCP, these and other necessary network support
operations present unique problems. It became apparent that a solution to these problems could
have a scope larger than just Bluetooth piconets. Had the SIG attempted to develop a general
solution, it very likely would not have aligned with other industry activities that are proceeding
toward maturity; furthermore, any such solution would have required prohibitive time
investments in development and testing. Thus, a general solution that addresses the difficult
issues associated with ad hoc IP networking (and that would enable several aspects of the
conference table usage case described in Chapter 3) was deferred until after version 1.0. Instead,
the networking group focused on developing the PPP-based LAN access solution—for two
reasons: (1) PPP is a widely used Internet standard that addresses host configuration and
preparation for IP communications; and (2) many devices, including popular PDAs, today support
IP communications over PPP for dial-up access to IP networks. Hence, a large number of
computing devices can support the Bluetooth LAN access profile without modification to their
installed networking stack—a consideration that should not be overlooked.

Support for more general ad hoc peer-to-peer networking is an issue revisited by the SIG, as
discussed in Chapter 16.

LAP Examined
The LAP defines device roles of a LAN access point and a data terminal. The LAN access point
(which is just different terminology for a data access point; we use the latter term) is the device
that exports PPP server function and is connected to a LAN, which might be Ethernet, token-ring
or some other type of LAN.[3]The data access point is typically envisioned as a small "wireless
plug"[4]connected to the wiring infrastructure of the LAN, and thus often mounted on a wall very
much like a cabled data access point would be, perhaps in an office, a conference room, an
auditorium or even in a home. The data terminal is the client of the data access point and thus
contains PPP client function, which is used to establish the connection with the data access point
that in turn permits access to the LAN. In the most general case, there is an association between
these device roles and the baseband master and slave roles. Much as a cordless telephony
gateway must be a piconet master (as described in Chapter10 and Chapter13), a data access
point must also assume the master role if it supports more than one data terminal client. In the
case of only one data terminal client (for example, when the data access point is dedicated to a
single client or when the LAP is used for PPP networking between two computers), it does not
matter which device assumes the master role, but in general the data access point is assumed to
be the master in LAP applications.
[3]
The LAP generally assumes the scenario of wireless access to a wired LAN, although access to a wireless LAN, such as one
that uses 802.11 technology, is at least conceivable but might present some technical challenges.

[4]
Often informally called a dongle.

The use of PPP is key to the LAP. PPP is ideally suited for the connection between the data access
point and the data terminal. IP network traffic (as well as other network protocols) can flow over
the PPP link. PPP is also designed for use over serial connections, and thus within the LAP, PPP
operates over RFCOMM.

The LAP is essentially a procedure for establishing a PPP connection between the data access
point and the data terminal. Once the PPP connection is established, conventional IP solutions can
be employed for networking functions such as obtaining an IP address. Standard IETF protocols
can then flow over the PPP connection to access services on the LAN, much as in dial-up
networking. Unlike dial-up networking, though, the PPP connection in the LAP is established
directly over a packet-oriented data link and thus does not require modem functions and

170
associated AT commands to establish the connection. Typical LAP operation with a single data
terminal is shown in Figure 15.2; note that there could be multiple data terminals if supported by
the data access point (in this case, each has its own separate Bluetooth transport and PPP
connection to the data access point, and the data access point must be the piconet master).
Figure 15.3 shows the special case of the LAP between two individual computers.

Figure 15.2. Typical LAN access profile operation. Note that data access
points optionally may support multiple data terminal clients.

Figure 15.3. LAN access profile operation for networking between two
devices. Either device can assume either role (data terminal or data
access point).

The LAP has an interesting attribute that merits discussion. The service record associated with
the PPP/RFCOMM service makes use of the ServiceAvailability attribute defined by SDP. The LAP
is the only version 1.0 profile that specifies use of this attribute, although as a universal service
attribute, it could be used by any service. A data access point could support many data terminal
clients, and the ServiceAvailability attribute is used to indicate the degree of utilization of the
data access point (how "busy" it is with current clients). Thus in the case where multiple data
access points exist for a given LAN (perhaps in an auditorium or large conference room), a data
terminal can perform SDP transactions with each data access point to locate one that has
capacity to handle additional clients. The SDP specification defines the ServiceAvailability
attribute generically without specifying particular values to indicate degrees of utilization. The
LAP specifically defines values for ServiceAvailability for data access points,[5] with a percentage
range that roughly corresponds to the number of possible active slaves in a piconet of which the
data access point is master.
[5]
The actual values are found in the Bluetooth Assigned Numbers portion of the core specification (volume 1).

171
Security is a significant consideration of most networks; hence the LAP defines a high degree of
security for the PPP connection that permits access to those networks. The LAP mandates
authentication using device pairing, which can help to ensure that only authorized devices gain
access to the network. This is important for corporate and other private networks; the network
owner may not wish to grant network access to any device that happens to be within range of a
data access point (that device might belong to a visitor who is not authorized to access the
private network). PIN-based authentication is required to authenticate with a data access point,
so network access could be granted by divulging the PIN to the prospective data access point
client. For more public data access points where it may be desirable to allow almost anyone to
use the LAN, the PIN could be publicized to all persons who ought to have access, or—as the LAP
specifies—a default, zero-length PIN could be used, effectively permitting universal admission to
the data access point and hence to the LAN. In this latter case, additional security measures
could be necessary to restrict access to services on the LAN or to other networks that may be
accessible from the LAN. The LAP also insists upon the use of encryption of all the traffic on the
Bluetooth wireless link between the data terminal(s) and the data access point. In addition, other
higher-layer security mechanisms, including various PPP authentication schemes mentioned in
the LAP, may be used to authenticate and authorize users of network resources.

LAP Usage
As with the DUNP, the motivation for the LAP is to access networks, primarily (but not
exclusively) IP networks. So if middleware exists for PPP, along with a requisite IP stack, the
same sorts of applications noted for the DUNP can execute over the LAP's PPP link: browsers, e-
mail, FTP file transfers and so on. IP networking stacks and applications that use them are
common in many devices, and these legacy applications are enabled for use with Bluetooth
wireless communication via the PPP link defined by the LAP. Furthermore, other protocols can
operate over the PPP link. Notable among these is WAP. The specification does not include a WAP
profile; however, the use of a Bluetooth PPP/IP connection as a bearer for WAP traffic is described
in volume 1 of the specification, and that part of the specification contains some information
similar to that found in profiles. In particular, SDP service records are defined for WAP
interoperability, and the PPP connection as defined by the LAP for IP traffic is exactly what is used
for WAP network access.

In the next section we offer additional information on how the LAP is used as well as a
comparison of the LAP usage versus that of the DUNP.

DUNP AND LAP COMPARED

Because the methods used to access IP-based services in the DUNP and LAP are similar, we
assert that a data terminal device that implements both profiles could be developed with little
more effort than would be required to implement just one. Moreover, the user experience for
both of the profiles on such a device could be quite similar, with applications providing the same
user interface and procedures for both the DUNP and the LAP. This is an added benefit to the
user, who thus can be concerned with only the task at hand (perhaps browsing or accessing a
corporate application), rather than with the underlying method used to connect to the data
network.

For either of these two networking profiles, the ultimate objective is to enable a connection
between the PPP client function in the data terminal device and a PPP server function residing at
the edge of an IP network.[6] The primary difference in the two profiles is the role that the
Bluetooth link plays in enabling this connection. Figures Figure 15.4 and Figure15.5 highlight the
differences and similarities in supporting IP communications using these two profiles, showing a
typical protocol stack used in each. To connect, log in, and authenticate oneself to a PPP service,
one may use a dialer application, like those used to connect to an Internet service provider over

172
telephone networks. In the case of the DUNP, a modem connection is required to access the PPP
server, and the Bluetooth link replaces a serial cable between the data terminal device and the
gateway device that contains the modem service. In the case of the LAP no modems are
involved, but the Bluetooth link is used as a substitute for a direct serial connection between the
PPP client in the data terminal and the data access point that exports the PPP server function.
Apart from this difference regarding the role of the Bluetooth link in the two profiles, the same
applications and processes used to achieve IP connectivity with the DUNP can be reused in the
LAP.
[6]
Note that other protocols besides IP can be multiplexed over PPP. Thus the IP discussion here applies for other protocols,
too, but we focus on IP as the most commonly used networking protocol.

Figure 15.4. Use of a Bluetooth link in the dial-up networking profile (DUNP).

Figure 15.5. Use of a Bluetooth link in the LAN Access Profile (LAP).

173
Even though similar applications can be used with both profiles, one interesting usage scenario
that differs between the LAP and the DUNP is the aspect of mobility. In the typical case of the
DUNP, the Bluetooth link is between the computer and the phone, while the network connection
is carried over the phone's wide-area cellular connection. Since cellular networks use handoff
technology to deal with changing locations of the phone, the network connection can be
maintained even when the user is mobile, so long as the computer and the phone stay within
proximity to each other (which is likely, since both are personal devices presumably kept with
their user). With the LAP, though, the Bluetooth link is the network connection. So long as a user
remains in proximity to the same data access point (as might occur in a conference room or
auditorium), the network connection can be maintained. But if the user is mobile, the PPP
connection to a given data access point could be terminated, requiring a new connection to be
established to a new data access point in the new vicinity, even if both data access points are
connected to the same LAN. The specification does not address any sort of handoff scheme for
this scenario. Solutions do exist, but they must be implemented at the application layer of the
client and/or in network middleware (which might or might not be directly associated with the
data access point).

The Fax Profile

The fax profile, or FaxP,[7] might be considered a special case of the DUNP (and in fact the DUNP
mentions fax calls when it describes the data calls necessary for dial-up networking, but it states
that fax is not part of the DUNP and instead is addressed in the FaxP). In many respects fax and
data transmissions are similar: both modulate and demodulate commands and data between two
endpoints over a telephone line. Yet there are differences, much as a data modem is
distinguished from a fax modem, and there are special considerations for faxing over Bluetooth
wireless links. Thus fax function is addressed in a separate profile, and even without a specific fax
usage model, it is an assumed scenario due to its similarity to data calls.
[7]
We use the term FaxP to distinguish it from the file transfer profile that we call FP.

FaxP Development
None of the published Bluetooth usage scenarios address fax function. The MRD[8] makes only two
passing references to fax usage cases. So rather than having an associated usage model with a
catchy name, the FaxP simply tells how to do wireless faxing using Bluetooth links. While we
treat the FaxP here as a networking profile, its heritage is in the telephony-based profiles. As
already noted, the DUNP and LAP were originally parts of a single Internet bridge profile. When
the DUNP was made into its own separate profile, it initially included fax scenarios as well as dial-
up data networking (this is evident from the many similarities in the structure and content of the
two profiles, as well as the references to fax calls that remain in the DUNP). Soon thereafter, the
FaxP was also split into its own profile based upon the considerations above that make fax its
own distinctive usage case.
[8]
Recall from Chapter 4 that the marketing requirements document preceded the specification and defined the usage models
that drove the requirements for protocols and profiles.

At about the same time that the FaxP was split into a separate profile, there was significant
debate about the fax classes that could and should be supported over Bluetooth links. We do not
present a detailed discussion of fax technology here,[9] but we do describe enough about fax
classes to frame the issue regarding fax in Bluetooth wireless communication. In what is called
Group 3 fax,[10] there are three protocols of interest within the FaxP context: class 1, class 2.0
and class 2. The former two are ITU-T standards while the latter is an industry de facto standard,
and indeed class 2 and class 2.0 are different (although similar, and much of the following
discussion of class 2.0 generally applies to class 2 also). The debate about fax class support in
Bluetooth environments centers around timing requirements of these fax classes. A difference
174
between class 1 and class 2.0 fax is the functional split of two major components of fax
transmission: call control and image processing. In the typical FaxP usage case, a computer
works with a mobile phone to send and receive fax information, similar to the typical DUNP case.
In this typical configuration, both image processing and call control functions are performed by
the computer for class 1 fax; whereas for class 2.0 the phone manages call control with the
computer handling image processing. There was some concern within the SIG that the Bluetooth
link between the computer and the phone could cause delays sufficient to violate some fax timing
requirements. These concerns are most pronounced with class 1, where the computer must
manage the call control functions over the Bluetooth link in addition to the image-processing load
(the division of function between devices in class 2.0 makes it somewhat less susceptible to these
timing violations). There was a proposal within the SIG to make support for class 1 fax optional
based upon these concerns. After much study and debate, the SIG finally chose to mandate
support for at least one of the three classes (1, 2 or 2.0), without specifying any particular one as
mandatory to support, and without directly addressing the issue of timing requirements with
regard to these classes (these considerations are left to the implementer, with the guidance of
the Bluetooth specification and fax standards).
[9]
Interested readers can refer to, for example, [ITU96] as well as the standards listed in the "References" section of the Fax
Profile chapter of the Bluetooth specification [BTSIG99], volume 2.

[10]
More properly, Group 3 facsimile, but we will continue to use the common term "fax."

FaxP Examined
It is not surprising, given the history of profile development, that the FaxP is quite similar to the
DUNP. The examination of the FaxP here is abbreviated, since much of the DUNP discussion also
applies to the FaxP. The FaxP defines the same device roles as the DUNP, namely a gateway
device (typically a mobile phone or a fax modem) and a data terminal device (typically a
computer). These device roles have no bearing on the baseband master and slave device roles.
Like in the DUNP, both outgoing calls (fax send) and incoming calls (fax receive) are permitted.

Since the FaxP is a derivative of the serial port profile, AT commands are used over an RFCOMM
link for call control. The AT command set used is dependent upon the fax class(es) supported.
Audio call progress feedback is optional and is handled in the same manner as with the DUNP.
Typical FaxP operation is shown in Figure 15.6; note that the gateway device also could be a
modem.

Figure 15.6. Typical fax profile operation.

175
The FaxP SDP service record is used to determine whether or not the optional audio feedback
support is present, as well as to determine the fax class(es) supported, although the latter also
can be determined using AT commands.

Because fax transmissions are generally considered reasonably secure, the FaxP mandates a
relatively high level of security. Authentication and encryption are required, as is support for
bonding and at least one of security modes 2 or 3 (described in Chapter 12).

FaxP Usage
Clearly the FaxP is another example of a profile to enable existing usage scenarios to be
accomplished by existing applications in a wireless fashion. Fax technology is quite mature and is
widely used today. Through the use of modem and serial port emulation, the FaxP is designed to
allow legacy fax applications to operate over Bluetooth links with little, if any, change.

176
Part 4: The Future of Bluetooth Technology
This book concludes with an examination of future directions for the Bluetooth
technology.Chapter 16 discusses some possibilities for future applications of
Bluetooth wireless communication, including topics addressed by the SIG
subsequent to the publication of the version 1.0 specification. These include
automotive, imaging, printing and other scenarios. We also discuss the product
landscape and marketplace for Bluetooth devices in the year 2000 and
beyond.Chapter 17 offers concluding remarks about present and future
opportunities in this field.

Part 4 is intended to provide a snapshot of Bluetooth wireless communication in the

year 2000 and a vision of where the techology may be headed in the future.

Chapter 16. Beyond the Version 1.0

Specification
Having examined the version 1.0 specification in detail, we now turn our attention to post-version
1.0 matters. In particular we look into the activities of the SIG in developing new profiles, as well
as some possibilities for products that use Bluetooth wireless technology. The thesis of this
chapter is on new applications that might appear in the realm of Bluetooth technology, rather
than on factual content that was explored in the main body of the book. Hence the tone of this
chapter and the one that follows is a bit different.

Earlier in the book we noted that for version 1.0 the SIG focused on enabling basic cable-
replacement scenarios. The SIG consciously decided to defer profile development that would
support many more advanced yet interesting and valuable usage cases so as to accelerate the
development of the version 1.0 specification. Many of these new usage models are addressed in
profiles developed after version 1.0 publication. In this chapter we examine those profiles under
development in the year 2000 along with other associated work within the SIG.

Just as the version 1.0 profiles are not a complete picture of what Bluetooth wireless technology
offers, neither is the second round of profiles[1] to be published by the SIG the final answer about
the specification. Indeed, the story for Bluetooth wireless communication may well be one
without a definitive end, since industry innovation is likely to spawn new applications of the
technology for years to come. In this chapter we examine just a few possibilities that go beyond
the first two editions of the specification. In conjunction with the SIG's specification work, we also
explore the landscape of Bluetooth products, both those that are being marketed and those that
are likely to appear in the foreseeable future.
[1]
Tentatively called version 2.0 of the specification, although this is subject to change before final publication.

The SIG Reconstituted

The SIG's original charter technically expired with the publication of the version 1.0 specification.
That charter called for the specification's delivery, and once that was achieved, the SIG in one
sense ceased to exist. The bylaws of the SIG allowed for the publication of errata to the original
specification, and version 1.0B was published in December 1999 with many corrections and
clarifications to the version 1.0A specification.

177
The SIG's work didn't really stop, though, after the initial specification was published. During the
latter half of 1999, representatives of the original promoter members of the SIG held frequent
discussions about the next steps that the SIG would take. These discussions culminated in
December 1999 with the announcement of a newly chartered SIG which included four new
promoter companies (3Com, Lucent, Microsoft and Motorola) in addition to the original five
founding promoter companies (Ericsson, Intel, IBM, Nokia and Toshiba). Along with the new
promoter group, the SIG also had a new organization, including a new class of members called
associates. Associate members are somewhere between adopter and promoter members and
may participate in specification development and SIG technical meetings. The associate
membership category was created to permit broader participation in the SIG, and several
companies immediately joined as associates. At the same time, the SIG also announced the
formation of several new working groups, most of which are developing new profiles. This work,
underway in 2000, is reviewed below.

New Working Groups and Profiles

Some important usage models were deferred during the development of the version 1.0
specification, and a number of new ideas for usage scenarios have surfaced as the Bluetooth
technology has evolved. In 2000, the SIG chartered several new working groups to explore many
such usage models, with most of them resulting in new profiles. A brief review of each working
group underway in 2000 follows.

It should be noted that with the version 1.0 specification available and with many
implementations proceeding based upon its contents, backward compatibility is a key concern of
the SIG. All of the working groups include compatibility with the version 1.0 specification as one
of their core objectives. Indeed, this is why most of the version 2.0 specification work is
embodied as profiles: profiles provide a way to introduce new function without affecting those
capabilities that already exist. All profiles, save the GAP, are optional. As new profiles become
available, implementers may choose to support them without affecting existing functions. The
protocols in the core specification are not expected to change significantly as the post-version 1.0
work proceeds; in some cases, optional extensions may be developed. But most new specification
content will be delivered in the form of profiles.

Radio 2.0 and Coexistence Working Groups

Chaired by Ericsson and Nokia, the radio 2.0 working group investigates optional extensions to
the radio specification. Among these are increased data rates, improvements to baseband
functions (especially the inquiry process), "handoff" capability to support roaming, and better
coexistence with other technologies operating in the 2.4 GHz spectrum.

Perhaps the most prominent feature under investigation by the radio 2.0 working group is that of
higher data rates. The quest for more bandwidth in all types of communication seems insatiable,
and most technologies are constantly striving for higher speeds and throughput. Increased data
rates have been seen in both wired and wireless communication, with Ethernet and IrDA being
but two examples. Bluetooth wireless technology is no exception, and many knowledgeable
engineers believe that Bluetooth wireless communication can occur at higher speeds. In 2000,
the radio 2.0 working group was looking into at least doubling the raw transmission speed of
Bluetooth links to 2 Mbps, with some proposals that could increase data rates even more
dramatically.

Like all of the working groups, the radio 2.0 group is concerned with backward compatibility. The
radio 2.0 specification is expected to take the form of optional extensions. Fundamental principles
of the Bluetooth radio, including global operation, low cost and short-range communication, will
continue to be at the heart of the radio specification.

178
One particular radio consideration, that of harmony with other 2.4 GHz technologies, merits its
own working group: the coexistence working group. This group is concerned with issues such as
interference and performance impacts when multiple RF technologies are used in the same time
and space. Working with other organizations, such as HomeRF™ and the IEEE 802.11 and 802.15
working groups, the coexistence working group produces recommendations to allow the various
2.4 GHz technologies to work well together. One example is the SIG's collaboration with the IEEE
802.15 working group, which was formed in the spring of 1999 to develop standards for wireless
personal area networks. In the summer of 1999, the SIG proposed the version 1.0 Bluetooth
specification, which had just been published, as a potential IEEE 802.15 standard. A task group
within the 802.15 working group was then formed to draft an IEEE 802.15 standard based upon
the group of Bluetooth transport protocols[2].
[2]
The IEEE 802 standards are concerned only with the two lowest communication layers, the physical and data link layers. As such, only the group
of Bluetooth transport protocols is relevant to an 802 standard, and this subset of the protocol stack is the basis for the 802.15 proposal.

Extensions and Enhancements Working Groups

All of the working groups discussed in this section had their genesis in usage cases that were
addressed to some extent during the version 1.0 specification development. In each case, some
preliminary work was done within the SIG during its early days, but for various reasons the
complete profiles for these usage scenarios were deferred. Because the SIG fully expected to
complete these profiles for version 2.0 of the specification, the foundation for each was laid in
version 1.0. Some of the resulting profiles will trace back to usage cases described in Chapter 3
for which no version 1.0 profile exists. The working groups dealing with version 1.0 extensions
and enhancements are:

• Personal Area Networking (PAN): The PAN working group is co-chaired by Microsoft
and Intel and is focused on general IP networking issues, including security. As described
in Chapter 15 and elsewhere, the version 1.0 specification does not define a general
solution for ad hoc IP networking; it addresses only dial-up networking and LAN access
using PPP. The SIG's original networking working group had some preliminary discussions
of a general IP networking solution but realized that a comprehensive profile would
require more time than was available for the version 1.0 specification. The PAN group was
formed to continue this work, with the deliverable of a profile that addresses secure ad
hoc networking to support usage models such as collaborative applications (much as
described in "Ad Hoc Networking" in Chapter 3).
• Human Interface Devices (HID): Chapter 3 described the cordless computer usage
model and noted that no profile existed for it in version 1.0. The HID[3] working group is
intended to focus primarily on such a usage scenario. HID refers to computer peripherals
such as keyboards, mice, joysticks and the like. HID is an existing specification for the use
of such devices with computers, and the HID working group, chaired by Microsoft, is
charged with the development of a profile to realize the use of HID over Bluetooth links to
realize the cordless computer usage model.
[3]
Not to be confused with the hidden computing usage model.

• Printing: While none of the initial usage models dealt directly with printing, it is such a
common task that it was discussed in numerous working groups. The cordless computer
usage model describes printer peripherals, and printing is a common example for service
discovery scenarios. Co-chaired by Hewlett-Packard® (an associate member of the SIG)
and Ericsson and populated by numerous printing experts, the printing working group
addresses various usage cases that involve printing over Bluetooth links. These include
direct-to-printer scenarios using peer-to-peer communication to print from various devices
to a Bluetooth printer.

179
 • Still Image: In "The Instant Postcard" section of Chapter 3, we note that that scenario is
unique among the version 1.0 usage models in that it includes a personal device other
than a mobile phone or computing platform, namely a digital camera. The still image
working group, chaired by Nokia, works on details of image handling and manipulation in
Bluetooth environments, with the instant postcard usage model at the heart of its focus
area. This working group formalizes the model of image transfer as described in the
instant postcard scenario, and also addresses manipulating the image, perhaps for display
or printing (and thus works with the printing working group).
• Extended Service Discovery Profiles (ESDP): Chapter 8 described a design objective
of SDP to permit coexistence with other industry service discovery protocols. The ESDP
working group, co-chaired by Microsoft and 3Com, focuses on formal specifications, in the
form of profiles, for mapping selected service discovery protocols to Bluetooth
environments. The initial focus for these profiles is on the Universal Plug and Play and
Salutation technologies (the latter being an outgrowth of [Miller99], which described a
Salutation mapping in informal terms), although other profiles for other technologies may
come later.

New Applications Working Groups

While each of the working groups noted in the preceding section will produce profiles or other
documentation to enable new applications of Bluetooth technology, they all have grown out of
work that was started during version 1.0 specification development. The working groups
discussed in this section, on the contrary, are truly new domains for Bluetooth wireless
communication. While these applications might have been discussed in passing in the original
SIG, there was no specific work done to enable them. Each deals with an application of Bluetooth
technology that is more than just an evolutionary extension of the version 1.0 usage models. The
working groups dealing with new applications are:

• Car Profile: Automotive manufacturers have expressed great interest in Bluetooth

technology for in-vehicle communication. Chaired by Nokia, the car profile working group
is investigating solutions for wireless communication within vehicles, including accessing
devices and services in a car using Bluetooth links (perhaps automotive information and
entertainment systems) and the use of personal devices like pagers, mobile phones and
mobile computers in automotive environments. There are many possibilities for the use of
Bluetooth wireless communication in vehicles. Consider scenarios such as automatically
configuring personalized settings in the automobile (ventilation, seat and mirror positions,
radio settings and so on) based upon personal identity carried on a Bluetooth device, or
retrieving e-mail through a cellular link between the car's Bluetooth network and a larger
network and then having that mail read, using voice technology, over the car's audio
system. Numerous other applications can be imagined, and the car profile working group
is chartered to specify many of these.
• Richer Audio/Video (AV): This working group, co-chaired by Philips® and Sony® (both
SIG associate members), addresses the use of Bluetooth links for exchanging audio
information beyond the simple voice-quality audio specified in version 1.0, as well as
motion video data. With multimedia capability on Bluetooth devices, new usage scenarios
for movies and video clips, music (with wireless headphones), video conferencing,
dictation and others could be enabled. The AV working group deals with the challenges of
handling this kind of data-intensive, time-critical information in Bluetooth environments.
• Local Positioning: Co-chaired by Microsoft and Nokia, this working group investigates
the use of Bluetooth wireless technology as a means to determine the geographic location
of a device (and often, then, the user of that device). Through judicious use of the
properties of the short-range RF interface, Bluetooth technology can be employed to
determine local (in-building) position information. The local positioning working group is
chartered to provide a scheme to gather such information and make it available in a
standard way to applications. The applications could then use this information for a

180
 multitude of purposes that might include selection of the "best" device to connect to in a
local area, based upon proximity, locating a lost device, and so on.

Creating Additional Profiles

The foregoing are some of the working groups initially chartered by the SIG in 2000. Over time,
new working groups may develop more new extensions and profiles for Bluetooth applications.
The SIG's new organization promotes participation by a wider group of contributors and enables
the formation of new working groups when sufficient industry interest exists for a given topic.
The SIG has developed a formal process for the creation of working groups and profiles. As it
does for the products discussed below, tremendous opportunity exists for innovation resulting in
new applications and profiles.

Bluetooth Products
This section discusses the product landscape for Bluetooth technology. We do not cite specific
products or companies;[4] rather, we describe general product classes. We survey, in general
terms, the first Bluetooth products to reach the market in 2000 and predict the kinds of products
expected to appear over time.
[4]
The official Bluetooth SIG web site, http://www.bluetooth.com, includes a section that links to currently available products.

Silicon and Developers Kits

The basis of the specification is the radio and baseband; so, too, are these components the
fundamental elements of products. Manufacturers building end-user products need to start with a
chip set that includes the RF componentry and digital subsystems for the baseband firmware and
its associated memory. Original equipment manufacturers (OEMs) have a choice among several
suppliers of Bluetooth hardware. In 2000, at least seven vendors were supplying Bluetooth radio
modules to the marketplace.

Most silicon manufacturers also can supply complete developers kits to accompany the radio
module hardware. Developers kits typically include a circuit board with multiple interfaces to a
host, along with protocol stack software that executes on the host. These developers kits allow
product manufacturers to create their own products, both hardware and software, and to test and
debug those products using the kits' accessible features. These kits typically allow for frequent
and easily made changes to the product under development, so that the development process is
expedited. Often a large portion of the product development process can be completed using the
developers kits and other development tools, without having to create a final product image until
late in the cycle.

In addition to general development systems, a specific class of developers tools for Bluetooth
wireless technology also emerged in 2000: protocol analyzers. These are tools that can capture
the air-interface traffic over Bluetooth links and present this information to the developer in an
easy-to-comprehend fashion. These wireless protocol analyzers are analogous to their wired
counterparts but do not require a physical connection to the products being tested, since they
just need to intercept RF traffic. They tend to be passive receivers which capture the packets in a
piconet and transfer this data to a host for processing. The processing might include separating
packets from each of the various layers in the stack and displaying that data in human-readable
form on the host. Protocol analyzers can be especially helpful in Bluetooth environments because
the actual bit streams transferred over the air-interface can be quite complex.[5]

181
 [5]
Consider all of the operations that might occur on the data before it is transmitted over the air-interface: packetization, FEC,
whitening, encryption and other transformations could make the over-the-air data bear little resemblance to the logical PDUs
generated by upper layers of the stack.

Since silicon, hardware, firmware and developers kits enable the production of end-user products,
these were the first Bluetooth products available. Numerous such hardware and development
platforms became available beginning in mid-2000.

Legacy Product Enablers

One way to quickly introduce Bluetooth technology to the marketplace is to produce "add-on"
components that attach to existing products to enable them for Bluetooth wireless
communication. Examples of such products include PC cards (also known as PCMCIA cards) for
notebook computers and similar devices and hardware "plug-ins" (sometimes informally called
"dongles"; we use the two terms interchangeably) that attach to a standard interface such as a
serial or USB port.

The first PC cards with associated protocol stack software and drivers for popular PC platforms
were announced in 2000, with some being demonstrated at developers conferences. These
Bluetooth PC cards work similarly to other PC cards; the card is installed in the computer, along
with its associated software, and the system is presented with a new interface (in this case, one
for Bluetooth wireless communication). A primary advantage of PC cards here is in adding
capability for Bluetooth wireless communication to existing machines in a straightforward
manner. Without the purchase of a new computer, a new feature becomes available. One
disadvantage is that the Bluetooth technology is not seamlessly integrated into the system, as it
would be if included in the base manufactured unit. Thus performance may not be optimal, due to
considerations such as antenna placement (which is necessarily on the PC card itself, or perhaps
elsewhere via a cable connection; in either of these cases, fragility is one concern). In addition,
PC card slots on mobile computers typically are limited to one or two, so a Bluetooth PC card
occupies a slot that might otherwise be used for other features.

Interface add-ons provide a similar way to enable existing devices with Bluetooth wireless
communication. These devices typically plug into an existing standard interface, such as an RS-
232 serial port or a USB port. As with PC cards, a dongle with the appropriate protocol stack and
driver software can enable the existing interface to support Bluetooth wireless communication.
From the system's point of view, the traffic is directed over the existing port just as it would be in
a cabled environment, but the interface add-on then receives and transmits that data over the
Bluetooth air-interface. The advantages and disadvantages of dongles are similar to those of PC
cards: they can enable immediate use of the Bluetooth technology on existing devices, but they
might exhibit nonoptimal performance and fragility while taking up one of the system's interface
ports.[6] Interface add-ons can be constructed for many types of devices, not just computers, thus
(at least theoretically) enabling any device that exports a standard interface to make use of
Bluetooth wireless communication. Handheld computers, digital cameras, printers, scanners and
other devices are all candidates for add-on Bluetooth solutions. However, packaging dongles for
use on small handheld devices might in some cases make the resulting device significantly larger
and less convenient to use. Dongles for use with equipment that typically is stationary, such as
printers, scanners and similar devices, though, is potentially quite valuable.
[6]
For a USB interface, this latter consideration is minimized through USB's "multi-drop" device attachment scheme.

Because PC cards and interface add-ons can enable legacy devices to immediately utilize
Bluetooth technology, these devices were some of the first end-user products to appear in 2000.
The use of standard interfaces, like serial and USB ports, combined with the freedom from
extensive electromechanical design and packaging as is required for integrated solutions, makes
the production of these legacy device enabling products relatively straightforward.

182
Computers and Mobile Phones
Given the composition of the original SIG's promoter members, who have significant business
interests in mobile phones and personal computers (both desktop and mobile), it is not surprising
that these devices were among the first end-user products to have Bluetooth technology
integrated into them. All of the version 1.0 cable-replacement usage models involve a phone, a
computing platform, or both.

Among the first products to be announced and demonstrated were Bluetooth mobile phones and
headsets. Most major mobile phone manufacturers indicated that they will ship handsets (and in
many cases, also headsets) with Bluetooth technology in 2000. The popularity of mobile
telephones results in very high volume manufacturing (in the hundreds of millions of units) of
these devices; hence mobile phones are a significant influence on Bluetooth module proliferation.
If a significant portion of mobile phones include Bluetooth technology, then hardware costs can
decrease as manufacturing volumes increase. Achieving lower-cost Bluetooth modules then
enables their incorporation into other cost-sensitive devices such as consumer electronics
(discussed below).

Computers are a key device segment for Bluetooth technology. Mobile computers, especially,
have a high affinity for Bluetooth wireless communication and are included in several of the
version 1.0 profiles. A number of major mobile computer manufacturers planned to incorporate
Bluetooth technology in their products in 2000. Furthermore, through the use of PC cards
(described above), the large installed base of mobile PCs can be enabled with Bluetooth
technology in the short term, in addition to integrated solutions that may be offered by computer
manufacturers. Moreover, Bluetooth wireless communication is not just for PCs; prototype
solutions for several handheld computers were demonstrated at developers conferences in 2000,
so these devices are also expected to incorporate Bluetooth technology.

Other Products
The initial marketplace for Bluetooth wireless communication is populated by mobile telephones
and computers and associated accessories and add-on components for these devices. This is not
surprising, given the composition of the SIG's promoter group. But the complete SIG membership
also includes manufacturers and software developers from many industries.

Given the SIG's post-version 1.0 work on printing, still image and automotive solutions, we
expect to see Bluetooth technology incorporated in printers, digital cameras and automobiles in
the foreseeable future. Leading manufacturers in each of these industries are actively
participating in the SIG, and there is momentum to produce equipment with Bluetooth wireless
communication capability.

As the technology's costs continue to decrease over time, many consumer electronic devices may
incorporate Bluetooth wireless communication. Again, with leading industry players being
involved in the SIG, Bluetooth devices including televisions, stereos and other audiovisual devices
are expected to appear in the marketplace. Chapter 3 discussed what the SIG calls "the ultimate
headset," which can be used with computers and mobile telephones. As other audio devices
incorporate Bluetooth technology, such a headset might be used with portable CD players,
automobiles, stereos and other such devices, perhaps enabling an "ultimate ultimate headset."
Other products in which Bluetooth technology could be used include universal remote controls,
household appliances and even toys. Bluetooth technology certainly has the potential to be widely
deployed in enterprises, homes and public venues. Successful introduction of the first devices can
help to enable positive perception, user experience and value for users of many types of devices.
We believe that Bluetooth wireless communication is well positioned to make inroads in many
different devices and marketplaces.

183
Bluetooth Products
This section discusses the product landscape for Bluetooth technology. We do not cite specific
products or companies;[4] rather, we describe general product classes. We survey, in general
terms, the first Bluetooth products to reach the market in 2000 and predict the kinds of products
expected to appear over time.
[4]
The official Bluetooth SIG web site, http://www.bluetooth.com, includes a section that links to currently available products.

Silicon and Developers Kits

The basis of the specification is the radio and baseband; so, too, are these components the
fundamental elements of products. Manufacturers building end-user products need to start with a
chip set that includes the RF componentry and digital subsystems for the baseband firmware and
its associated memory. Original equipment manufacturers (OEMs) have a choice among several
suppliers of Bluetooth hardware. In 2000, at least seven vendors were supplying Bluetooth radio
modules to the marketplace.

Most silicon manufacturers also can supply complete developers kits to accompany the radio
module hardware. Developers kits typically include a circuit board with multiple interfaces to a
host, along with protocol stack software that executes on the host. These developers kits allow
product manufacturers to create their own products, both hardware and software, and to test and
debug those products using the kits' accessible features. These kits typically allow for frequent
and easily made changes to the product under development, so that the development process is
expedited. Often a large portion of the product development process can be completed using the
developers kits and other development tools, without having to create a final product image until
late in the cycle.

In addition to general development systems, a specific class of developers tools for Bluetooth
wireless technology also emerged in 2000: protocol analyzers. These are tools that can capture
the air-interface traffic over Bluetooth links and present this information to the developer in an
easy-to-comprehend fashion. These wireless protocol analyzers are analogous to their wired
counterparts but do not require a physical connection to the products being tested, since they
just need to intercept RF traffic. They tend to be passive receivers which capture the packets in a
piconet and transfer this data to a host for processing. The processing might include separating
packets from each of the various layers in the stack and displaying that data in human-readable
form on the host. Protocol analyzers can be especially helpful in Bluetooth environments because
the actual bit streams transferred over the air-interface can be quite complex.[5]
[5]
Consider all of the operations that might occur on the data before it is transmitted over the air-interface: packetization, FEC,
whitening, encryption and other transformations could make the over-the-air data bear little resemblance to the logical PDUs
generated by upper layers of the stack.

Since silicon, hardware, firmware and developers kits enable the production of end-user products,
these were the first Bluetooth products available. Numerous such hardware and development
platforms became available beginning in mid-2000.

Legacy Product Enablers

One way to quickly introduce Bluetooth technology to the marketplace is to produce "add-on"
components that attach to existing products to enable them for Bluetooth wireless
communication. Examples of such products include PC cards (also known as PCMCIA cards) for
notebook computers and similar devices and hardware "plug-ins" (sometimes informally called

184
"dongles"; we use the two terms interchangeably) that attach to a standard interface such as a
serial or USB port.

The first PC cards with associated protocol stack software and drivers for popular PC platforms
were announced in 2000, with some being demonstrated at developers conferences. These
Bluetooth PC cards work similarly to other PC cards; the card is installed in the computer, along
with its associated software, and the system is presented with a new interface (in this case, one
for Bluetooth wireless communication). A primary advantage of PC cards here is in adding
capability for Bluetooth wireless communication to existing machines in a straightforward
manner. Without the purchase of a new computer, a new feature becomes available. One
disadvantage is that the Bluetooth technology is not seamlessly integrated into the system, as it
would be if included in the base manufactured unit. Thus performance may not be optimal, due to
considerations such as antenna placement (which is necessarily on the PC card itself, or perhaps
elsewhere via a cable connection; in either of these cases, fragility is one concern). In addition,
PC card slots on mobile computers typically are limited to one or two, so a Bluetooth PC card
occupies a slot that might otherwise be used for other features.

Interface add-ons provide a similar way to enable existing devices with Bluetooth wireless
communication. These devices typically plug into an existing standard interface, such as an RS-
232 serial port or a USB port. As with PC cards, a dongle with the appropriate protocol stack and
driver software can enable the existing interface to support Bluetooth wireless communication.
From the system's point of view, the traffic is directed over the existing port just as it would be in
a cabled environment, but the interface add-on then receives and transmits that data over the
Bluetooth air-interface. The advantages and disadvantages of dongles are similar to those of PC
cards: they can enable immediate use of the Bluetooth technology on existing devices, but they
might exhibit nonoptimal performance and fragility while taking up one of the system's interface
ports.[6] Interface add-ons can be constructed for many types of devices, not just computers, thus
(at least theoretically) enabling any device that exports a standard interface to make use of
Bluetooth wireless communication. Handheld computers, digital cameras, printers, scanners and
other devices are all candidates for add-on Bluetooth solutions. However, packaging dongles for
use on small handheld devices might in some cases make the resulting device significantly larger
and less convenient to use. Dongles for use with equipment that typically is stationary, such as
printers, scanners and similar devices, though, is potentially quite valuable.
[6]
For a USB interface, this latter consideration is minimized through USB's "multi-drop" device attachment scheme.

Because PC cards and interface add-ons can enable legacy devices to immediately utilize
Bluetooth technology, these devices were some of the first end-user products to appear in 2000.
The use of standard interfaces, like serial and USB ports, combined with the freedom from
extensive electromechanical design and packaging as is required for integrated solutions, makes
the production of these legacy device enabling products relatively straightforward.

Computers and Mobile Phones

Given the composition of the original SIG's promoter members, who have significant business
interests in mobile phones and personal computers (both desktop and mobile), it is not surprising
that these devices were among the first end-user products to have Bluetooth technology
integrated into them. All of the version 1.0 cable-replacement usage models involve a phone, a
computing platform, or both.

Among the first products to be announced and demonstrated were Bluetooth mobile phones and
headsets. Most major mobile phone manufacturers indicated that they will ship handsets (and in
many cases, also headsets) with Bluetooth technology in 2000. The popularity of mobile
telephones results in very high volume manufacturing (in the hundreds of millions of units) of
these devices; hence mobile phones are a significant influence on Bluetooth module proliferation.

185
If a significant portion of mobile phones include Bluetooth technology, then hardware costs can
decrease as manufacturing volumes increase. Achieving lower-cost Bluetooth modules then
enables their incorporation into other cost-sensitive devices such as consumer electronics
(discussed below).

Computers are a key device segment for Bluetooth technology. Mobile computers, especially,
have a high affinity for Bluetooth wireless communication and are included in several of the
version 1.0 profiles. A number of major mobile computer manufacturers planned to incorporate
Bluetooth technology in their products in 2000. Furthermore, through the use of PC cards
(described above), the large installed base of mobile PCs can be enabled with Bluetooth
technology in the short term, in addition to integrated solutions that may be offered by computer
manufacturers. Moreover, Bluetooth wireless communication is not just for PCs; prototype
solutions for several handheld computers were demonstrated at developers conferences in 2000,
so these devices are also expected to incorporate Bluetooth technology.

Other Products
The initial marketplace for Bluetooth wireless communication is populated by mobile telephones
and computers and associated accessories and add-on components for these devices. This is not
surprising, given the composition of the SIG's promoter group. But the complete SIG membership
also includes manufacturers and software developers from many industries.

Given the SIG's post-version 1.0 work on printing, still image and automotive solutions, we
expect to see Bluetooth technology incorporated in printers, digital cameras and automobiles in
the foreseeable future. Leading manufacturers in each of these industries are actively
participating in the SIG, and there is momentum to produce equipment with Bluetooth wireless
communication capability.

As the technology's costs continue to decrease over time, many consumer electronic devices may
incorporate Bluetooth wireless communication. Again, with leading industry players being
involved in the SIG, Bluetooth devices including televisions, stereos and other audiovisual devices
are expected to appear in the marketplace. Chapter 3 discussed what the SIG calls "the ultimate
headset," which can be used with computers and mobile telephones. As other audio devices
incorporate Bluetooth technology, such a headset might be used with portable CD players,
automobiles, stereos and other such devices, perhaps enabling an "ultimate ultimate headset."
Other products in which Bluetooth technology could be used include universal remote controls,
household appliances and even toys. Bluetooth technology certainly has the potential to be widely
deployed in enterprises, homes and public venues. Successful introduction of the first devices can
help to enable positive perception, user experience and value for users of many types of devices.
We believe that Bluetooth wireless communication is well positioned to make inroads in many
different devices and marketplaces.

186
Chapter 17. Concluding Thoughts
In this book we have presented many facets of Bluetooth wireless communication. Part 1
introduced the technology, discussed the origins of the SIG and presented an overview of
wireless communication concepts leading to the development of the Bluetooth technology and
specification. Parts 2 and 3 delved into the specification, aiming to make it more accessible and
easily understood. Our choice of the title for this book is based upon our endeavor to reveal the
specification's background and development in addition to interpreting its contents. Part 2
covered the core specification, or volume 1, focusing on the protocol stack. Part 3 addressed
volume 2 of the specification, the profiles.

We conclude with some forward-looking remarks about the directions in which Bluetooth wireless
communication is likely to proceed in the future.

Interoperability
The motivation for producing profiles—over 400 pages in version 1.0, with more profiles
continuing to be developed—is to foster interoperability. Indeed, the formation of the SIG itself
was aimed at developing an open specification with backing from leaders in the computing and
telecommunications industries. The SIG is well aware that many promising new technologies
have not gained market traction for various reasons, and the SIG believes, as we do, that
interoperability is a key attribute that can enable the initial and continued success of Bluetooth
technology.

Besides expending tremendous effort to develop the profiles, the SIG also sponsors other
activities geared toward fostering interoperability. Events called unplugfests are held from time to
time. During unplugfests, vendors can test their Bluetooth solutions with those of others to
determine how well the different implementations interoperate. Unplugfests are informal
gatherings where developers, under nondisclosure agreements and within a spirit of cooperation,
can judge the precision and completeness of their protocol stack implementations. These events
have been popular and have allowed developers to discuss and test their implementations with
each other, helping to resolve conflicts and work toward producing robust, interoperable
solutions.

The compliance testing and logo programs provide more formal methods for testing and
certifying Bluetooth implementations. The certification program is not covered in detail in this
book; a detailed presentation could perhaps be a book unto itself. The compliance testing and
logo programs were still maturing in 2000 and are likely to continue to evolve over time. In
general, these programs revolve around a process for formal testing of a Bluetooth
implementation by a SIG-certified test body. The types of tests vary with the type of
implementation being tested. Once a product is certified through the testing process, the product
can sport the Bluetooth logo (depicted in Chapter 1) as an indication of its compliance with the
specification. The SIG publishes rules for the use of the logo; these rules and other authoritative
information about compliance testing can be found at the official Bluetooth web site,
http://www.bluetooth.com.

187
Opportunities
Innovation is the lifeblood of the computing and communications industries. The Bluetooth
technology fosters innovation and presents many opportunities to many people. First and
foremost is the value it can provide to end users in the form of convenience and new applications
of the technology. As the previous chapter pointed out, product opportunities abound for
manufacturers and software developers. Like most new technologies, Bluetooth wireless
communication presents opportunities for education and consulting by those who choose to
become immersed in the technology. Indeed, this book and others on the topic are intended to
educate and widely disseminate information about this exciting new technology. This book has
not covered every facet of Bluetooth wireless communication—besides the new subjects which
will arise as the technology evolves, there is still room for investigating other topics in more
depth than we have done here. Testing and certification, WAP interoperability, software design
and development, silicon and antenna design and development and other subjects are all ripe for
further exploration.

With a solid and robust foundation, exceptional industry backing, a detailed specification,
tremendous momentum, and dedicated product developers worldwide, Bluetooth wireless
communication is poised to become a major influence in high-technology industries. Bluetooth
technology has made great strides since its inception, and we believe that King Harald would be
proud of his namesake.

Cited References
[BTSIG99] Bluetooth Special Interest Group, Specification of the Bluetooth System, version 1.0B,
volumes 1 and 2, available from http://www.bluetooth.com, December 1999.

[ETSI99] European Telecommunications Standards Institute (ETSI) SMG4, ETSI TS 101 369
V7.1.0 (1999-11) Technical Specification: Digital cellular telecommunications system (Phase 2+);
Terminal Equipment to Mobile Station (TE-MS) multiplexer protocol (GSM 07.10 version 7.1.0
Release 1998), available from http://www.etsi.org, 1998.

[FCC99] Federal Communications Commission, Code of Federal Regulations part 15, Title 47,
volume 1, available from http://www.fcc.gov, revised October 1, 1999.

[Graham99] Graham, Steve; Miller, Brent, and Rusnak, Joseph, IBM Corporation, Discovering
Devices and Services in Home Networks, http://www.ibm.com/pvc/tech/networking.shtml, June
1999.

[Haartsen00] Haartsen, J. C., "The Bluetooth Radio System," IEEE Personal Communications
(special issue on "Connectivity and Application Enablers for Ubiquitous Computing and
Communications"—C. Bisdikian, J. C. Haartsen, P. Kermani, eds.), vol. 7, no. 1, pp. 28–36,
February 2000.

[IAL99] Inventors Assistance League, Hedy Lamarr,

http://www.invention.org/culture/female/lamarr.html, 1999.

[IEEE99] Institute of Electrical and Electronics Engineers, Wireless Standards Package (802.11),
available from http://www.ieee.org, 1999.

[IETF92] Partridge, C., Internet Engineering Task Force Network Working Group, Request for
Comments: 1363, A Proposed Flow Specification, available from http://www.ietf.org, 1992.

188
[IETF96] Yergeau, F., Internet Engineering Task Force Network Working Group, Request for
Comments: 2044, UTF-8, a transformation format of Unicode and ISO 10646, available from
http://www.ietf.org, 1996.

[IMC96a] The Internet Mail Consortium, vCard—The Electronic Business Card Exchange Format,
Version 2.1, http://www.imc.org/pdi/, September 1996.

[IMC96b] The Internet Mail Consortium, vCalendar—The Electronic Calendaring and Scheduling
Exchange Format, Version 1.0, http://www.imc.org/pdi/, September 1996.

[IrDA99a] Infrared Data Association, IrDA Object Exchange Protocol (IrOBEX), Version 1.2,
http://www.irda.org/standards/pubs/IrOBEX12.pdf, April 1999.

[IrDA99b] Infrared Data Association, IrMC (Ir Mobile Communications) Specification, Version 1.1,
http://www.irda.org/standards/specifications.asp, February 1999.

[ISO96] International Organization for Standardization in ISO/IEC 11578:1996, Information

Technology—Open Systems Interconnection—Remote Procedure Call (RPC), available from
http://www.iso.ch/, 1996.

[ITU96] International Telecommunication Union, Recommendation T.4—Standardization of Group

3 facsimile terminals for document transmission, available from http://www.itu.org, July 1996.

[ITU98] International Telecommunication Union, Recommendation Q.931—ISDN user-network

interface layer 3 specification for basic call control, available from http://www.itu.org, May 1998.

[ITU99] International Telecommunication Union Recommendation V.250—Serial asynchronous

automatic dialing and control, available from http://www.itu.org, May 1999.

[Mettälä99] Mettälä, Riku, Nokia Mobile Phones, Bluetooth Protocol Architecture, Version 1.0,
http://www.bluetooth.com/developer/download/download.asp?doc=172, August 25, 1999.

[Miller99] Miller, Brent and Pascoe, Robert, IBM Corporation, Mapping Salutation Architecture
APIs to Bluetooth Service Discovery Layer, Version 1.0,
http://www.bluetooth.com/developer/download/download.asp?doc=174, July 1, 1999.

[Muller99] Muller, Thomas, Nokia Mobile Phones, Bluetooth Security Architecture, Version 1.0,
http://www.bluetooth.com/developer/download/download.asp?doc=174, July 15, 1999.

[Suvak99] Suvak, David, Extended Systems, Inc., IrDA and Bluetooth: A Complementary
Comparison, http://www.extendedsystems.com/prodinfo/white/bt%5Fvs%5Fir.html, 1999.

189