-- ----
`
`-------
`
`The Automatic Synchronizer
`
`41
`
`The speaking laptop usage model is an example of extending the
`functions of one device by allowing it to ''bor·row'' tl1e capabilities of
`some otl1er· device. Speakerphone capability becomes available, using
`the speaker and micr·ophone of the notebook computer, even if the
`mobile phone does not have its own speakerphone capability . Exten-
`sions to the speaking lapt op scenario migl1t enable other- similar usage
`models wher·e exjsting auruo input and output could be t1sed to supple-
`ment 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 Blue-
`toot·h wirele ss communications.
`
`The Automatic Synchronizer
`is an example of using proximity netwo1·k-
`The automatic synchronizer
`ing to add value by making an existing task easier to do. Personal po1·ta-
`ble devices em pow er people
`to have quick and easy access
`to
`inf 01·mation they can use in tl1eir-daily lives. For that infor111ation to be
`most useful it need s to be kep t up to date, but this personal inf or 1r1ation
`ma11agement data might be dist1·ibuted across the many devices that a
`per son could use. For· examp le, new calenda1· entries or to-do list items
`migl1t be entered on any of a notebook computer, personal digital assis-
`tant 01-smart phone; or these ent1ies might be entered on a desktop
`computer and stored on a server· in a network. Synchroruzation
`is the
`proces s of merging
`the data from two differ·ent sou1·ces based upon
`some set of rules such that the resulting data sets are identical ( 01· at least
`reflect identical information ). A comn1on example
`is synchronizing a
`per·sonal digital assistant with a desktop or notebook computer·. Today
`tlus often is performed using special serial cables and software that may
`be unique to the device . Standard protocols and object for·111ats in the
`specification allow data on one device to be synch1·onized with data on
`any other· device , whether· they be PDAs, notebook computers, smart
`phones or even networ·ked data accessed th1·ough a data access point.
`The ''automatic '' part of this usage model is enabled by proximity
`networking. Today syncl11·onization is almost always a conscious effort-
`it involves connecting a ser·ial cable and pushing a button , 01· pointing
`two inf1·ared-capable devices at each othe1· and launching an applica -
`tion. With Bluetooth wireless co1nmunications
`it is possible for· two
`devices to automatically synch1·onize whenever they come within 1·a11ge
`of each other. For example, a personal digital assistant carried in a per-
`son's pocket could automatically synchr·onize witl1 tl1at per·son's desktop
`
`IPR2020-00202
`Apple Inc. EX1057 Page 63
`
`

`

`42
`
`Chapter 3 r, BLUETOOTH USAGE MODELS
`
`computer "''henever she \valked into her office. Clea1·ly it should be pos-
`sible to configure the devices as to whe11 and I1ow to automatica lly sy11-
`ch1·onize, and to ensure that devices synchr·onize on ly with otJ1er kno'vvn
`devices and data sources and not with just an)' randon1 device ; the spec-
`ification does offer mechanisn1s tl1at could be used to do tl1is. Figure 3.8
`shows examples of the automatic synchronizer ·. Th e figur e illustrate s
`how different device s in a pe1·sonal area netwo1·k (such as the mobil e
`telephone and PDA shown ) might automaticall y synchroni ze. Th e fig-
`ure also shows how one of those devices (he1·e, tl1e PDA in the bri ef-
`case) might aJso synch1·onize ,,vith a desktop computer when those
`devices come within rang·e of eacl1 other (in tl1is case, when the PD A s
`owner walks u1to her office).
`
`I
`
`•
`
`• • • • •••
`
`••• •••
`•• ••
`i
`•• •• •• ....
`•• . ........... u
`
`Figure 3.8
`The Bluetooth automatic synchronizer usage model.
`
`\
`
`·~
`
`•
`
`• -
`
`I
`
`\_ ,
`
`.-
`
`,
`
`--
`
`• E J
`
`In addition to the convenience afforded by automatic synchroniza -
`tion, Bluetooth wireless communication
`removes
`the requirem ent for
`cables. By specifying a standard protocol and object formats for syn-
`chronization
`(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 synchro-
`nization enables a person to use any convenient device to enter new
`appointments,
`to-do list items or other data .
`
`J
`
`•
`
`•
`
`a a •
`
`IPR2020-00202
`Apple Inc. EX1057 Page 64
`
`

`

`The Instant Postcard
`
`4 3
`
`The Instant Postcard
`The insta11t postcard is another usage model that was discussed early in
`tl1e development of the specification but is not formally part of the ver-
`sio11 1.0 profiles. This is 011e of tl1e few scenarios that involves a device
`othe1· than a mobile phone or comput ing platform, although
`it is
`expected that over ti1ne 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
`sto.red, catalogued , manipulated and distributed. As with the other ver-
`sion 1.0 usage models, Bluetooth wireless communication removes the
`need for a cable which in tu1·n presents new ways to use a device, as
`pointed out below. Figure 3.9 shows how the instant postcard might be
`realized.
`
`\ ,o
`
`Cellula\
`
`\
`
`\ \
`
`\
`
`Photo Image
`
`The Internet
`
`Figure 3.9
`The instant postcard.
`type pic-
`This scenario is useful not only for sending ''postcard''
`tu.res to friends and relatives but also for commercial applications, such
`as real estate (transferring photos o·f newly listed homes to a central
`
`IPR2020-00202
`Apple Inc. EX1057 Page 65
`
`

`

`44
`
`Chapter 3 & BLUETOOTH USAGE MODELS
`
`database) , law enforcement (transferring pl1otos of suspects or stolen
`vehicles, for example) and insurance (transferring ph otos of automobile
`damage resulting from accidents ). In addition to replacing cab les, Blue-
`tooth technology also could change the way a digital camera is used,
`since photos need not necessarily be transfe1·red to a comput er. 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
`inter111ediary. In addition, the transfer of photos from the camera to a
`database or librar y could be accomplished in more of a real -time fash-
`ion, since no cabling is required.
`
`Ad Hoc Networking
`This usage model could be considered to be an extension of the interac -
`tive conference (file transfer ) scena.rio. It is not specifica lly addr essed in
`the version 1.0 specification but it does provide an illustration of usage
`cases that could be enabled in the future. Ad hoc networ ks are network s
`that for 1n spontaneousl) '; Bluetooth
`\i\rireless communication
`is an
`enabling technology for these sorts of applicatio11s. The interactive con-
`ference usage model showed how objects such as electronic business
`cards or files could be exchanged in a conference room setting. When
`ad hoc nehvorks can be fo1111ed among the meeting participants, addi -
`tional applications become possible . Among
`these are collabor ative
`applications such as real-time viewing and group editing of presenta -
`tions and instant messaging among the meeting participants.
`Ad hoc nehvorks consisting of diverse types of devi ces present
`many new and exciting possibilities for usage scenarios. While more
`work is required
`to establish interoperable methods for general net -
`working, 4 Bluetooth wireless communication
`is positioned
`to be an
`enabling technology for ad hoc networking scenarios.
`
`Hidden Computing
`Hidden computing (sometimes called unconscious com·puting ) is on e of
`the most exciting future applications for Bluetooth technology. While
`in the version 1.0 specification, hidden comput -
`not directly addressed
`ing has been discussed at SIG events in the past and is an area ripe for
`4. For example, issues \Vith routing, name serving, address assignment and other topics all need to
`be addressed for effective ad hoc nel\vork.ing. Such issues are also relevant in forming Blue-
`tooth scattemets, ctiscussed in Chapter 6.
`
`IPR2020-00202
`Apple Inc. EX1057 Page 66
`
`

`

`Hidden Computing
`
`45
`
`futu1-e exploration. Tl1e fu11damental elements required for some forms
`of hidden computing al1·eady exist in the curre11t specification, although
`the SIG has not developed profiles that describe how the various hid-
`den computing applications might be accomplished
`in a standard and
`interoperable mann er.
`in which
`i·nvolves a class of applications
`Hidden
`computing
`devic es that a1·e not overtly being used by a person can still perforn1
`tasks on tl1at person 's behalf. We have already seen one example that
`could be considered a hidden computing application:
`the automatic
`synchroni zer·. In that usage model , a PDA ''hidden'' in a pocket or purse
`could synchronize with another device witl1out user inte1·vention. Sev-
`e1·al otl1er examples have been described
`in the context of Bluetooth
`wi1·eless communication. Among these a1·e:
`• A notebook computer
`''hidde11'' in a briefcase in a ''sleeping''
`mode could be configu1·ed to awake periodically, receive new e-
`mail and send information such as new e-mail alerts (and possi-
`bly a short clip of tl1e e-mail content ) to a mobile phone. The
`user might then decide to browse e-mail using the mobile phone
`01· p1·ocess e-mail on the notebook compute1·.
`• A mobile telephone
`''hidden'' in a pocket or purse could be used
`by an appropriately configt1red 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 synchroniza-
`tion 01· transmission and 1·eception of e-mail could be initiated, all
`without conscious user interaction with either device.
`In early stages of the development of the specification, such appli-
`cations were called
`''the briefcase
`trick.'' With proximity netwo1·king
`enabled by Bluetooth wireless communication, hidden computing appli -
`cations abound. Other future possibilities might include the t1se of a hid-
`den device that cont1·ols environmental
`settings (such as home climate
`and lighting, music, automobile drive1·'s seat and mirror adjustments and
`so on) based upon the personal preferences of the user, automatic cus-
`tomer discounts applied at points of sale based upon a device tucked
`identification and authenti-
`away in a pocket or suitcase, and automated
`cation when a pe1·son checks in with an airline 01· a hotel.
`These sorts of scena1·ios are almost limitless. While hidden com-
`puting applications may not be fully realized for some time, the Blue-
`tooth
`technology does offer a basis upon which indust1·y innovators
`could build them.
`
`IPR2020-00202
`Apple Inc. EX1057 Page 67
`
`

`

`I
`
`• I
`
`... ,. ...
`
`'
`
`I PR2020-00202
`
`Apple Inc. EX1057 Page 68
`
`IPR2020-00202
`Apple Inc. EX1057 Page 68
`
`

`

`Intro __ uction
`t e
`to
`Bluetooth
`Speci
`
`..... ication
`
`A 11y good technical specification should answer several questions of
`''what ?'' for its readers. Some topics that a specification ought to add1·ess
`are:
`
`• what is the product or tecl1nology?
`• what is it designed to do?
`• what is it composed of?
`• what standa1·ds a11d metrics must an implementer· meet?
`Question s of ''how ?'' typically are not addressed in a specification
`but rather are left to the judg1nent and ingenuity of tl1e implementers. A
`specification usually does not add1·ess exactly how an instance of the
`technology or pr·oduct is constructed using· hardware or software mod -
`ules or describe the p1·ecise metl1ods used to ensu1·e that standards and
`requirements ar·e met.
`The Bluetooth specification
`is no different f1·om others in this
`1·espect. Even in its g1·eat magnitude ( over 1,500 total pages in version
`I.OB) the specification still focuses p1·ima1·ily on what an implementer
`needs to know to create products that use Bluetooth technology. One
`reason fo1· 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 diver·se audience.
`The SIG deemed
`this approach necessary, given the many new con-
`cepts introduced with Bluetooth technology. However, the SIG adopted
`
`47
`
`IPR2020-00202
`Apple Inc. EX1057 Page 69
`
`

`

`48
`
`Chapter 4
`
`INTRODUCTION TO THE 8LUETOOTH SPECIFICATION
`
`existing protocols ,vhere feasible; large portions of the specification deal
`,,,ith adapting these protocols to Bluetootl1 environm ents.
`The SIG involved dozens, if not hundr eds of people who spent
`over a year developing the fi1·st 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
`con1plete to enab le in1plementation s to begin. While the initial pt1blica-
`tion ,vas unsurprisingl y imperfect (nun1e1·ous er1·ata l1a·ve been pub -
`lished) and arguabl y can never be
`truly complet e
`(since ne\.\'
`applications of the technolo gy v,,ill continue to evolve), this approac h to
`producing a comprehensive
`first version of the specification was appre -
`ciated by many Bluetooth adopter companies.
`This chapter exp lains the purp ose, scope and structur e of the pec-
`ification and the relation ships amon g its constituent par ts. Because the
`specification is so broad and voluminou s it seem s unlikel y tl1at all read-
`ers will read it from cover to cover ,vith equal interest in all of its
`diverse parts. Since the main bod y (Parts 2 and 3) of this bo ok deal s
`\.\rith the specification, its structure logically mirror s the specification s
`structure to a great extent. By explaining hovv the specification is orga-
`nized , this chapter is designed to direct reader s to,,vard the chapt ers of
`this book, and hence to,vard the chapter s of the specification that are
`likely to be of most interest and relevanc e based up on the tasks they
`wish to accomplish or the knowledg e they hop e to gain.
`
`Purpose of the Specification
`Like most
`technical specifications, the Bluetooth specification is a
`response
`to marketing requirements. As previou sly noted, the SIG 's
`Marketing working group originally generated a marketing requirements
`document (MRD ), which is internal to the SIG and include s objectives
`and usage models which were the genesis of the specification. A co1·e
`purpose of the specification is to define components that can be used to
`develop solutions that address these marketing requirement s.
`Among the objectives set forth in the MRD were those that now
`are key attributes of Bluetooth wireless commun ication s: an open speci -
`fication, 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,
`
`IPR2020-00202
`Apple Inc. EX1057 Page 70
`
`

`

`Scope
`
`Scope
`
`49
`
`tl1e objective of an open specification is realized with its public avail-
`ability and royalty -free license ; unlicensed global communications are
`achiev ed through the use of the 2.4 GHz spectrum; many of the radio's
`paramete1·s ( described in more detail in Chapter 6) are a result of design
`tradeoffs to specify a robu st radio while meeting the objective of low
`cost; and tl1e objectiv e of interoperability is directly addressed in the
`more than 400 pages of profiles ( volume 2 of the specification).
`Man y of the usage models and technical characteristics reviewed
`in Chapter 3 also wer·e 1·ecorded first as marketing requirements. Most
`of these scenario s are described in the MRD and many of these survive
`largely unch anged
`today , although
`they have been
`refined and
`expanded. Initial outlines for the interactive conference (file transfer ),
`synch1·onization, Internet brid ge, three-i11-one phone , ultimate headset
`and others all are included within the original MRD , although some of
`these scenarios originall y were known by different names.
`
`Th e SIG intention ally began the specification development by focusing
`first on cable replacement usage model s and a basic protocol frame-
`work to support them . Thi s philo soph y resulted in the specification ver-
`sion 1.0, which defines a protocol stack that enables many important
`p1·ofiles, but the SIG has not stopped there. There is interest in many
`new application s and profile s; these will continue to be developed by
`the SIG and are likely to be publi shed in future editions of the specifica-
`tion. Part 4 explore s these possibilities further. By sta1·ting with the sim-
`plest and most fundamental usage models, the SIG was able to bound
`the version 1.0 specificatiop scope .
`The specification does not simp ly describe some existing imple -
`mentation. Great care was taken during its development
`to ensure that
`anyone who has or can obtain sufficient skills and resoUI·ces should be
`able to implement
`the specification. Recall that the specification was
`developed by a multicompany special interest group with a sha1·ed and
`stated objective to produce a truly open specification. The elements of
`the specification were developed to meet the objectives for the technol-
`ogy 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 specifi-
`
`IPR2020-00202
`Apple Inc. EX1057 Page 71
`
`

`

`50
`
`Chapter 4 •
`
`INTRODUCTION TO THE BLUETOOTH SPECIFICATION
`
`cation. Hypoth eses in the draft specification could then be tested at one
`or n1ore companies via prototyping or some other means, with the
`results then fed back into the refinement proce ss.
`The man y independent
`implementations of Bluetoot h hardware
`and software by multitudes of vendors, man y of whon1 were not part of
`the SI G's promoter group seem to indicate that the SIG ha s performed
`v.rell in producing a sufficiently comp lete specificatio n. It is encouragin g
`that man y products with Bluetooth wireless communi cat ion are being
`produced on the basis of the vers ion 1.0 specification.
`In any work this large, of course, some errors and op portunit ies for
`misinterpre tation are likely to arise. Th e Bluetoot h pe cification
`is no
`exception. Follo\.\ring publication of the version 1.0 (or mor e prope rly
`l.OA) specification, numerou s comments from adopter
`and others "''ere
`received. Many of these comments dealt with porti on of the specifica -
`tion that were unclear or for which multiple interpr etatio n cou ld rea-
`sonably be construed.
`In addition minor errors that had slipped
`through even the diligent revie\v of the SIG memb ers vvere discove red .
`For each of these item s-and
`there were dozens if not hundreds - the
`responsible working group within the SIG considered
`the co mm ent
`and , if accepted , prepared an erratum document and correcte d the
`error or clarified the wording in a corre spondin g chan ge to the specifi-
`cation. The result was the publication in Decem ber 1999 of the spec ifi-
`cation version l.OB, which is what most people mean when they ref er to
`version 1.0 of the specification (and inde ed this is what is mean t by such
`this book ). Of course even as new ver sions of the
`references throughout
`specification are generated, document main tenance mu st continue and
`the SIG still deals with errata to the initial specification while deve lop -
`ing 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 proto col stac k
`but also includ~s descriptions of related items such as testing and co m -
`pliance; volume 2 is the profile specification. In this book these two vol-
`umes 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 por-
`
`IPR2020-00202
`Apple Inc. EX1057 Page 72
`
`

`

`The Specification's Structure
`
`51
`
`tion of the SI G'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 pre sented largely in a bottom-to-top
`organization. Th e specification begin s 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 afte1· all of the higher -level protocol sections (the HCI is a
`command
`interface rather than a p1·otocol per se and its use may differ
`dependin g upon an implementation's design; thus it is discussed sepa-
`rately in the specification ). Additional chapters that do not deal specifi-
`cally with p1·otocols include WAP interoperability,
`test mode,
`test
`control a11d compliance discussions. Finally the miscellaneous material
`is included in the appendices, although much of this material is impor -
`tant for many implementers and should not be overlooked . Among the
`topics covered in the appendices of volume 1 of the specification are
`in Chapter 10 of this book ) and Bluetooth
`audio
`(also discussed
`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 1·egistered. Included are the particular values assigned to key
`fields or structures that must be well known in several protocols. Exam-
`ples include
`inquiry access codes and bit definitions for fields that
`describe device and service classes, used when establishing connec-
`tions; channel and protocol values used in L2CAP; and several specific
`values defined for use with SD P. In this latter case these values repre-
`sent particular services and attributes associated with those services that
`are required to accomplish the usage models ( as described in the pro-
`files) 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 ser-
`vices will be available, it is difficult to pre-assign values for all services;
`
`IPR2020-00202
`Apple Inc. EX1057 Page 73
`
`

`

`52
`
`Chapter 4
`
`INTRODUCTION TO THE BLLJETOOTH SPECIFICATION
`
`thus the values are isolated i11 the assigi1ed nun1bers regist1-y so that t'he
`protocol specification itself need not be modified wl1en instan ces of new
`services are developed.
`Volume Two Structure
`The organization of the p1·ofiles in volume 2 of the specification is quit e
`straightfo1,vard . Each chapter
`is a single profile. Fo1· the most part,
`togeth er, althot1gh the seria l porl pr ofile
`related profiles ru:e grouped
`seems to be oddly inserted in the middl e of the teleph ony-ba sed pro -
`files. As in volume 1, the profile specification begins st1-aightaway ,,vith-
`out any introductory or background material to set tl1e stage. In Parl 3
`of this book ,.ve pro\ 1ide some context for the pro-file specification.
`Part 3 of this book mo stly follows the structw-e of volum e 2 of lhe
`specification , gi·ouping
`togethe1- tl1e GAP and SDAP profile s
`tele-
`phony-related
`profiles , serial port -related profil es and netwo rkin g-
`related profiles. Although
`these profiles are not formall y gTouped this
`\Vay in the specification, this approa ch is intended to aid und ers tand ing
`and is discussed further in Chapter 11.
`
`Relationships
`that there is som e couplin g
`it may not be evident
`initially
`While
`between
`the two volumes of the specification , ther e is in fact a corr e-
`spondence between many layers of the proto col stack and one or m ore
`profiles. Because the profiles are intended
`to infor1n the reader about
`how to apply the protocols defined in volum e 1 to realiz e an interopera -
`ble implementation
`of a particular usage case, the se profil es 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
`stac k
`that it requires, as well as ho"v to use and configure the appropriat e pro-
`tocol layers. Many profiles are somewhat attuned to certain protocol s.
`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 coup led with the SDP
`layer o·f 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 tran sfer
`and the serial port profile itself) and networking-based profiles (LAN
`1. The headset profile does not directly use TCS; see the discussion in Chapter 13.
`
`IPR2020-00202
`Apple Inc. EX1057 Page 74
`
`

`

`Guide to Understanding the Specification
`
`53
`
`the
`access, fax and dial-up networking ) l1ave some affinity with
`RFCOMM
`layer of the stack, with the serial port-based profiles also
`being tightly cot1pled to the IrDA interoperability protocol s.
`So while the1-e is not a direct mapping of the chapte1·s of volume 1
`of the specification to those of volume 2, the subject matter of corre-
`sponding parts of tl1ese two volumes does include 1·elated material.
`Th erefo1-e it is usually insufficient to read 01- write about just one portion
`of the specification in isolation. Thi s is why this book covers both vol-
`ume s of the specification in its main body; this is also why this book
`strives to explain the motivation for and relationships among the vari-
`ot1s part s of the specification. The following section suggests some
`method s tl1at might aid in understanding
`those portion s of the s.pecifica-
`tion that are of most inter-est; if using this book as a guide to the specifi-
`cation , these same method s may be used to determine the focus areas
`herein, since the structure of Parts 2 and 3 of the book largely mirr·ors
`that of version 1.0 of the specification.
`
`Guide to Understanding the Specification
`Th e specification version 1.0 does not include any introductory
`infor-
`mation about its purp ose, scope, structure or component relationships
`(aside from a table of contents ). Its readers will find a title page , some
`notic es and a mast er table of contents abruptly followed by the radio
`specification and remaining chapters. Readers will find no preface, no
`foreword and no organized background inforn1ation. This is not neces-
`sarily a bad thing; 3 it p1;marily results from the specification's technical
`nature and direct approach
`to its subject matter. This chapter
`is
`intended to suppl y some of the inforn1ation that is not ·found (or at least
`not explicitly called out) in the specification, thus making the specifica-
`tion more accessible and better p1·eparing its 1-eaders to get the most
`from it.
`While the most straightforward way to read the specification is to
`start with page I of volume I 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 reade1-s would have difficulty absorbing
`the tremendous
`detail contained in the mo1-e than 1,500 pages of the complete version
`2. We group the serial port profiles as listed here ; Chapter 11 furtl1er describes profile family
`group ing.
`•
`3. After all, it helps to create a market for books such as this 011e.
`
`IPR2020-00202
`Apple Inc. EX1057 Page 75
`
`

`

`54
`
`Chapter 4
`
`INTRODUCTION TO THE BLUE TOOTH SPECIFICATION
`
`1.0 specification . Furthermore, many people p1·obabl y do not ne ed to
`learn all of the details of every protocol and profile, and eve 11 those who
`do may find it helpful to digest these details in logical grouping s, one at
`a time. The specification is quite broad , covering eve1·ythin g from low-
`level radio details to application software considerations. Th e projected
`Bluetooth marketplace is expected to be just as broad offering oppo rtu-
`nities for man y specialized products and skills as well as for gene1·al-pur -
`pose ones. Thus , dependin g upon interest, it may be benef1cial 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 rem edy to the lack of introductory material in the speci -
`fication, the SIG has published several white papers in addi tion to the
`specification. One of those white paper s, Bluetooth Protocol Architecture
`[Mettala99], is a useful overview of the content s of the specification and
`we recommend
`it as supplemental reading. This pap er cove rs som e of
`the same topics as Chapters 5 and 11 of this book and ma y serve as a
`good companion to that material .
`Once introductory material (such as Part 1 and Chapter s 5 and 11
`of this book along with the cited white paper) is und erstoo d, man y rea d-
`ers may wish to branch out to particular sections of the specificatio n
`depending upon their interests and objectives. It is unr ealistic to devise
`a reading plan to fit every audience 's need, but this sectio.n suggests
`some general guidelines. It is hoped that most read ers will be able to
`use one or more of these general classifications to achie ve an und er-
`standing of Bluetooth wireless technology that is appropriat e for th eir
`own situation.
`For General Knowledge
`Many readers, perhaps
`including students, teachers, consu ltan ts and
`others who have general interest in the Bluetooth technology and who
`wish to understand
`that technology in the context of their prof ession ,
`may wish to read this book and the specification to gain general knowl -
`edge. 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 .
`
`•
`
`IPR2020-00202
`Apple Inc. EX1057 Page 76
`
`

`

`Guide to Understanding the Specification
`
`5 5
`
`1. Read Part 1 and Chapter 5 of this book and tl1e SIG protocol archi-
`tecture white pape1· (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 correspond-
`ing specification sections.
`3. After reading Chapter 11 as an introduction
`to the profiles, study
`each pr·ofile in volume 2 of the specification, using Chapters 12
`through 15 as an aid in understanding
`the related 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 bt1ild device components need to under -
`stand the