Audio and Telephony Control Operation
`
`193
`
`call and adjust volume) was envisioned. As the telephony profiles
`(including tl1ose noted above along with dial-up networking and fax)
`were furth er developed , it became evident that a richer set of telephony
`control functions was desirable and a working group was forr11ed to
`define tl1ese capabi lities fo1· the protocol stack.
`With tl1e initial recognit ion of a need for minimal audio control
`functions early in the SIG' s history, it was at first supposed that these
`simple operation s would be accomplished via AT commands using the
`RFCOMM
`serial port abstraction (recall that RFCOMM was fairly
`well defined even at this early stage). Thu s was born the TCS-AT speci-
`fication. Thi s specification was intended to describe how standard AT
`comm and s could be mapped ove1· the Bluetooth protocol stack and to
`define any new AT comm ands required for Bluetooth wireless commu-
`nication. TCS-AT was designed to support legacy applications that send
`and 1·eceive AT comma nds ove1· 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 progre ssed, it became apparent
`that there was very little need for any new AT command s specific to
`Bluetooth envi1·onments (only two new AT command responses were
`identified as being useful enough to propos e specific definitions for
`Bluetooth TCS -AT). Thus the TCS-AT specification became a short ref-
`erence that described how to use AT commands in the Bluetooth proto -
`col stack, and its definition was absorbed into the profiles that use AT
`protocol s (namely headset, fax and dial-up networking ).
`In the meantim e a binary , packet-based telephony control proto-
`col was also being defined within the Bluetooth protocol stack. Called
`TCS -Binary (or TCS-BIN ), it was adapt ed &·om an existing ITU -T spec-
`ification, Q931 [ITU98] . As in other cases, the SIG's adoption of exist-
`ing standard s provid ed benefits for the protocol stack, in this case
`including the capability fo1· robust telephony control operations
`in a
`standardized mann er. 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
`provid ed all of the functions necessary for all of the telephony-based
`profile s. Finally it was also observed that the TCS-AT specification did
`not p1·ovide significant new functions specific to Bluetooth environ-
`ments 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 specifi-
`cation, although the functions were not removed; only the name was.
`
`. • • •
`
`•
`
`IPR2020-00202
`Apple Inc. EX1057 Page 215
`
`

`

`194
`
`Cl1apter IO t AUDIO AND TELEPHONY CONTROL
`
`Thus the version 1.0 specification does not mention TCS -AT, 1 although
`several applications
`in fact do use RFCO MM as a serial tran spo1·t for
`AT commands
`in cases where a mod em se1·vice support s such a config-
`uration. Indeed, the headset, fax and dial-up networking p1-ofiles use AT
`command
`telephony control. With onJy TCS-BIN being explicitly men -
`tioned in the specification , all furthe1- referenc es to TCS he1-ein imply
`TCS -BIN.
`The TCS Protocol Examined
`In addition to what the specification calls TCS supplem ental services
`(including caller identification info1mation and dual tone multi-fi·equenc y
`[DTMF] tone gene1·ation), TCS defines three major fw1ctional 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 11ot reprodu ced here. Instead we
`highlight some of the important featur es 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 ma chin e, perforrnin g
`the operations necessary to progress a call from one state to the next,
`and tracking the resulting state . When making calls, these operation s
`might include such things as setting up the call, including dialing infor -
`mation; 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 estab -
`lishment and te1·1nination. Much of the TCS chapter of the specification
`is devoted to a full explanation of these states and their transition opera-
`tions; the appendix
`to the TCS chapter of the specification details these
`states and transitions in comprehensive state diagrams.
`
`I. Actually there is one "lefto,1er" reference to TCS-AT in the Bluetooth Assigned Number s
`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.
`
`IPR2020-00202
`Apple Inc. EX1057 Page 216
`
`

`

`I I
`I
`
`Audio and Telephony Control Operation
`
`195
`
`. Th e telephon y control functions can operate not only in a point-to-
`po1nt netwo1·k topology but also in a point-to-multipoint configuration.
`Th e multipoint environment is relevant, as pointed out in the specifica-
`tion, for incoming calls when numerou s phones all need to receive the
`incoming ring signal and control information. In this case, TCS uses
`multip oint 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.
`Unlike RFCOMM , in which a single instance of the protocol layer
`is multipl exe d, the specification indicates that multiple instances of TCS
`may be executed at the same time to handle multiple calls (recall that
`Bluetoot h wireless communi cation per1r1its up to three voice channels
`simultan eously over the baseband ). Multiple instances of TCS simply
`use multipl e L2CAP chann els.
`TCS Group Management
`Group mana gement 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 interme1nber access).
`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 WU G is just a group of devices that all support TCS. The specifi-
`cation makes special provisions for security within the WUG by allowing
`
`2. The need to transmit ring signals simultaneously to multiple telephone handsets ,vas a primary
`motivation for including group abstraction and management ar1d connectionless channels in
`L2CAP. The se features could certainly be utilized in other future scenarios , but in ,,ersion 1.0
`they are used only in the context of TCS-BIN.
`
`IPR2020-00202
`Apple Inc. EX1057 Page 217
`
`

`

`,I ... ,,
`• •• l
`f; " ....
`2.
`
`196
`
`Chapter 10
`
`AUDIO AND TELEPHONY CONTROL
`
`the WUG n1aster to distiibut e keys used specifically for communicat io ns
`within the WU G, including communication with the master· and separate
`communication
`(using a different key) with other WUG member s as is
`done with the fast inter-member access described belo w.
`One device in a WUG can request to use the teleph ony services of
`anothe1· device in the WU G; TCS calls this an access 1·ights request. A
`handset might 1·equest the use of the telephon y services of a base station
`to make a call, or an access rights reqt1est might be used to transfer a
`call from one TCS device (such as a hand set or headset) to anot her.
`Configuration distributi on is the TCS -BIN meth od for managing
`the membership of the ,vua. Again using the concept of a WUG mas-
`ter that maintains all of the inform ation about the WUG , TCS -BI N
`defines a protocol for the WU G master to send upd ated \t\TU G configu -
`ration inf or111ation to each WU G memb er, each time that configuration
`information changes. For example , this might be used to inform all
`WUG member s that a new member has joined (or that some member
`has left) the WUG. Among other application s, this featur e could be
`used to support the three-in-one phone profile by advising WUG mem -
`bers (perhaps stationary handset s and base stations in a home ) that a
`new member (say, a mobile phone brought into the home ) has joined
`the WUG. Thu s the mobile phone 's pre sence is known and it can con-
`tact the base station (to act as a cordless pl1one) or it cou ld directl y con-
`tact other phones in the WUG (to act as an interco m).
`Fast inter1nember access is a facility by which any two WU G
`members can quickly establish a connection with each other. This fea-
`ture makes use of the fact that two member s alread y belong to a WU G
`and have already established connections with a common WU G mas-
`ter. Thus all WUG members are alread y in a single picon et, all using
`the same hopping sequence established by the WU G master's clock.
`Furthe1111ore, via the configuration distribution noted abov e, all WU G
`members can know about all other WU G members. Becaus e all of this
`info1·1nation is already known, it can be leveraged to establish a connec -
`tion with another WUG member more quickly than such a connection
`could be established from scratch. With fast intermember
`access, a
`WU G member uses the configuration information to detern1ine another
`member with which it wishes to establish contact. It forwards this infor -
`mation
`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 infor1nation 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
`
`IPR2020-00202
`Apple Inc. EX1057 Page 218
`
`

`

`Audio and Telephony Control Operation
`
`197
`
`to establish a connection with the target member by paging
`information
`that member (wl1ich is 110w in page scan state to accept such pages), the
`result being a new piconet , consisting initially of the two devices. This
`sche1ne takes advantage of the other features that are already in place
`for a WU G to enable quick direct connection between any two devices
`in that WU G to support , for exampl e, the "walkie-talkie" function of the
`thr ee-in-one phon e pr-ofile.
`Connectionless
`TCS
`Finall y, TC S-BIN also provide s a way ·for devices to exchange call sig-
`nalin g information without actually placing a call or having a TCS call
`conne ction established. Thi s is called connectionless TCS. Connection-
`less TC S pr ovide s a sort of ''sideband '' in which devices within a WUG
`can send messages to each other without having to have a TCS connec-
`tion established between
`them. What sort of messages might these
`devices want to send ? The specification defines only a single message
`format for connectionle ss TCS called CL Info. CL_Info messages in tum
`can contain only tw·o types of information: audio control, used to spec-
`ify inform ation about microphone gain and speaker volume settings,
`and compan y information, which is the common TCS way to allow any
`information not specified in a standardized TCS for111at to be inter-
`changed. Thu s it can be seen that connectionless TCS could be used to
`manaa-e the audio settino·s of all members of a WUG as vvell as to com-
`b
`b
`municate product -specific features, defined by the manufacturer, among
`all of the devices from that manufacturer
`in the WUG. Such use of con·
`.
`.
`I d
`ed telephony features
`nect1onles s TCS might allow, for examp e, a vane
`to be used between a base station and a handset from the same mafnu-
`h d t from another manu ac-
`f acturer that might not be available to an se s
`1 h
`.
`CS
`tions the basic te ep ony
`~pe_ra e WUG with all hand-
`through standard T
`turer (although
`functions would be expected to wo1·k within th
`sets).
`Bluetooth Audio Development
`JG A dio has
`within the S
`. u.
`.
`,..,,01unication since ialts
`There was no audio working group per se
`· eless C0 1 •~
`d
`nt
`th
`. d into the fun arne
`been an inherent part of Bluetoo wir
`· ntegrate
`.
`· ed 0ver
`inception and thus l1as always been 1
`. thei· audio) 1s carrt
`d
`A d. (
`· ce 01 o
`k
`·e alrea Y
`. scO lin 'S wei
`· bl. ly
`design of the protocol stack. u 10 voi
`basic
`pu 1c
`.
`Th
`tly after 1t was
`SCO links at the baseband
`layer.
`ese h
`JG' h'
`ry s or
`s 1sto
`defined ea1·ly in
`the S
`,
`
`IPR2020-00202
`Apple Inc. EX1057 Page 219
`
`

`

`198
`
`Cl1apter 10 :: AUDIO AND TELEPHONY CONTROL
`
`announced (the addition of mul tiple SCO conne ction s to support multi-
`ple voice channel s was introdu ced in n1id-1998).
`This evolution of Bluetooth audio mi1To1·s its situation within the
`stack: it is 11ot a distinct prot oco l layer bu t rather a fundam ental part of
`the technology. Audio essentially is integr ated into the baseba11d. Owin g
`to a few specific con siderations for audio in the pr otoco l stack we discuss
`it as a separat e topic. And as 11oted above, due to audio s affinity with
`telephon y, for pragm atic 1·easons 'A'e discuss it in this chapt e1·.
`Bluetooth Audio Examined
`A quick scan of the specification searching for audio informatio n is likely
`to locate only Append ix V, ''Bluetooth Audio .'' Tl1is app endix contain s
`info1·mation interesting mostly to audj o and sound enginee 1·s, includin g
`such thing s as recomm ended sound pressur·e, loudne ss and audi o levels.
`Although impor tant, it is not the fund amental infor·mation about how to
`deal with Bluetooth wireless audio traffic. That inform ation, as might be
`expected from preceding discussions, is actually found in the ''Bluet ooth
`Audio' ' section of the Baseband chap ter 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 continuou s for periods of time and is thus isochr o-
`nous, or time limited. Th e tra nsmission rate for Bluetoot h audio traffic
`is set at 64 Kbps , chosen to be sufficient for normal voice con versations.
`While the communication of other audi o media (say, mu sic) ove r Blue-
`tooth 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 scheme s are specified for Bluetooth audi o.
`The first is pulse coded modulation (PCM ) with eith er of two types of
`logarithmic compression (called A-law and µ-law) appli ed. PCM audi o
`with these compression
`types is well known and widel y used for gen eral
`audio, including things like short sound clips. The second audio encod -
`ing scheme is continuous variable slope delta (CVSD ) modulation . Th e
`characteristics of typical voice conversations, which hav e a more pre -
`dictable continuity
`than general audio (music, for example ), make a
`delta-slope prediction more efficient. CVSD generally is also more tol-
`erant of communication errors. Thus CVSD, in general, is a more effec -
`tive 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.
`
`IPR2020-00202
`Apple Inc. EX1057 Page 220
`
`

`

`Audio and Telephony Control Operation
`
`199
`
`The specification says little else about audio as a topic unto itself.
`Th e remai11der of what needs to be specified (and what implementers
`and other s may wish to und erstand ) 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
`dat a traffic. Thi s information is found in the baseband chapter of the
`specification and in Chapter 6 of this book.
`On e final note about audio: it should be clear that Bluetooth audio
`as described here and in the specification is digital isochronous ( effec-
`tively strea ming) audio traffic that operates directly over the air-interface
`using the baseband protocols. Of c.ourse audio inforrnation can also be
`in a digital packet-based format3 using local recording and
`encoded
`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 f1·om what we refer to here as Bluetooth audio. 4
`Audio and Telephony Control Usage
`Several families of telephon y applications are possible. TCS-B IN is
`intended
`to supp ort applications that realize the Bluetooth
`telephony-
`bas ed profil es: cordl ess telephony and intercom. These are the only two
`profile s technicall y classified as telephon y profiles, based upon their
`usage of TCS -BIN . Such applications are expected to use TCS-BIN
`dire ctly, as depicted in Figure 10.1.
`Other sorts of applications also might be considered
`in some
`respect s 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 seiial port profile family;
`this is because the telephony facets of these applications tend to use ~e
`programming model of AT commands over a serial port (RFCO~M 1~
`the Bluetooth wireless communication case), as described earlier m this
`chapter. Although not TCS-BIN based, we also consider these applic~-
`tions in general to be telephony applications, and they are depicted 10
`Figure 10.1 as such (that figure shows telephony applications using both
`TCS-BIN and AT commands over RFCOMM).
`
`3. Such as WAV and man y other fundamentally similar representation s.
`· fashion For
`th
`·
`·
`l
`4,. For one thing , it is not truly isochronous, at east not Ln a streanung, over -
`e-a1r
`·
`another most encoding schemes for such digital packet audio are designed so that n1
`~ ~ typthes
`tim-1z1ng e
`I
`d
`d
`th
`'
`rr
`.
`of audio (music, sound clips and so on} cru1 be e11ective y ren ere , rather
`an op
`audio content for one primary use such as voice.
`
`IPR2020-00202
`Apple Inc. EX1057 Page 221
`
`

`

`200
`
`Chapter 10 r AUDIO AND TELEPHONY CONTROL
`
`telepl1ony con-
`Legacy applications are likely to use AT command
`trol, since this is the typical prog1·amming mod el in the vvorld of serial
`cables. New applications developed specificall y to make use of Blue-
`tooth wireless links, though , ar·e encourag·ed via the specification to
`make use of the TCS-BIN protocol, 1vvhich provide s a r~obu st set of tele-
`phony control functions based upon an existing standard that has been
`adapted for the BI uetooth stack.
`Telephony and audio , particularl y voice audio, play in1portant
`roles in the Bluetooth stack. With their associat ed appli cations (which
`may involve both computing and telecommunica tions devices in some
`profiles and usage models ), they pr·ovide a distinguishin g· feature of
`Bluetooth wireless communication .
`
`' I ,,
`' ·' •
`
`IPR2020-00202
`Apple Inc. EX1057 Page 222
`
`

`

`THE BLUETOOTH
`PROFILES
`EXAMINED
`
`f-·-... · -
`
`· l aving examined the Bluetooth co1·e specification in Part 2,
`we continu e in Pa1·t 3 with an exa·mination of volume 2 of
`ter 11 with an ove1"View of the profiles and their interrela-
`i:.........--.-.------..---1
`tion ship s, includin g the rationale for our own grouping of the profiles in
`this book. Th e remaining chapters then explore each of the published
`profile s in logicall y related groups. Chapter 12 discusses the fundamental
`generic access and service discove1-y application profiles. Chapter 13
`explores
`the profiles that deal with telephony functions (cordless tele-
`phony , intercom and headset ), while Chapter 14 describes the family of
`serial port related profiles (basic serial port , object push , file transfer and
`synchronization). Finally Chapter 15 examines the profiles 1·elated to net-
`working, 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 inforn1ation more acces-
`sible and understandable. Drawing on our experience in the Bluetooth
`SIG, we attempt here to expose the motivation and rationale fo1· key
`elements of volume 2 of the Bluetooth specification.
`
`201
`
`IPR2020-00202
`Apple Inc. EX1057 Page 223
`
`

`

`
`
`|PR2020-00202
`
`Apple Inc. EX1057 Page 224
`
`IPR2020-00202
`Apple Inc. EX1057 Page 224
`
`

`

`V olume 2 of the specification consists of the profiles. These ai·e
`intend ed to pr·omote interoperability among many implementations of
`the pr·otocol stack that is specified in volume l. In this chapter we dis-
`cuss the gene1·al natur e of the profiles- the rationale for generating
`them, their history and evolution and the interrelationships among
`them. Eacl1 of the version 1.0 profiles is then examined in more detail in
`subsequ ent chapt e1·s.
`
`The Version 1 .0 Profiles
`P1·ofiles spring from usage cases. Chapte1· 3 discussed the usage scenar-
`ios that were part of the development of the version 1.0 specification
`(altl1ough not all usage cases resulted in a corresponding profile for ver-
`sion 1.0). Many of the profiles can be grouped togethe1· based upon the
`shared elements of thei1· usage scena1ios; 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 st1·aightforward manner to usage scenario
`relationships , although
`in other cases the technical relationship
`(for
`example, of ·fax to headset ) is not so obvious. Furthermore,
`the ve1·sion
`1.0 specification contains additional p1·ofiles that do not directly
`embody usage cases. These include the generic access p1·ofile, the se1·-
`vice discovery application profile, the gene1ic object exchange profile
`and the serial port profile. Each of these profiles can be considered a
`transport profile which defines a co1nmon basis of shared characteristics
`
`203
`
`IPR2020-00202
`Apple Inc. EX1057 Page 225
`
`

`

`204
`
`Chapter 11 , THE BLUETOOTH PROFILES
`
`,.vl1ich othe1· application p1·ofiles can be built ( or, in object-oriented
`upon
`terminology,
`these p1·ofiles a1·e classes f1·om whicl1 oth er profiles, or sub -
`classes , inl1eri t).
`Figure 11. l depicts the ve1·sion 1. 0 p1·ofile fan1ilies based up on their
`tech11ical relation ships . A simjlar figure app ears i11 mu ltiple places in
`volume 2 of the specification . Th at figu1·e depicts these relationships in a
`''nested container '' sort of repr esent atio n, wl1ile Figu1-e 11.l uses an
`object hierarch y rep1·esentation , but both diagr·ams convey
`the same
`info1·mation . The abbrevi ation s in par enthe ses in th e figu1·e intro duce
`the shorthand nomenclatur e tha t is used in the remaini11g cha pters of
`Part .3 to name
`the profil es. Th ese abbr eviations are use d for con ve-
`nience;
`in some case s (bu t not all) tl1ey are consisten t vvith sim ilar
`abbreviations
`for tl1e profile s that ai·e used in tl1e specification.
`
`·' •• I ,, • • l
`fJ .. .,; z
`
`r'J
`
`Service
`Discovery
`App. (SOAP)
`"
`Generic
`Object
`Exchange
`,(GOJ
`,
`
`I
`
`I
`Fi le
`Transfer
`(FP)
`
`I
`Object
`Push
`(OPP)
`
`Generic
`Access
`(GAP)
`
`Serial
`Port
`(SPP)
`
`Telephony
`(TCS-BIN)
`
`Cordless '
`Telephony
`(CTP)
`
`'
`
`Intercom
`(lntP)
`
`,;/ -
`
`•
`Synchronization ·
`(SP)
`
`Dial Up
`Networking ,
`(DUNP) j
`
`•
`
`Fax
`(FaxP)
`
`Headset
`(HSP)
`
`LAN
`Access
`(LAP)
`
`Figure 11.1
`The Bluetooth version 1.0 profile families, based upon protocol stack relationships, in class hierarchy
`representation .
`
`to the rela-
`This chapter describes each of the profiles according
`tionship 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 multi -
`ple ways of viewing several of the profiles and thus there are multiple
`ways to group
`the profiles. This chapter presents one such grouping,
`
`IPR2020-00202
`Apple Inc. EX1057 Page 226
`
`

`

`I
`
`•
`
`t
`
`The Version 1 .0 Profiles
`
`205
`
`that of the techni cal elements shar ed among profiles (which is consistent
`with the version 1.0 specification, although it does not propose any
`ove1·t gr oupin.g at all other than including a different repr esentatio n of
`tl1e figu1·e sl1own above). Figure 11.2 depicts the logical, service -based
`groupin g that we use in discussing these profiles in subsequent chapters .
`On e exa n1ple of these mt1ltiple viewpoints is that of the head set profile.
`As depicted in Figur e 11.1 in the profile hierarchy , headset is a deriva-
`tive of the se1·ial port pro·file. Howe ver, from a functiona l or services
`point of viev., the headset p1·ofile could be considered to be part of the
`teleph ony profile gToup , as shown in Figure 11.2, and thus we include it
`in Ch apter 13 along with cordless telephon y and intercom . Anot her
`exampl e is tl1at of the fax profile, which from a technical perspective is
`also a serial port profile derivative. Ou1· treatment of the fax profile in
`this book, though, is alongside that of the dial-up networki ng and LAN
`access p1·ofiles, as part of what we consider a ''networking '' category, 1 a
`g1·oup which lhe specification does not addre ss.
`
`Generic
`
`Generic
`Access
`(GAP}
`
`Service
`Discovery
`App. (SOAP)
`
`Serial
`Port
`(SPP)
`--~
`·-
`
`Fi le
`Transfer
`(FP)
`
`Serial
`
`Generic
`Object
`' •
`Exchange
`(GOEP) ·
`_L
`
`'j
`
`Object
`Push
`(OPP)
`
`Synchronization•
`
`(SP) ---~
`
`LAN
`Access
`(LAP)
`
`'
`,
`~P
`I
`
`Telephony
`
`Cordless
`Telephony
`(CTP)
`
`)
`
`Headset
`(HSP)
`
`Intercom
`(I ntP)
`
`,
`Dial Up
`Networking :
`(DUNP) J
`
`Networking
`
`}
`Fax
`(FaxP) /)
`• 1
`~
`-1i/7
`
`Figure 11.2
`The Bluetooth version 1 .0 profiles, based upon logical service-based groupings.
`
`1. Whi le it 01ay not be obviotis t1ow a fax profile fits ,vithi11 a net,vorking category, cons~der that
`· 1·ke dial up net"\vorking and LAN access, uses a Bluetooth deV1ce as a
`th
`e ax usage scenano , 1
`th'
`f
`-
`•
`•
`"gate,vay" to a ,vide area nenvork for data communication . Chapter 15 further elaborates
`1s
`point.
`
`IPR2020-00202
`Apple Inc. EX1057 Page 227
`
`

`

`206
`
`Chapter 11 • THE BLUETOOTH PROFILES
`
`This discussion and the figures a1·e intend ed only to po int out that
`there are multiple ways in which to categ·orize the ve1·sio11 1.0 pr ofiles.
`The choice of which metl1od to use is probabl y best made depe11ding
`upo.n the purpose and circumstance s sur1·ound ing the need to gi·oup the
`profiles in the fi1·st place, and most distinctions a1·e not likely to be dras-
`tically different. Howeve1·, because the numb er of p1·ofiles is expecte d to
`gi·ow over time, with the SIG already planning to add quite a few nev\'
`ones (as discussed in Chapter 16), ilie act of grot1ping the profiles
`becomes n1ore advantageous , and the different ,iVays of doing· so should
`not be confused .
`Generic Profiles: This group is compo sed of the generic access
`profile, which is ilie root of all profiles, and the service discove1-y
`application profile , which provides a framework for mapping from
`the application layer to the SDP layer of the sta.ck.
`Telephony Profiles: In the object hierarchy vievv these are ilie
`profiles that imply the use of TCS-BIN for teleph ony contro l func-
`tions. This group includ es the cordl ess teleph ony and intercom pr o-
`files (in Chapter 13 we consider ilie head set profile in the telephon y
`group also, although from the technical pe1·spective it is part of the
`serial port group ).
`Serial Port Profiles: All of the remaining profile s are par t of the
`serial port group. However , this group is furth er subdivided . Dir ect
`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 tum 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 ) identicall y
`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 remain -
`ing serial port profile family me.mbers-fax, LAN access and dial-up
`networking-are
`treated as a networking family, which is examined
`in
`Chapter 15.
`
`IPR2020-00202
`Apple Inc. EX1057 Page 228
`
`

`

`The Version 1 .0 Profiles
`
`207
`
`Part 3 Chapter Organization
`In each of the remaining chapters of Part 3 we examine a group of pro-
`files as desc1·ibed 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 exa mination o·f 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 p1·ocess and future possibilities of the profiles based upon
`our par·ticipation in the SIG when tl1e p1·ofiles were being developed.
`
`IPR2020-00202
`Apple Inc. EX1057 Page 229
`
`

`

`•
`
`f· ,..
`'"""
`
`•• " ' ·' ,•
`
`
`
`|PR2020-00202
`
`Apple Inc. EX1057 Page 230
`
`IPR2020-00202
`Apple Inc. EX1057 Page 230
`
`

`

`O ur examination of the profiles begins with two that we call the generic
`profiles be cause they are fundamental
`to Bluetooth wireless communica -
`tion . The generic access profile, or GAP, is the basis for all other profiles. It
`describ es the fundamental
`operations necessary
`for two Bluetooth
`devic es 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
`de scribed in Chapters 6 and 7. The service discovery application profile, or
`SDAP, describe s fundamental operations necessary for service discov-
`link is
`ery , an operation often perfo1·1ned soon after a communication
`established. The SDAP maps directly to the service discovery protocol
`(SD P) 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 imple-
`ment
`telephony profiles, while a headset device is unlikely to imple-
`ment 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 co1Tesponding guidelines out-
`lined 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.
`
`'
`
`209
`
`IPR2020-00202
`Apple Inc. EX1057 Page 231
`
`

`

`, . ,,
`
`210
`
`Chapter 12 P THE GENERIC PROFILES
`
`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 p1-otocols involved in the most basic
`Bluetooth communication functions, while the DAP