BLUETOOTH SPECIFICATION Version 1.0 8
`
`page 88 ef440
`
`Service Discovery Application Profiie
`
`8 LINK CONTROL
`
`8.1 CAPABILITY OVERVIEW
`
`The following tabie lists all features on the LC level
`
`Support in
`baseband
`
`Support In
`Locflev
`
`Support In
`Remflev
`
`O§OO§§OOOO§§§§§?...
`
`Procedure
`
`Inquiry
`
`Inquiry scan
`
`Paging
`
`Page scan
`
`Type R0
`
`Type R’!
`
`Type R2
`
`Packet types
`
`ID packet
`
`NULL packet
`
`POLL packet
`
`FHS packet
`
`DM1 packet
`
`D!-I1 packet
`
`DM3 packet
`
`DH3 packet
`
`DM5 packet
`
`DH5 packet
`
`AUX packet
`
`HV1 packet
`
`HV2 packet
`
`HV3 packet
`
`DV packet
`
`|nter—piconet capabilities
`
`Voice coder:
`
`.5
`
`2.
`
`3.
`
`4.
`
`A B C 5
`
`. A B C D E F G H
`
`9702573‘-
`
`.“*-'
`
`Tabie 8.1: LC features
`
`1 December 1999
`
`Link control
`
`AFFLT0294-398
`
`Samsung Ex. 1216 p. 1170
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`Service Discovery Application Profile
`
`Procedure
`
`Support in
`base-band
`
`page 89 of 440
`
`Bluetooth.
`
`Support in
`Remnev
`
`Comments:
`
`{C1}: This mandatory LC feature will be activated under the control of the SrvDscApp.
`
`{C2]: This mandatory LC feature is a settable device policy {outside the scope of this profile)
`that is activated whenever a device is to operate in a discoverable {public} mode.
`
`[C3] This mandatory LC feature is a settable device policy {outside the scope of this profile)
`that is activated whenever a device is to operate in a discoverable or connectable {private}
`mode.
`
`{X1}: These features are not used in this profile. but their use by other applications running
`simultaneously with this profile is not excluded.
`
`Table 8.1: LC features
`
`For the next four subsections, it is assumed that a LocDev is to perform service
`searches with originally unconnected RemDevs. It thus needs to inquire for
`and page (or only page) these RemDevs. None of the following four Subsec-
`tions apply whenever a LocDev performs service searches with RemDevs to
`which it is already connected.
`
`8.2 INQUIRY
`
`Whenever instructed by the SrvDscApp, the i_ocDev shall advise its baseband
`to enter the inquiry state. Entry into this state may or may not be immediate,
`however, depending on 008 requirements of any already existing and ongoing
`connections.
`
`The user of the Sn/DscApp shall be able to set the criteria for the duration of an
`inquiry. see stopRuie service primitive parameter in Section 4.2. Nevertheless.
`the actual residence time in the inquiry state must comply with the recommen-
`dation given in section 10.7.3 of Bluetooth Baseband Specification it}.
`
`When inquiry is invoked in a LocDev, the general inquiry procedure shall be
`used using a GIAC as described in Section 8.1 of Bluetooth GAP_profi|e:lj3}.
`
`Instead ofa GIAC. an appropriate DIAC can be used to narrow down the scope
`of the inquiry. Since the only defined DIAC (referred to as the LIAC) does not
`reflect any specific device or service categories, the use of DIACS is of limited
`(but non-zero) benefit in this profile. In particular, the profile does not exclude
`(but neither does it encourage) performing inquiries according to the limited
`inquiry procedure described in Section 53.2 of GAP_profi|e:i3§.The information
`contained in the Class of Device field in the FHS packet returned by the
`‘inquired devices’ can be used as a filter to limit the number of devices to page
`and connect to for subsequent SDP transactions.
`
`Link control
`
`1 December 1999
`
`AFFLT0294399
`
`Samsung Ex. 1216 p. 1171
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 8
`
`Service Discovery Application Profile
`
`8.3 INQUIRY SCAN
`
`page 90 of 440
`
`Bluetooth-
`
`Inquiry scans are device-dependent policies outside the scope of this profile.
`Devices that operate in a discoverable mode of operation, see Section 4.1 of
`GAP_profi|e:;’3}, could be discovered by inquiries sent by other devices.
`
`To be discovered by an inquiry resulting from a SrvDscApp action. a RemDev
`must enter inquiry scans using the GIAC: see general discoverable mode in
`Fsiectien e-‘V3.23 of GAP_profi|e:{fEt}. A DIAC can be used instead of a GIAC. As
`previously mentioned, the use of DIACS are of limited (but non-zero) benefit in
`this profile. In particular, performing inquiry scans according to the limited
`discoverable procedure described in Section 6.2 of GAP_profile:{3} is not
`excluded, but is not encouraged either.
`
`8.4 PAGING
`
`Whenever the SrvDscApp needs to connect to a specific RemDev for inquiring
`about its service records, the LocDev will advise its baseband to enter the page
`state. Entry into this state may or may not be immediate, however, depending
`on Q08 requirements of any already existing and ongoing connections.
`
`Depending on the paging class (R0, R1, or R2) indicated by a RemDev device,
`the LocDev shall page accordingly. The total residence time in the page state
`must comply with the recommendation given in section 10.6.3 of
`BT_BB_spec:§f’i}. For the pages, the 48«bit BD_ADDR of the RemDev must be
`used.
`
`8.5 PAGE SCAN
`
`Just like inquiry scans, page scans are device-dependent policies outside the
`scope of this profile. Devices that operate in a connectable mode of operation,
`see $ection 4.12.2 of GAP_profile:§:3}, could establish Bluetooth links with other
`devices from pages sent by these other devices. To establish a link with a
`RemDev, a LocDev must send a page that results from a SrvDscApp action
`using the RemDev's 48-bit BD_ADDR.
`
`8.6 ERROR BEHAVIOR
`
`Since most features on the LC level have to be activated by LMP procedures,
`errors will usually be caught at that layer. However, there are some LC proce-
`dures that are independent of the LMP layer, such as inquiry or paging. Misuse
`of such features is difficult or sometimes impossible to detect. There is no
`mechanism defined to detect or prevent such improper use.
`
`1 December 1999
`
`Link control
`
`AFFLT0294400
`
`Samsung Ex. 1216 p. 1172
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 91 of 440
`
`Service Discovery Appiicatiori Proiiie
`
`9 REFERENCES
`
`9.1 NORMATIVE REFERENCES
`
`[1] Baseband specification (see Volume 1. Part B)
`
`[2] Bluetooth Assigned Numbers (see Volume 1. Appendix VIII)
`
`[3] Generic Access Profile (see Volume 2, Part K1)
`
`[4]
`
`[5]
`
`Link Manager Protocol (see Volume 1, Part C)
`
`Logical Link Control and Adaptation Protocol Specification (see Volume 1.
`Part D)
`
`[6] Message Sequence Charts between H0st—Host Contro||eriLink
`Manager (see Volume 1, Appendix IX)
`
`[7]
`
`Service Discovery Protocol (see Volume 1. Part E)
`
`References
`
`1 December 1999
`
`AFFLT0294401
`
`Samsung Ex. 1216 p. 1173
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 8
`
`page 92 of440
`
`Service Discovery Appiicat.-‘on Profile
`
`10 DEFINITIONS
`
`Term
`
`Definition
`
`conscious
`
`known
`
`new (RemDev)
`
`private
`
`public
`
`(usually referred to) a process that requires the explicit intervention of
`a user to be accomplished
`
`(with respect to a specific device} opposite to unknown; a known
`devices is not necessarily a paired device
`
`{with regard to this profile) an additional remote device (Re-mDev} that
`is discovered during a Bluetooth inquiry, and that is not already
`connected to local device (LocDev)
`
`a mode of operation whereby a device can only be found via Bluetooth
`baseband pages; i.e. it only enters page scans
`
`a mode of operation whereby a device can be found via Bluetooth
`baseband inquiries; i.e. it enters into inquiry scans. A public device
`also enters into page scans (contrast this with private}
`
`unconscious
`
`opposite to conscious
`
`unknown
`
`(with respect to a specific device) any other device that a specific
`device has no record of
`
`1 December 1999
`
`Definitions
`
`AFFLT0294402
`
`Samsung Ex. 1216 p. 1174
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 93 of 440
`
`Service Discovery Appiication Profiie
`
`11 APPENDIX A (INFORMATIVE): SERVICE
`PRIMITIVES AND THE BLUETOOTH PDUS
`
`In this Annex, we relate the service primitives shown in section 4.2 with the var-
`ious Biuetooth PDUs which support these primitives. The table below only
`shows the actions taken at the higher involved Bluetooth layer. Thus. unless
`specifically stated, the low-level inquiries and pages needed to discover and
`connect to Bluetooth devices are not discussed in detail.
`
`service primitive
`
`(highest layer) Bluetooth PDUs involved
`
`For the subset of RemDev that satisfy the Remflevfieiaiion.
`this service primitive will cause the LocDev to send:
`an SDP Servicesearchfitequesr PDU and receives a
`corresponding response PDU. see section 4.5 in
`BT_sDP_5peC.[?E;
`an SDP_ServiceAt‘tributeRequesf PDU and receives a
`corresponding response PDU. see section 4.6 in
`BT_SDP_spec:[}’].
`The first transaction above identifies the SDP servers that
`
`contain pertinent service records, while the second transac-
`tion retrieves the desired information;
`
`Alternatively. the two transactions above are combined to
`one:
`
`LccDev sends an SDP_ServiceSearch/ltrr'ibuteRequest
`PDU and receives a corresponding response PDU, see
`section 4.7 in BT_SDP_spec:§?;i
`
`In either of the above cases, the corresponding SDP trans-
`action may last a number of request and response PDU
`exchanges, due to the LZCAP MTU limitation.
`
`If the ge(RemDevName parameter is set to ‘yes‘, then for
`each RemDev involved in the execution of this service primi-
`tive. the service primitive will cause a sequence of
`LMP_name_request{) LM level PDUs to be sent by the
`
`LocDev.' The corresponding RemDev responds with a
`LMP_name_response{) LM level PDU containing the
`requested user-friendly device name.
`
`same as above
`
`servicefirowse
`(LlST( RemDev)
`I-IS-ri R9mDe"R9iaH°” )
`Us-ri b’°"""3eGm“p}
`get.‘-'\’emDevName
`t
`F.’
`i
`5 Op U 9)
`
`servicesearch
`(LlST( RemDev}
`L|ST{ RemDevReiatr‘on )
`L|ST( searchPaitern.
`attributeust )
`getRemDevName
`s1opRuie)
`
`Tabie 11.1: Biuetooth PDUs reiated to the service primitives in Ejection 4.2
`
`Appendix A (Informative): Service primitives and the Bluetooth PDUs 1 December 1999
`
`AFFLT0294403
`
`Samsung Ex. 1216 p. 1175
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 8
`
`Service Discovery Application Profits
`
`page 94 of 440
`
`Bluetooth-
`
`service primitive
`
`{highest layer) Bluetooth PDUs involved
`
`en ume rate RemDev
`(L|ST( ciassOfDew’ce )
`stopRuie}
`
`tenninatePrimitive
`
`{prirnitivei-iandie
`ret‘urnResuits)
`
`This service primitive wiii cause a Bluetooth baseband
`
`inquiry process. The inquiry will ‘indiscriminately‘i' find
`devices residing in the vicinity of the LocDev. Prior to return»
`ing the results of this inquiry the LocDev may filter them
`Using the classOfDev':ce qualifier.
`
`This service primitive wiil cause the termination of any out-
`standing operation caused by the invocation of the service
`primitive identified by the primitiveHandie parameter. This
`may cause an L2CAP connection termination request PDU
`to be sent from the LocDev to the RemDev. and the subse-
`quent transmission of an L2CAP termination response PDU.
`It the LocDev is connecting to the RemDev only for the pur-
`poses of an SDP transaction, the baseband link will also be
`severed by the transmission of an LiviP_detach LM level
`PDU.
`
`Tabie 11.1: Biuetocfh PDUS reiated to the service primitives in S.r:.-ciicn 4.2
`
`*.
`
`If the information requested is already stored (cached) in the LocDev, this service
`primitive may not have to cause the described LM level PDU transaction.
`1'. The inquiries considered here use the GIAC. No CoD-specific DlACs have been
`defined. Nevertheless. the use of appropriate D|ACs whenever possible is not
`excluded and is not outside the scope of this profile.
`
`1 December 1999
`
`Appendix A (informative): Service primitives
`
`AFFLT0294404
`
`Samsung Ex. 1216 p. 1176
`
`

`
`"LESS TELEPHONY PROFILE
`
`This rofile fiefines the features and proce-
`
`required for interoperability
`dure; that a
`betw en diff rent units active in the
`‘3-infl phon _' use case. The scope of this pro-
`file igicludeggthe following layerslprotocolsi
`profiles: Bl _etooth Baseband, Link Manager
`
`Prgtocol, l.gCAP, Service Discovery Protocol,
`Te. ephongControl Protocol Specification
`§fi'CS-Bigsry) and the General Access Profile.
`5‘
`
`AFFLT0294405
`
`Samsung Ex. 1216 p. 1177
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 8
`
`page 96 of-440
`
`Cordless Telephony Profile
`
`1 December 1999
`
`AFFLT0294406
`
`Samsung Ex. 1216 p. 1178
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`Cordless Teiephony Profile
`
`CONTENTS
`
`page 97 of 440
`
`Bluetouth.
`
`imrcsziuctim ................................................................................ ......‘i%
`1.’!
`
`1653
`
`1.12
`
`1.3
`
`‘S08
`Prcfiia £’Jeper2de.=‘=Ci3s ............................................................. ..
`...'EG1
`‘E9?
`
`Symimis and
`1.3.‘!
`ReqL:iremen§. siatus syrnbczis ..................................... ..
`
`1.3.2
`€.C-3.3
`
`Signaiiingdiagramconventions.._................................
`Notation for timers and counters
`
`‘E02
`
`‘E02
`
`Prcsfiie ovewiew................
`
`.
`
`.
`
`. ..
`
`.
`
`....1fi}3
`
`2.1
`
`2.3
`
`2.4
`
`2.5
`
`2.6
`
`C0~nf:gL:r'ati0ns and mies
`
`User requirézments and sscamarios
`Profék-2 fuaxdazneaatais .............................................................. ..
`
`163
`
`‘E54
`
`105
`
`105
`
`Feature d£%f'sn§tEC}a“:$ ................................................................. _.
`
`106
`
`Canfomma race ......................................................................... ..
`
`‘E E3?’
`
`Appiicaiien iayer ............................................................................ ..1€}$
`
`T{.‘.$«3§N prccedureg ...................................................................... .. ‘Hi?
`4.?
`‘HG
`Hf}
`
`Connention E\.»1as*.agem<-ant ....................................................... ..
`4.1.1
`{Ionneciéng to 23
`
`4.1.2 Conneciing to sanothar
`
`C35! Comm)! proceaiures
`4.2.’!
`Sides .......................................................................... ..
`
`Caii mass ................................................................... ..
`
`4.2.4
`
`£2«‘varEa;2 sending
`
`4.2.5
`4.2.6
`
`Caii proceeding ......................................................... ..
`Gait corafirrrsatiorw ........................................................ ..
`
`4.2.?
`
`Gait
`
`4.2.8
`4.23:
`
`Non—$ai=.:acied user
`in--‘sand iones and annourcements.............................
`
`4.2.10 F-'a':Eure of C31!
`
`4.2.1‘! Cafl
`4.2.12 Caflinforrm-Itiorz
`
`Suppéamentary
`4.3.1
`§}TE‘JiF signaiiing ........................................................ ..
`
`4.3.2
`
`Caifirtg line identiiy
`
`4.3.3 Register recaii ........................................................... ..
`
`Gr'ou;:+ Marzagarnent rirocedures ............................................ ..
`
`1 December 1999
`
`"HG
`
`111
`TE‘!
`
`11'?
`
`'31?
`
`“M?
`
`‘H1
`
`‘H1
`
`‘H2
`
`112
`
`1'12
`
`112
`
`‘H2
`
`‘M3
`
`‘E13
`113
`
`113
`
`‘E13
`
`H4
`
`AFFLTD294407
`
`Samsung Ex. 1216 p. 1179
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 98 0f4-40
`
`Cordress Telephony Proffle
`
`"0
`
`4.4.1
`
`{3iJtaEnAoces5
`
`4.4.2
`
`Configuraimredistrimtion .......................................... "114
`
`Link toss cieieciian by Gk’
`4.4.2.‘i
`Periodic key aspdate
`Fast inter--member
`
`4.4.3
`4.4.4
`
`114
`T35
`115
`
`Conrxeciioraiesss §:r'c-cedures ................................................... .. ‘H5
`
`TCS—E~3EN Message overview .................................................. .. "E16
`irafcsrmation Eiierneni ova‘-.=.Wiew' .......................................
`...... .. 11?‘
`
`4,.7’.3
`
`Eiearercapabiéity ....................................................... "H8
`
`42.2
`
`flaiit-3:3 party
`
`‘$18
`
`Caiiing party
`47.3
`4.‘.?'.ai Cause ..................
`
`H8
`................................................... .119
`
`4.8
`
`Uni»: E033 .................................................................................. .. 119
`
`3es"vice Déecucwery prccedures ..................................................... "129
`
`LEQAF wocedures ......................................................................... H12‘?
`
`6.?
`
`93.2
`
`C:3nfEgLa:'ati0r:0;>ti0r:s ............................................................. ..‘§2‘i
`6.2.1
`fviaximum Trarssmissiun uni!
`$21
`
`F!z.:sshiime0umptéon .................................................. ..12'§
`
`6.2.3
`
`-Quaiity of Service ...................................................... .. 121
`
`L53? praceaiures averview ............................................................A22
`(.1 Master--sieve switrsh ............................................................... .123
`
`7.2
`
`E..ir1%<{:.‘-oéicy ........................
`
`................................................... ..123
`
`LC features ..................................................................................... "124
`
`8.1
`8.2
`
`1.“.qu§ry scan ......................................................
`inter-piconet cap:-abiiitisss
`
`.................. .. “£25
`125
`
`Genera? Access Pmffle intercperabisity Requirements................125
`59.1
`
`9.2
`9.3
`
`Se<;=..=rity aspects
`.......................... ..12":'
`.................
`icfiimnrade pmcedures ............
`9.3.1
`Bamiéiug ....
`.......................................................
`...... .42“?
`
`1 December 1999
`
`AFFLTD2944-OB
`
`Samsung Ex. 1216 p. 1180
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 99 of 440
`
`Cordless Telephony Profile
`
`$8
`
`Annex A {Enfsrmative}: Sigszaiiing flaws
`1%.‘? Ouigguing eximnai caii *.«\rEt§“:{.>ut post—«riiaiiir:g....,.........................‘f28
`
`30.2 Guétgoing externai ca?! witfs po:=.i~cJéa§iir:g ................................. ..‘i?‘.9
`
`‘$0.3
`
`inc:-ming extarnai caii, SETUP deiivereté an canne-ectioniess
`era:-3r~.ne§'13fJ
`
`10.4 Inca:-ming extarraai caii. E§ET'iJi3 cieiivereci an Conn-action--oriented
`c?:ar=,ne§‘s 30
`
`18.5 Caii Ciearing ........................................................................... .33‘?
`
`4.0.6 EJTMF signaiiing ..................................................................... J31
`
`1%.?
`
`E}“§”%':F signaiiing faéiure
`
`‘£{}.8 Access rights
`
`€{}.E~£= Cflrfiguratiian distribution
`
`E32
`
`‘:32
`
`13.18 Parindic key upxaiate ............................................................... ..‘i33
`105%‘? Fast ‘trite?-memt=e.r
`
`Timers and cesunaers
`
`Referencea
`
`List of
`
`List (ref Taitreies
`
`1 December 1999
`
`AFFLT0294409
`
`Samsung Ex. 1216 p. 1181
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 8
`
`Cordless Telephony Profile
`
`1
`
`INTRODUCTION
`
`1.1 SCOPE
`
`page 100 of440
`
`Bluetooth-
`
`The Cordless Telephony profile defines the protocols and procedures that shall
`be used by devices implementing the use case called '3-in-1 phone’.
`
`The ‘3-in-1 phone‘ is a solution for providing an extra mode of operation to cel-
`lular phones, using Bluetooth as a short-range bearer for accessing fixed net-
`work telephony services via a base station. However, the 3-in-1 phone use
`case can also be applied generally for wireless telephony in a residential or
`small office environment. for example for cordless-oniy telephony or cordless
`telephony services in a PC — hence the profile name ‘Cordless Telephony‘.
`
`This use case includes making calls via the base station, making direct inter-
`com calls between two terminals, and accessing supplementary services pro-
`vided by the external network.
`
`1.2 PROFILE DEPENDENCIES
`
`In fr’-"igua'e 1.1, the Bluetooth profile structure and the dependencies of the pro-
`files are depicted. A profile is dependent upon another profile if it re-uses parts
`of that profile, by implicitly or expiicitly referencing it. Dependency is illustrated
`in the figure. A profile has dependencies on the profile(s) in which it is con-
`tained — directly and indirectly. As indicated in the figure, the Cordless Tele-
`phony profile is dependent only upon the Generic access profile. The
`terminology, user interface and security aspects, modes and procedures as
`defined in the Generic access profile are applicable to this profile, unless
`explicitly stated otherwise.
`
`1 December 1999
`
`introduction
`
`AFFLT029441 0
`
`Samsung Ex. 1216 p. 1182
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 101 of 440
`
`Cordless Telephony Profile
`
`Bluetooth.
`
`_ Service Discovery
`" Profile
`
`ofiles
`
`lntercom Profile
`
`_
`
`.
`
`Figure 1.1: Bluetoolh Profiles
`
`1.3 SYMBOLS AND CONVENTIONS
`
`1.3.1 Requirement status symbols
`
`In this document, the following symbols are used:
`
`'M' for mandatory to support (used for capabilities that shall be used in the pro-
`file);
`
`'O‘ for optional to support (used for capabilities that can be used in the profile);
`
`'C' for conditional support (used for capabilities that shall be used in case a cer-
`tain other capability is supported);
`
`'X‘ for excluded (used for capabilities that may be supported by the unit, but
`which shall never be used in the profile);
`
`’NlA‘ for not applicable (in the given context it is impossible to use this
`capability).
`
`Some excluded capabilities are capabilities that, according to the relevant
`Bluetooth specification, are mandatory. These are features that may degrade
`operation of devices following this profile. Therefore, these features shall never
`be activated while a unit is operating as a unit within this profile.
`
`Introduction
`
`1 December 1999
`
`AFFLT029441 1
`
`Samsung Ex. 1216 p. 1183
`
`

`
`BLUETOOTH SPECEFICATION Version 1.0 8
`
`Cordless Telephony Profile
`
`1.3.2 Signalling diagram conventions
`
`page 102 of440
`
`Bluetooth-
`
`The following arrows are used in diagrams describing procedures:
`
`PROC1
`
`PROC2
`——~————————~—~———«—————«—m—p-
`
`PROC3
`~
`
`4
`
`(PROC4)
`
`(PROC5)
`
`MSG1
`
`MSG2
`
`A {
`
`MSG3)
`
`A (
`
`MSG!-l)
`
`A
`
`In the table above, the following cases are shown: PROC1 is a sub-procedure
`initiated by B. PROC2 is a sub-procedure initiated by A. PROC3 is a sub-
`procedure where the initiating side is undefined (may be both A and B).
`PROC4 indicates an optional sub-procedure initiated by A, and PROC5 indi-
`cates an optional sub-procedure initiated by B.
`
`MSG1 is a message sent from B to A. MSG2 is a message sent from A to B.
`MSG-3 indicates an optional message from A to B, and MSG4 indicates an
`optional message from B to A.
`
`1.3.3 Notation for timers and counters
`
`Timers and counters may be introduced specific to this ptofile. To distinguish
`them from timers (counters) used in the Bluetooth protocol specifications and
`other profiles. these timers (counters) are named in the following format: ‘TC-I-p_
`
`nnn‘ (‘NC1-pnnn').
`
`1 December 1999
`
`introduction
`
`AFFLT029441 2
`
`Samsung Ex. 1216 p. 1184
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 103 of 440
`
`Cordless Telephony Profile
`
`2 PROFILE OVERVIEW
`
`2.1 PROFILE STACK
`
`Bluetooth.
`
`e=a'gu:'e 2.1 below shows the protocols as used within this profile:
`
`Telephony Application
`
`Protocol
`Discrimination
`
`TCS Binary
`
`Speech
`synchronisation
`Control
`
`‘ Ba:-;eBand
`
`Figure 2. 1: Protocol model
`
`This profile will define the requirements for each of the layers in the model
`above for the Cordless Telephony profile.
`
`Profile overview
`
`1 December 1999
`
`AFFLT029441 3
`
`Samsung Ex. 1216 p. 1185
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 8
`
`page 104 of440
`
`Cordless Telephony Prof.-‘re
`
`Bluetooth-
`
`In the profile, the interfaces in .>”~‘ig=.ars 2.‘: above are used for the following
`purposes:
`
`A) The Call Control entity uses this interface to the speech synchronization
`control to connect and disconnect the internal speech paths.
`
`B)This interface is used by the GW to send and by the TL to receive
`broadcast TCS-Binary messages.
`
`C)This interface is used to deliver all TCS messages that are sent on a
`connection-oriented (point-to-point) LZCAP channel.
`
`D)This interface is used by the Call Control entity to control the Link Manager
`directly for the purpose of establishing and releasing SCO links.
`
`E) This interface is used by the Group Management to control Link Manager
`functions when initializing and for key handling purposes.
`
`F) This interface is not within the scope of this profile.
`
`G)This interface is used by the Group Management entity to control the LC!
`Baseband directly to enable inquiry, paging, inquiry scan and page scan.
`
`2.2 CONFIGURATIONS AND ROLES
`
`The following two roles are defined for this profile:
`
`Gateway (GW) — The GW acts as a terminal endpoint from the external net-
`work point of view and handles all interworking towards that network. The GW
`is the central point with respect to external calls, which means that it handles all
`call set-up requests torfrom the external network. Examples of devices that can
`act as a gateway include a PSTN home base station, an ISDN home base sta-
`tion, a GSM gateway, a satellite gateway and an H.323 gateway.
`
`With respect to this profile, the gateway may have the functionality to support
`multiple terminals being active at once, or be of a simple kind where oniy one
`terminal may be active. The simple gateway will not support multiple ringing
`terminals, multiple active calls or services involving more than one terminal
`simultaneously.
`
`Terminal (TL) — The TL is the wireless user terminal, which may for example
`be a cordless telephone, a dual-mode cellularfcordless phone or a PC. Note
`that the scope of this profile with respect to a dual-mode cellularicordless
`phone acting as TL is only the cordless mode.
`
`1 December 1999
`
`Profile overview
`
`AFFLT0294414
`
`Samsung Ex. 1216 p. 1186
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 105 of 440
`
`Cordless Teiephony Profile
`
`Bluetooth.
`
`The Cordless Telephony profile supports a topology of one gateway (GW) and
`a small number (3?) of terminals (TLs)". Figure 2.2 below shows an example of
`the considered architecture:
`
`"Bluetoo‘th only"
`5 peech P P5
`
`a u ar 1: one low
`M
`C H I
`h
`Blueto-oth speech
`
`Figure 2.2: System configuration example
`
`..-;_-
`I.‘-I.|_
`..
`.,..__
`-E”
`
`lalulti-media PC
`wflhhamemath
`59°“
`
`2.3 USER REQUIREMENTS AND SCENARIOS
`
`The following scenarios are covered by this profile:
`
`1. Connecting to the gateway so that incoming calls can be routed to the TL
`and outgoing calls can be originated.
`
`. Making a call from a TL to a user on the network that the gateway is
`connected to.
`
`. Receiving a call from the network that the gateway is connected to.
`
`4. Making direct calls between two terminals.
`
`. Using supplementary services provided by the external network by means of
`DTMF signalling and register recall (hook flash).
`
`1. Optionally, more terminais may be supported.
`
`Profile overview
`
`1 December 1999
`
`AFFLT029441 5
`
`Samsung Ex. 1216 p. 1187
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 8
`
`Cordless Telephony Profile
`
`2.4 PROFILE FUNDAMENTALS
`
`page 108 of440
`
`Bluetooth-
`
`The GW is normally the master of the piconet in the Cordless Telephony pro-
`file. As master, the GW will control the power mode of the TLs and may broad-
`cast information to the TLs.
`
`A TL that is out of range of a GW searches for it by periodically trying to page it.
`A GW shall devote as much of its free capacity as possible (considering power
`limitations and ongoing signalling) to page scanning in order to allow roaming
`TLs that enter the range of the GW to find it as quickly as possible. This
`scheme minimizes ‘air pollution‘ and gives reasonable access time when com-
`ing into range of the GW. When a TL has successfully paged a GW, a master-
`slave switch shall be performed since the GW shall be the master. A
`connection-oriented LZCAP channel and. possibly, a L2CAP connectionless
`channel are established to be used for all TCS signalling during that Cordless
`Telephony session.
`
`A TL that is within range of a GW shall normally be in park mode when it is not
`engaged in calls. This mode is power-efficient, allows for reasonable call set-
`up times and allows broadcasting to the attached TLs.
`
`Upon arrival of an incoming call, or when a TL wants to make an outgoing call,
`the GW shall be put in active mode. The L2CAP channels (see above) are
`used for all TCS control signalling. Voice is transported using SCO links.
`
`For security purposes, authentication of TLs and GW is used. and all user data
`is encrypted. To facilitate secure communication between cordless units. the
`WUG concept (see TCS Binary. Section 3) is used. The GW always acts as
`WUG master.
`
`2.5 FEATURE DEFINITIONS
`
`Calling line identification presentation (CLIP) — The ability to provide the
`calling party number to the called party before accepting the call.
`
`Call information — The ability to provide additional information during the
`active phase of a call.
`
`Connection Management — The ability to accept and (TLs only) request con-
`nections for the purposes of TCS-Bin procedures.
`
`DTMF signalling — The ability, in external calls, to send a DTMF signal over
`the external network to the other party.
`
`Incoming external call — A call originating from the external network con-
`nected to the GW.
`
`Initialization - The infrequent process whereby a TL receives access rights to
`a certain GW.
`
`1 December 1999
`
`Profile overview
`
`AFFLT029441 6
`
`Samsung Ex. 1216 p. 1188
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 107 of 440
`
`Cordless Telephony Profile
`
`Intercom call — A call originating from a TL towards another TL.
`
`Multi-terminal support —
`
`1. In the GW, the ability to handle multiple active terminals being registered at
`the same time2
`
`2. In the TL, the support for a Wireless User Group (WUG)
`
`On hook — The ability to indicate the action of going on-hook (e.g. to terminate
`a call), and release of all radio resources related to that call.
`
`Outgoing external call — A call originated by a TL towards the external
`network connected to the GW.
`
`Post-dialling - The ability to send dialling information after the outgoing call
`request set-up message is sent.
`
`Register recall — The ability of the TL to request ‘register recall’, and of the
`GW to transmit the request to the local network. Register recall means to seize
`a register (with dial tone) to permit input of further digits or other actions. In
`some markets, this is referred to as ‘hook flash’.
`
`2.6 CONFORMANCE
`
`lf conformance to this profile is claimed, all capabilities indicated as mandatory
`for this profile shall be supported in the specified manner (process—mandatory).
`This also applies to all optional and conditional capabilities for which support is
`indicated. All mandatory capabilities, and optional and conditional capabilities
`for which support is indicated, are subject to verification as part of the
`Bluetooth certification program.
`
`Note that the lnte.-“co:':'i Profiis is used for intercom calls. This means that a TL
`
`claiming conformance to the Cordless Telephony profile must conform to inter-
`com :3’rofiie.
`
`2. Note that a GW may support multiple active terminals but not a Wireless User Group
`(WUG).
`
`Profile overview
`
`1 December 1999
`
`AFFLT029441 7
`
`Samsung Ex. 1216 p. 1189
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 8
`
`Cordless Telephony Profile
`
`3 APPLICATION LAYER
`
`page 108 of440
`
`Bluetooth-
`
`The following text, together with the associated sub-clauses, defines the fea-
`ture requirements with regard to this profile.
`4
`iatrie 3. 3 shows the feature requirements made by this profile.
`
`item no.
`
`Support in TL
`
`Support in GW
`
`_l
`
`F9F’°.‘*'F”.‘-"':i'-"F-*’!\’
`
`—|. F’
`
`.5 _L
`
`Connection Management
`
`Outgoing external call
`
`Incoming external call
`
`Intercom call
`
`On hook
`
`Post-dialling
`
`Muiti-terminal support
`
`Call information
`
`Calling line identification presentation
`(CLIP)
`
`DTMF signalling
`
`Register recall
`
`Table 3.1: Application layer features
`
`Tania 3.2 maps each feature to the procedures used for that feature, and
`shows if the procedure is optional, mandatory or conditional for that feature.
`The procedures are described in the referenced section.
`
`Ref‘
`
`1. Connection Management
`
`Connecting to a GW
`
`Connecting to a TL
`
`2. Outgoing external call
`
`Call request
`
`Overlap sending
`
`Call proceeding
`
`Call confirmation
`
`Call connection
`
`In-band tones and
`
`announcements
`
`Table 3. 2: Application layer feature to procedure mapping
`
`1 December 1999
`
`Application layer
`
`AFFLT029441 B
`
`Samsung Ex. 1216 p. 1190
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 109 of 440
`
`Cordless Teiephony Profile
`
`Feature
`
`Procedure
`
`3. Incoming external call
`
`Call request
`
`Cali confirmation
`
`Cali connection
`
`Non-selected user
`
`clearing
`
`In-band tones and
`announcements
`
`4. Intercom call
`
`NOTE 1
`
`5. On hook
`
`6. Post-dialling
`
`Cali clearing
`
`Overlap sending
`
`Call proceeding
`
`7. Muiti-terminal support
`
`Obtain access rights
`
`Configuration distri-
`bution
`
`Fast inter-member
`access
`
`Periodic key update
`
`8. Call information
`
`Call information
`
`9. Calling line identification
`presentation (CLIP)
`
`Calling line identity
`
`10. DTMF signalling
`
`DTMF signalling
`
`11. Register recall
`
`Register recall
`
`C2: IF feature 6 THEN M else NIA
`
`Table 3.2: Application layer feature to procedure mapping
`
`Note 1: For intercom calls. the intercom profile is used. Before initiating the
`intercom call, the TL which is initiating the call may optionally use the fast
`inter-member access procedure to speed up the cail set-up.
`
`Application layer
`
`1 December 1999
`
`AFFLT029441 9
`
`Samsung Ex. 1216 p. 1191
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 8
`
`Cordiess Telephony Profits
`
`4 TCS-BI N PROCEDU RES
`
`page 110 cf440
`
`Bluetooth-
`
`The fotlowing text together with the associated sub-clauses defines mandatory
`requirements with regard to this profile.
`
`When describing TCS-BIN procedures, this section provides additional infor-
`mation concerning lower layer han