BLUETOOTH SPECHFICATION Version 1.0 B
`
`page 44 of44D
`
`Generic Access Profile
`
`6.5.3.2 Dedicated bonding
`
`initiate bonding
`
`make airable
`
`Delete link key to
`paged device
`
`l=_'aging_
`
`LMP=name reg_ _ _ _
`-_-_ I-MP;.'."'i'T'$'£§ _ ._
`
`Li'v'|F’_host_connection_re
`LMP acce ted
`
`Authentication
`
`LMP detach
`
`Figure 6. ?: Bonding as perfonned when the purpose of the procedure is only to create and
`exchange a link key between two Bluetocth devices.
`
`6.5.4 Conditions
`
`Before bonding can be initiated. the initiating device (A) must know the Device
`Access Code of the device to pair with. This is normally done by first perform-
`ing device discovery. A Bluetooth Device that can initiate bonding (A) should
`use limited inquiry. and a Bluetooth Device that accepts bonding (B) should
`support the limited discoverable mode.
`
`Bonding is in principle the same as link establishment with the conditions:
`
`- The paged device (B) shall be set into pairable mode. The paging device (A)
`is assumed to allow pairing since it has initiated the bonding procedure.
`
`The paging device (the initiator of the bonding procedure, A) shall initiate
`authentication.
`
`Before initiating the authentication part of the bonding procedure, the paging
`device should delete any link key corresponding to a previous bonding with
`the paged device.
`
`If the paging device does not intend to initiate any higher layer initialization
`during bonding, it need not send LlvlP_host_request before initiating
`authentication.
`
`'1 December 1999
`
`Idle mode procedures
`
`AFFLTD294354
`
`Samsung Ex. 1316 p. 1126
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 45 of 440
`
`Generic Access Profile
`
`7 ESTABLISHMENT PROCEDURES
`
`-I
`
`1
`
`2
`
`Link establishment
`
`Channel establishment
`
`Connection establishment
`
`Table 7.1: Establishment‘ procedures
`
`The establishment procedures defined here do not include any discovery part.
`Before establishment procedures are initiated. the information provided during
`device discovery (in the FHS packet of the inquiry response or in the response
`to a name request) has to be available in the initiating device. This information
`Is:
`
`- The Bluetooth Device Address (BD_ADDR) from which the Device Access
`Code is generated:
`
`' The system clock of the remote device;
`
`- The page scan mode used by the remote device.
`
`Additional information provided during device discovery that is useful for mak-
`ing the decision to initiate an establishment procedure is:
`
`- The Class of device;
`
`- The Device name.
`
`7.1 LINK ESTABLISHMENT
`
`7.1.1 Purpose
`
`The purpose of the link establishment procedure is to establish a physical link
`(of ACL type) between two Bluetooth devices using procedures from {*3} and
`till.
`
`7.1.2 Term on Ul level
`
`'B|L.Ietooth link establishment‘
`
`Establishment procedures
`
`1 December 1999
`
`AFFLT0294355
`
`Samsung Ex. 1316 p. 1127
`
`

`
`BLUETOOTH SPECHFICATION Version 1.0 B
`
`page 46 of44D
`
`Generic Access Profile
`
`?.1.3 Description
`
`In this sub-section, the paging device (A) is in security mode 3. The paging
`device cannot during link establishment distinguish if the paged device (B) is in
`security mode 1 or 2.
`
`7.1.3.‘! B Q] secgritg mode 1 gr2
`
`make connectabie
`
`switch negotiation H
`
`Link setulp H
`
`LMP hosl connection re
`LMP acoe ed
`
`.3iuih_entic_af|i3n_ _
`
`-E-ricryipiion negotietion U
`
`Link selup complete
`
`Figure ?.1.' Link esrabiishment procedure when the paging device (A) is in security mode 3 and
`the paged device (3) is in security mode 1 or 2.
`
`‘I December 1999
`
`Eslablishmenl procedures
`
`AFFLT0294356
`
`Samsung Ex. 1316 p. 1128
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`Generic Access Profile
`
`7.1.3.2 Bin security: mode 3
`
`page 47 of 440
`
`Bluetooth.
`
`make connectable
`
`Paging
`
`“Switch negotiation I
`
`I
`
`I Link setup
`
`LMP hcst_ccnne-ction re
`LMF'_accepted
`
`Authentication
`
`Authentication
`
`‘Encryption negotiation
`
`Link setup complete
`
`Figure 7.2: Link estabiisirment procedure when both the paging device (A) and the paged
`device (B) are in security mode 3.
`
`7.1.4 Conditions
`
`The paging procedure shall be according to it} and the paging device should
`use the Device access code and page mode received through a previous
`inquiry. When paging is completed. a physical link between the two Bluetooth
`devices is established.
`
`If role switching is needed (normally it is the paged device that has an interest
`in changing the masterislave roles) it should be done as early as possible after
`the physical link is established. If the paging device does not accept the switch.
`the paged device has to consider whether to keep the physical link or not.
`
`Both devices may perform link setup (using LMP procedures that require no
`interaction with the host on the remote side). Optional LMP features can be
`used after having confirmed (using LMP_feature_req) that the other device
`supports the feature.
`
`Establishment procedures
`
`1 December 1999
`
`AFFLT0294357
`
`Samsung Ex. 1316 p. 1129
`
`

`
`BLUETOOTH SPECWICATION Version 1.0 B
`
`Generic Access Profile
`
`page 48 of44D
`
`Bluetuoth.
`
`When the paging device needs to go beyond the link setup phase, it issues a
`request to be connected to the host of the remote device. if the paged device is
`in security mode 3, this is the trigger for initiating authentication.
`
`The paging device shall send LMP_host_connection_req during link establish-
`ment (i.e. before channel establishment) and may initiate authentication only
`after having sent LMP_host_connection_request.
`
`After an authentication has been performed, any of the devices can initiate
`encryption.
`
`Further link configuration may take place after the Ll'v1P_host_connection_req.
`When both devices are satisfied. they send LlvlP_setup__complete.
`
`Link establishment is completed when both devices have sent
`LMP_setup_cornp|ete.
`
`7.2 CHANNEL ESTABLISHMENT
`
`7.2.1 Purpose
`
`The purpose of the channel establishment procedure is to establish a Blue-
`tooth channel (a logical link) between two Bluetooth devices using {:3}.
`
`T.2.2 Term on Ul level
`
`'Bluetooth channel establishment’.
`
`7.2.3 Description
`
`In this sub-section. the initiator (A) is in security mode 3. During channel
`establishment, the initiator cannot distinguish if the acceptor (B) is in security
`mode 1 or 3.
`
`‘I December 1999
`
`Establishment procedures
`
`AFFLT029435B
`
`Samsung Ex. 1316 p. 1130
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 49 of 440
`
`Generic Access Profile
`
`7.2.3.1 B in security: mode 2
`
`established link
`
`L2CAP_Con neclF2eq
`
`Authentication
`
`Encryption negotiation
`
`L2CAP ConnectRsp(+)
`
`Figure 7.3: Channei estabiishment procedure when the initiator (A) is in security mode 3 and
`the acceptor (B) is in security mode 2.
`
`7.2.3.2 Bin security mode 1' or 3
`
`__ established link
`
`L2CAP_Con ne ctR eq
`
`LZCAP ConnectRs(+)
`
`Figure 7.4: Channel estabiishment procedure when the initiator (A) is in security mode 3 and
`the acceptor (B) is in security mode 1 or 3.
`
`7.2.4 Conditions
`
`Channel establishment starts after link establishment is completed when the
`initiator sends a channel establishment request (L2CAF’_ConnectReq).
`
`Depending on security mode. security procedures may take place after the
`channel establishment has been initiated.
`
`Channel establishment is completed when the acceptor responds to the chan-
`nel establishment request (with a positive L2CAP_ConnectRsp).
`
`Establishment procedures
`
`1 December 1999
`
`AFFLT0294359
`
`Samsung Ex. 1316 p. 1131
`
`

`
`BLUETOOTH SPECHFICATION Version 1.0 B
`
`Generic Access Profile
`
`7.3 CONNECTION ESTABLISHMENT
`
`7.3.1 Purpose
`
`page 50 of 440
`
`Bluetuoth.
`
`The purpose of the connection establishment procedure is to establish a con-
`nection between applications on two Bluetooth devices.
`
`?.3.2 Term on UI level
`
`'Bluetooth connection establishment’
`
`7.3.3 Description
`
`In this sub-section, the initiator (A) is in security mode 3. During connection
`establishment. the initiator cannot distinguish if the acceptor (B) is in security
`mode 1 or 3.
`
`7’. 3. 3.1 B in security mode 2
`
`connecl_est_req
`
`Authentication
`
`Encryption negotiation
`
`connecl_est_acc
`
`Figure 7'. 5: Connection establishment procedure when the initiator (A) is in security mode 3
`and the acceptor (B) is in security mode 2.
`
`‘I December 1999
`
`Establishment procedures
`
`AFFLT0294360
`
`Samsung Ex. 1316 p. 1132
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`Generic Access Profile
`
`7.3.3.2 Bin security: mode 1 or3
`
`page 51 of 440
`
`Bluetouth.
`
`established channel
`
`connect BS1 re 0
`
`connect__est_acc
`
`Figure 7.6: Connection estabiishment procedure when the initiator (A) is in security mode 3
`and the acceptor (B) is in security mode 1 or 3.
`
`7.3.4 Conditions
`
`Connection establishment starts after channel establishment is completed,
`when the initiator sends a connection establishment request ('connect_est_req'
`is application protoco|—dependent). This request may be a TCS SETUP mes-
`sage {5} in the case of a Bluetooth telephony application Cmdiess Teiephony
`?scfiie. or initialization of RFCOMM and establishment of DLC 36%] in the case of
`a serial port-based application Eieriaé Port Profits (although neither TCS or
`RFCOMM use the term ‘connection’ for this).
`
`Connection establishment is completed when the acceptor accepts the
`connection establishment request ('connect_est_acc' is application protocol
`dependent).
`
`7.4 ESTABLISHMENT OF ADDITIONAL CONNECTION
`
`When a Bluetooth device has established one connection with another
`
`Bluetooth device. it may be available for establishment of“.
`
`- A second connection on the same channel. andior
`
`- A second channel on the same link, andior
`
`- A second physical link.
`
`If the new establishment procedure is to be towards the same device. the secu-
`rity part of the establishment depends on the security modes used. If the new
`establishment procedure is to be towards a new remote device, the device
`should behave according to active modes independent of the fact that it
`already has another physical link established (unless allowed co-incident radio
`and baseband events have to be handled).
`
`Establishment procedures
`
`1 December 1999
`
`AFFLTO294361
`
`Samsung Ex. 1316 p. 1133
`
`

`
`BLUETOOTH SPECHFICATION Version 1.0 B
`
`Generic Access Profile
`
`8 DEFINITIONS
`
`page 52 of44D
`
`Bluetooth.
`
`In the following, terms written with capital letters refer to states.
`
`8.1 GENERAL DEFINITIONS
`
`Mode A set of directives that defines how a device will respond to certain
`events.
`
`ldle As seen from a remote device, a Bluetooth device is idle, or is in idle
`mode. when there is no link established between them.
`
`Bond A relation between two Bluetooth devices defined by creating. exchang-
`ing and storing a common link key. The bond is created through the bonding or
`LMP-pairing procedures.
`
`8.2 CON NECTION-RELATED DEFINITIONS
`
`Physical channel A synchronized Bluetooth baseband-compliant RF hopping
`sequence.
`
`Piconet A set of Bluetooth devices sharing the same physical channel defined
`by the master parameters (clock and BD_ADDR).
`
`Physical link A Baseband-level connection" between two devices established
`using paging. A physical link comprises a sequence of transmission slots on a
`physical channel alternating between master and slave transmission slots.
`
`ACL link An asynchronous (packet-switched) connection‘ between two
`devices created on LMP level. Traffic on an ACL link uses AC1. packets to be
`transmitted.
`
`SE30 link A synchronous (circuit-switched) connection‘ for reserved bandwidth
`communications; e.g. voice between two devices, created on the LMP level by
`reserving slots periodically on a physical channel. Traffic on an SCO link uses
`SCO packets to be transmitted. SCO links can be established only after an
`ACL link has first been established.
`
`Link shorthand for an ACL link.
`
`PAGE A baseband state where a device transmits page trains, and processes
`any eventual responses to the page trains.
`
`PAGE_SCAN A baseband state where a device listens for page trains.
`
`1. The term 'connection‘ used here is not identical to the definition below. It is used in the
`absence of a more concise term.
`
`'1 December 1999
`
`Definitions
`
`AFFLT0294362
`
`Samsung Ex. 1316 p. 1134
`
`

`
`BLUETDOTH SPECIFICATION Version 1.0 B
`
`page 53 of 440
`
`Generic Access Profile
`
`Page The transmission by a device of page trains containing the Device
`Access Code of the device to which the physical link is requested.
`
`Page scan The listening by a device for page trains containing its own Device
`Access Code.
`
`Channel A logical connection on L2CAP level between two devices serving a
`single application or higher layer protocol.
`
`Connection A connection between two peer applications or higher layer
`protocols mapped onto a channel.
`
`Connecting A phase in the communication between devices when a connec-
`tion between them is being established. (Connecting phase follows after the
`link establishment phase is completed.)
`
`Connect (to service) The establishment of a connection to a service. if not
`already done, this includes establishment ofa physical link. link and channel as
`well.
`
`8.3 DEV|CE—RELATED DEFINITIONS
`
`Discoverable device A Bluetooth device in range that will respond to an
`inquiry (normally in addition to responding to page).
`
`Silent device A Bluetooth device appears as silent to a remote device if it does
`not respond to inquiries made by the remote device. A device may be silent
`due to being non-discoverable or due to baseband congestion while being
`discoverable.
`
`Connectable device A Bluetooth device in range that will respond to a page.
`
`Trusted device A paired device that is explicitly marked as trusted.
`
`Paired device A Bluetooth device with which a link key has been exchanged
`(either before connection establishment was requested or during connecting
`phase).
`
`Pre-paired device A Bluetooth device with which a link key was exchanged,
`and the link key is stored, before link establishment.
`
`Un-paired device A Bluetooth device for which there was no exchanged link
`key available before connection establishment was request.
`
`Known device A Bluetooth device for which at least the BD_ADDR is stored.
`
`Un-known device A Bluetooth device for which no information (BD_ADDR.
`link key or other) is stored.
`
`Definitions
`
`1 December 1999
`
`AFFLT0294353
`
`Samsung Ex. 1316 p. 1135
`
`

`
`BLUETCIOTH SPECHFICATION Version 1.0 B
`
`Generic Access Profile
`
`page 54 of-440
`
`Bluetooth.
`
`Authenticated device A Bluetooth device whose identity has been verified
`during the lifetime of the current link, based on the authentication procedure.
`
`8.4 PROCEDURE—RELATED DEFINITIONS
`
`Paging A procedure for establishing a physical link of ACL type on baseband
`level, consisting of a page action of the initiator and a page scan action of the
`responding device.
`
`Link establishment A procedure for establishing a link on LMP level. A link is
`established when both devices have agreed that LMP setup is completed.
`
`Channel establishment A procedure for establishing a channel on L2CAP
`level.
`
`Connection establishment A procedure for creating a connection mapped
`onto a channel.
`
`Creation of a trusted relationship A procedure where the remote device is
`marked as a trusted device. This includes storing a common link key for future
`authentication and pairing (if the link key is not available).
`
`Creation of a secure connection. A procedure of establishing a connection,
`including authentication and encryption.
`
`Device discovery A procedure for retrieving the Bluetooth device address.
`clock. class-of-device field and used page scan mode from discoverable
`devices.
`
`Name discovery A procedure for retrieving the user-friendly name (the Blue-
`tooth device name) of a connectable device.
`
`Service discovery Procedures for querying and browsing for services offered
`by or through another Bluetooth device.
`
`8.5 SECURITY-RELATED DEFINITIONS
`
`Authentication A generic procedure based on LMP-authentication if a link key
`exists or on LMP-pairing if no link key exists.
`
`LMP-authentication An LMP level procedure for verifying the identity of a
`remote device. The procedure is based on a challenge-response mechanism
`using a random number, a secret key and the BD_ADDR of the non-initiating
`device. The secret key used can be a previously exchanged link key or an ini-
`tialization key created based on a PIN (as used when pairing).
`
`Authorization A procedure where a user of a Bluetooth device grants a
`specific (remote) Bluetooth device access to a specific service. Authorization
`
`'1 December 1999
`
`Definitions
`
`AFFLTU294364
`
`Samsung Ex. 1316 p. 1136
`
`

`
`BLUETDOTH SPECIFICATION Version 1.0 B
`
`page 55 of 440
`
`Generic Access Profile
`
`implies that the identity of the remote device can be verified through authenti-
`cation.
`
`Authorize The act of granting a specific Bluetooth device access to a specific
`service. It may be based upon user confirmation, or given the existence of a
`trusted relationship.
`
`LMP-pairing A procedure that authenticates two devices, based on a PIN, and
`subsequently creates a common link key that can be used as a basis for a
`trusted relationship or a (single) secure connection. The procedure consists of
`the steps: creation of an initialization key (based on a random number and a
`PIN), L|'v|P-authentication based on the initialization key and creation of a com-
`mon link key.
`
`Bonding A dedicated procedure for performing the first authentication, where
`a common link key is created and stored for future use.
`
`Trusting The marking of a paired device as trusted. Trust marking can be done
`by the user. or automatically by the device (e.g. when in pairable mode) after a
`successful pairing.
`
`Definitions
`
`1 December 1999
`
`AFFLT0294365
`
`Samsung Ex. 1316 p. 1137
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`Generic Access Profile
`
`page 56 of 440
`
`Bluetooth.
`
`9 ANNEX A (NORMATIVE): TIMERS AND CONSTANTS
`
`The following timers are required by this profile.
`
`Timer
`
`Recommended
`
`.
`
`.
`
`Normal time span that a
`Bluetooth device performs
`inquiry.
`
`Minimum time in
`
`lNQUIRY_SCAN.
`
`Maximum time between
`repeated iNQUlRY_SCAN
`enterlngs.
`
`A Bluetooth device shall
`not be in a discoverable
`
`mode less than TGAp(103}.
`
`A Bluetooth device should
`not be in limited discover-
`able mode more than
`
`TGAp{104).
`
`Used during inquiry and
`device discovery.
`
`A discoverable Biuetooth
`device enters
`
`INQU lRYflSCAN for at least
`TGAp{101) EVETY
`
`Maximum value of the
`inquiry scan interval,
`
`Tinquiry scan-
`Minimum time to be
`discoverable.
`
`Recommended upper limit.
`
`Tabie 9.1: Defined GAP tirners
`
`‘I December 1999
`
`Annex A {Normative}: 'l'imers and constants
`
`AFFLT0294356
`
`Samsung Ex. 1316 p. 1138
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`Generic Access Profile
`
`page 57 of 440
`
`Bluetooth.
`
`10 ANNEX B (INFORMATIVE): INFORMATION FLOWS
`OF RELATED PROCEDURES
`
`10.1 LMP-AUTH ENTICATION
`
`The specification of authentication on link level is found in
`
`Verifier
`
`(initiator)
`
`.
`
`init_aulhenticatiori
`
`secret ke
`{link key or Kinit)
`
`Generate
`random number
`
`{link key or Kinit)
`
`|mp_au_rand
`
`Calculate
`challenge
`
`Calculate
`response
`
`Figure 10.1: Lrl/iP—a-urhenticarron as defined by 524?.
`
`The secret key used here may be either an already exchanged link key or an
`initialization key created in the LM P-pairing procedure.
`
`Annex B [lnlorn1ative}'_ Information flows of related procedures 1 December 1999
`
`AFFLTD2943B7
`
`Samsung Ex. 1316 p. 1139
`
`

`
`BLUETOOTH SPECHFICATION Version 1.0 B
`
`page 58 of44D
`
`Generic Access Profile
`
`10.2 LMP-PAIRING
`
`The specification of pairing on link level is found in E2}.
`
`Verifier
`
`i'"i“a‘°'>
`
`.
`
`Generate
`random number
`
`LMP_in_rand
`LMP_a-coepted
`
`Calculate Kinit
`
`Calculate Kinit
`
`Imp-authentication-
`
`create link key
`
`Figure 10. 2: LMP-pairing as defined in ,*'2_:‘.
`
`The PIN used here is PNBB.
`
`The create link key procedure is described in section 3.3.4 of [2] and section
`14.2.2 of [1]. In case the link key is based on a combination key. a mutual
`authentication takes place and shall be performed irrespective of current secu-
`rity mode.
`
`10.3 SERVICE DISCOVERY
`
`The Service Discovery Protocol {F5} Specifies what PDUs are used over-the-air
`to inquire about services and service attributes. The procedures for discovery
`of supported services and capabilities using the Service Discovery Protocol are
`described in the S£§f‘»’ECE? Discovery Appiication i-‘rattle. This is just an example.
`
`1 December 1999
`
`Annex El {informative}: Information flows of
`
`AFFLTD29436B
`
`Samsung Ex. 1316 p. 1140
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 59 of 440
`
`Generic Access Profile
`
`initiate service discovery
`
`make cannectable
`
`_ Link estab|isl:Imen_r_
`
`C hannel establishment
`
`_
`
`service discovery session '
`
`Channel release
`
`LMP_detach
`
`Figure 10.3: Service discovery procedure.
`
`Annex B [|nforr11ative}'_ Information flows of related procedures ‘I December 1999
`
`AFFLT0294369
`
`Samsung Ex. 1316 p. 1141
`
`

`
`BLUETOOTH SPECHFICATION Version 1.0 B
`
`page 80 of44D
`
`Generic Access Profile
`
`11 REFERENCES
`
`[1] Bluetooth Baseband Specification
`
`[2] Bluetooth Link Manager Protocol
`
`[3] Bluetooth Logical Link Control and Adaptation Protocol
`
`[4] Bluetooth RFCOMM
`
`[5] Bluetooth Telephony Control Specification
`
`[6} Bluetooth Service Discovery Protocol
`
`[?] Bluetooth Service Discovery Application Profile
`
`[81 Bluetooth Cordless Telephony Profile
`
`[9] Bluetooth Serial Port Profile
`
`[10] Bluetooth Security Architecture (white paper)
`
`[11] Bluetooth Assigned Numbers
`
`‘I December 1999
`
`References
`
`AFFLTD294370
`
`Samsung Ex. 1316 p. 1142
`
`

`
`AFFLT0294371
`
`Q =:~SERVlCE DISCOVERY
`PLICATION PROFILE
`
` a
`
`; This ocum nt defines the features and proce-
`dure for an ppiication in a Bluetooth device
`to di cover ervices registered in other
`B|u_ tooth _ vices and retrieve any desired
`
`5_
`
`jgvllable iugrormation pertinentto these
`
`ices. 3.?‘
`
`Samsung Ex. 1316 p. 1143
`
`

`
`BLUETOOTH SPECWICATION Version 1.0 B
`
`page 62 of-L140
`
`Service Discovery Application Profile
`
`1 December 1999
`
`AFFLTD294372
`
`Samsung Ex. 1316 p. 1144
`
`

`
`BLUETDOTH SPECIFICATION Version 1.0 B
`
`Service Discovery Application Profiie
`
`CONTENTS
`
`page 63 of 440
`
`Bluetoath.
`
`Imrosiuction ................................................................................
`
`1.1
`
`1.2
`
`Scope
`
`S‘,»’E’1’1§}£JE55 and corwentiorts
`
`6%
`
`6?’
`
`?m§§§e szavawiew .......................................
`
`...................................... ..
`
`$8
`
`2.1
`
`5-‘wofiia stack
`
`58
`
`Configtxratiarws and rah"-:5
`2.2
`2.3 User requirements and scenar¥{3$ ............................................ ..
`2.4
`Pmfiie {Lunch-tmentais
`.?1
`4
`2." Coraformar1ce........ . ...
`
`.69
`‘YB
`
`.
`
`.....'F1
`
`._ .
`
`.
`
`..
`
`Lisa? interface asgecfis
`
`3.1
`
`.
`
`...'?2
`37.?
`
`.72
`
`Apgaiicaticn iayer ...........................
`
`........................................
`
`‘me service dnscovery apgzficatéon
`
`4.‘:
`
`4.2
`
`'?3
`
`..... ..
`.73
`5:
`"f3:
`
`E3ervice pi‘irni!ives ai*:.stra<:ti:3ns ................................................ ..
`
`4.3 Message saquersce chafls {ivifiiis} ........
`
`.............................. ..
`
`7*?
`
`$e;'vice Biscmrery ..........
`
`..........................
`
`...........
`
`....
`
`........
`
`5.1
`
`An SUE“ ¥5E3L5 exchange
`
`"23
`.\J
`R3
`
`LECAP ............................................................................................... ..
`
`8.’!
`
`6.3
`
`{}c:r:figuration c>ption3..........
`6.3.1 Maximum Transmission Unit
`6.3.2
`Fiush Time~csut....................
`
`Qu:3%:'iyo§Ser~.'ice.............--\...........................................
`
`6.4
`
`SQP‘ iranssactiuns and LECAP conraecflon iifeafirrie
`
`Lmk Manager .............................................
`
`.................................... ..
`
`fllapahiifigr
`
`}’.3
`
`Link
`
`Link c<3ntrs:3i..............
`
`.
`
`8.1
`
`Capabiitiy
`
`8.3
`8.4
`
`8.5
`8.6
`
`inquiry
`
`Page scan
`Ermr berzaviur
`
`1 December ‘I999
`
`82
`
`83
`
`233
`
`.
`
`‘
`
`"
`
`‘
`
`AFFLT0294373
`
`Samsung Ex. 1316 p. 1145
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 84 of44D
`
`Service Discovery Application Prnffle
`
`£3
`
`3.1
`
`‘E9
`
`fiefmatmns
`
`figgenfiix 9. {Enfcfmative}: fiervica gcriwaitivea and tha
`Eéuatoath
`
`‘I December 1999
`
`AFFLT0294374
`
`Samsung Ex. 1316 p. 1146
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 65 of 440
`
`Service Discovery Application Profile
`
`FOREWORD
`
`Interoperability between devices from different manufacturers is provided for a
`specific service and use case, if the devices conform to a Bluetooth SIG-
`defined profile specification. A profile defines a selection of messages and
`procedures (generally termed capabilities) from the Bluetooth SIG specifica-
`tions, and gives an unambiguous description of the air interface for specified
`service(s) and use case(s).
`
`All defined features are process-mandatory. This means that, if a feature is
`used. it is used in a specified manner. Whether the provision of a feature is
`mandatory or optional is stated separately for both sides of the Bluetooth air
`interface.
`
`1 December 1999
`
`AFFLT0294375
`
`Samsung Ex. 1316 p. 1147
`
`

`
`BLUETOOTH SPEClF|CAT|ON Version 1.0 B
`
`Service Discovery Application Profile
`
`1
`
`INTRODUCTION
`
`1.1 SCOPE
`
`page 86 of 440
`
`Bluetuuth.
`
`It is expected that the number of services that can be provided over Bluetooth
`links will increase in an undetermined (and possibly uncontrolled) manner.
`Therefore, procedures need to be established to aid a user of a Bluetooth-
`enabled device to sort the ever-increasing variety of services that will become
`available to himiher. While many of the Bluetooth-enabled services that may be
`encountered are currently unknown, a standardized procedure can still be put
`into place on how to locate and identify them.
`
`The Bluetooth protocol stack contains a Service Discovery Protocol (SDP)
`BT_SDP_spec:{7] that is used to locate services that are available on or via
`devices in the vicinity of a Bluetooth enabled device. Having located what
`services are available In a device, a user may then select to use one or more of
`them. Selecting, accessing, and using a service is outside the scope of this
`document. Yet, even though SDP is not directly involved in accessing services,
`information retrieved via SDP facilitates service access by using it to properly
`condition the local Bluetooth stack to access the desired service.
`
`The service discovery profile defines the protocols and procedures that shall
`be used by a service discovery application on a device to locate services in
`other Bluetooth-enabled devices using the Bluetooth Service Discovery Proto-
`col (SDP). With regard to this profile. the service discovery application is a spe-
`cific user-initiated application. In this aspect, this profile is in contrast to other
`profiles where service discovery interactions between two SDP entities in two
`Bluetooth-enabled devices result from the need to enable a particular transport
`service (e.g. RFCOMM, etc.}, or a particular usage scenario (e.g. file transfer,
`cordless telephony, LAN AP, etc.) over these two devices. Service discovery
`interactions of the latter kind can be found within the appropriate Bluetooth
`usage scenario profile documents.
`
`The service discovery in the other profile documents has a very narrow scope;
`e.g. learning about the protocols and related protocol parameters needed for
`accessing a particular service. Nevertheless, the fundamentals of the service
`discovery procedures covered in this profile document, and the use of the
`Bluetooth protocols in support of these procedures can be replicated in other
`profile documents as well. The only difference is that for the other profiles
`these procedures are initiated by application-level actions within the applica-
`tions described by the corresponding profiles, as opposed to user-level actions
`for this profile.
`
`‘I December 1999
`
`introduction
`
`AFFLT0294375
`
`Samsung Ex. 1316 p. 1148
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 67 of 440
`
`Service Discovery Application Profile
`
`SDP provides direct support for the following set of service inquiries:
`
`- Search for services by service class:
`
`- Search for services by service attributes; and
`
`- Service browsing.
`
`The generic service discovery application considered for this profile also
`covers the above service inquiry scenarios.
`
`The former two cases represent searching for known and specific services.
`They provide answers to user questions like: "Is service A, or is service A with
`characteristics B and C, available?'' The latter case represents a general
`service search and provides answers to questions like: "What services are
`available?" or "What services of type A are available?"
`
`The above service inquiry scenarios can be realized two-fold:
`
`- By performing the service searches on a particular device that a user ‘con-
`scious|y' has already connected to, andior
`
`By performing the service searches by ‘unconsciously connecting to
`devices discovered in a device's vicinity.
`
`Both of the above approaches require that devices need first to be discovered.
`then linked with, and then inquired about the services they support.
`
`1.2 SYMBOLS AND CONVENTIONS
`
`This profile uses the symbols and conventions specified in Section 1.2 of the
`Generic: Access Profile
`
`introduction
`
`1 December 1999
`
`AFFLTU294377
`
`Samsung Ex. 1316 p. 1149
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`Service Discovery Application Profits
`
`2 PROFILE OVERVIEW
`
`2.1 PROFILE STACK
`
`page 88 of44tJ
`
`Bluetuuth.
`
`Figure 2.1 shows the Bluetooth protocols and supporting entities involved in
`this profile.
`
`SrvDscApp
`
`SDP (server:
`
`LZCA layer
`
`Baseband
`
`Figure 2.1’: The Bruetooth protocol stack for the service discovery profits
`
`The service discovery user application (SrvDscApp) in a local device (LocDev)
`interfaces with the Bluetooth SDP client to send service inquiries and receive
`service inquiry responses from the SDP servers of remote devices (RemDevs)
`BT_SDP_spec:[?}. SDP uses the connection-oriented (CO) transport service in
`L2CAP. which in turn uses the baseband asynchronous oonnectionless (ACL)
`links to ultimately carry the SDP PDUS over the air.
`
`Service discovery is tightly related to discovering devices. and discovering
`devices is tightly related to performing inquiries and pages. Thus. the SrvD-
`scApp interfaces with the baseband via the BT_moclule_Cntrl entity that
`instructs the Bluetooth module when to enter various search modes of opera-
`tion.1
`
`1. The BT_mor:lu|e_Cntrl may be part ofa Bluetooth stack implementation (and thus he shared
`by many Bluetooth-aware applications) or a ‘lower part‘ of the SrvDscApp. Since. no
`assumptions about any particular stack or SrvDscApp implementations are made. the
`BT__moduIe_Cntrl entity represents a logiwi entity separate from the SrvDscApp. which may
`or may not be part ofthe SrvDscApp itself. a stack component. or any other appropriate
`piece of code.
`
`‘I December 1999
`
`Profile overview
`
`AFFLT0294378
`
`Samsung Ex. 1316 p. 1150
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 69 of 440
`
`Service Discovery Application Profile
`
`The service records database (DB) shown in F'igure 2.? next to an SDP server
`is a logical entity that serves as a repository of service discovery-related infor-
`mation. The ‘physical form’ of this database is an implementation issue outside
`the scope of this profile.
`
`2.2 CONFIGURATIONS AND ROLES
`
`The following roles are defined in this profile:
`
`- Local device (LocDev): A LocDev is the device that initiates the service
`discovery procedure. A LocDev must contain at least the client portion of the
`Bluetooth SDP architecture BT_SDP_spec:{‘i‘;. A LocDev contains the ser-
`vice discovery application (SrvDscApp) used by a user to initiate discoveries
`and display the results of these discoveries.
`
`Remote Device(s) (RemDev(s)): A RemDev is any device that participates
`in the service discovery process by responding to the senrice inquiries gen-
`erated by a LocDev. A RemDev must contain at least the server portion of
`the Bluetooth SDP architecture BT_SDP_spec:§‘i}. A RemDev contains a
`service records database. which the server portion of SDP consults to
`create responses to service discovery requests.
`
`The LocDev or RemDev role assigned to a device is neither permanent nor
`exclusive. A RemDev may also have a SrvDscApp installed into it as well as an
`SDP client. and a LocDev may also have an SDP server. In conjuction with
`which device has an SrvDscApp installed, an SDP-client installed, and an
`SDP-server installed. the assignment of devices to the above roles is relative to
`each individual SDP (and related) transaction and which device initiates the
`transaction. Thus. a device could be a LocDev for a particular SDP transaction.
`while at the very same time be a RemDev for another SDP transaction.
`
`With respect to this profile, a device without a Ul (directly or indirectly available)
`for entering user input and returning the results of service searches is not con-
`sidered as a candidate for a LocDev. Nevertheless. even if such a device is not
`considered as a candidate for a LocDev, the procedures presented in the fol-
`lowing sections can still apply if applications running in such a device need to
`execute a service discovery transaction.
`
`P