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.
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 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.
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 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.
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.
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 registry so that the protocol specification itself need not be modified when instances of new services are developed.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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:
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.
Read Chapters 6 though 10 of this book as a group in preparation for studying the core specification.
Thoroughly read all of volume 1 of the specification (or at least all of those sections that pertain to the implementation at hand).
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]
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:
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.
Read the remainder of Part 2 of this book as a prelude to a study of volume 1 of the specification.
Thoroughly read and understand the core specification, referring back to the corresponding chapters of this book where necessary.
Read all of Part 3 of this book in preparation for scrutinizing volume 2 of the specification.
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.
[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.
[3] After all, it helps to create a market for books such as this one.
[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.