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 (MHz)

Frequency channels (MHz) k = 0, 1, …, m -1

LGB [1] (MHz)

UGB[2] (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 (GFSK)

BT product[3] 0.5; modulation index: 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-hopping rate

1,600 hops per second, typical residence time: 625 µsec per hop

3,200 hops per second for inquiries and pages

residence time: 312.5 µsec per hop

Transmit power

Class 3: 0 dBm (1 mW) a typical Bluetooth radio; optional 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 sensitivity

a Bluetooth receiver must attain a raw bit error rate (BER)of 0.1% with an input signal level of –70 dBm or lower

the –70 dBm sensitivity level shall be attained for any input signal generated by any compliant Bluetooth transmitter

[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 state

Frequency-hop module Access code

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; address: paged device's

paged device's device access code (DAC)

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 name

Size Comments

AM_ADDR 3 bits

active member address assigned to an active slave when devices exchange paging information, such as during the paging of a device

TYPE 4 bits

defines 16 BB_PDU/payload types

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 bits

header error check (HEC) generated by the generator polynomial G HEC(x) = x 8 + x 7 + x 5 + x 2 + 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 name

Size Comments

L_CH (logical channel)

2 bits 'b00': not defined

64

Table 6.5. The ACL packet format.

Field name

Size Comments

'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) bits

length of ACL payload in octets (excludes header and 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 bytes

ACL packet payload spanning 1 to 5 slots

CRC 2 bytes

the cyclic redundancy check protects the payload and is generated by the CRC-CCITT generator polynomial G

(x) = x + x + x +1CRC16 12 5

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 bits

used for building the device access code (DAC) for paging the device sending this packet

LAP 24 bits

the lower address part of the BD_ADDR of the device sending this packet

Reserved 2 bits

set to 'b00'

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 bits

the upper address part of the BD_ADDR of the device sending this packet

NAP 16 bits

the non-significant address part of the BD_ADDR of the device sending this packet

CoD 24 bits

class of device field containing information regarding the device sending this packet

AM_ADDR 3 bits

for inquiry responses, it is set to 'b000'; for a master response 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 bits

the current time (updated with each retransmission of the packet) of the Bluetooth clock of the device sending this packet

Page scan mode 3 bits

the default page scan mode of the device; one mandatory page scan 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 'b0': identifies link manager transaction initiated by the master

1 bit

'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 bytes

the LMP_PDU fits in DM1 BB_PDU; if the 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'–'0x003F'

range of reserved CIDs

'0x0040'–'0xFFFF'

range of CIDs allocated on demand by a device to its local endpoints for either 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 – PSM_field_size) bytes

CL L2CAP_PDU payload data; the maximum possible size is 65,535 bytes minus the size of the PSM field, which 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 bytes

CO L2CAP_PDU payload data; the maximum possible size is 65,535 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 bytes

signaling command payload data (collection of signaling commands)

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 bytes

identifies the destination payload processing entity for the L2CAP_PDUs 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 MTU 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.

CO

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 bytes

the payload of a command HCI_PDU is structured as a 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 bytes

the payload of an event HCI_PDU is structured as a 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 bytes

data to be carried over the ACL or SCO baseband link 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 bytes

lower address part used for generating the inquiry 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 bytes

identifies the remote device with which to establish a connection

Packet_Type 2 bytes

indicates which BB_PDU types can be used by the link manager for the ACL link

Page_Scan_Repetition_Mode 1 byte

indicates the page scan repetition mode, that is, how frequently the remote device enters the page scan mode, last reported by the remote device

Page_Scan_Mode 1 byte

indicates the page scan mode supported by the device

Clock_Offset 2 bytes

indicates the difference between the slave and master clocks, as calculated in the last communication between them

Allow_Role_Switch 1 byte

indicates whether this (the paging) 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 bytes

identifies the connection (actually the ACL 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 bytes

indicates the maximum negotiable hold interval (0.625 msec – 40.9 sec)

Hold_Mode_Min_Interval 2 bytes

indicates the minimum negotiable hold 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 bytes

determines the interval between successive starts of inquiry scans11.25 msec – 2.56 sec (typically, 1.28 sec)

Inquiry_Scan_Window 2 bytes

determines the duration of a single 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 establishment

Line of sight Penetrates obstacles

Transmission pattern Relatively narrow conical

Relatively spherical

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 cost

< $1.00 $5.00 (estimated, approximately 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