BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 39 of 440
`
`Generic Access Profiie
`
`discoverable device scans for the LIAC, the initiating device may choose any
`inquiry procedure (general or limited). Even if the remote device that is to be
`discovered is expected to be made limited discoverable (e.g. when a dedicated
`bonding is to be performed), the limited inquiry should be done in sequence
`with a general inquiry in such a way that both inquiries are completed within the
`time the remote device is limited discoverable, i.e. at least TGAp(1O3).
`
`6.2.2 Term on Ul level
`
`'B|uetooth Device Inquiry‘.
`
`6.2.3 Description
`
`list of
`Bluetooth
`Device
`Addresses
`
`Figure 6.2: Limited inquiry where Bis a device in non-discoverabie mode, 8’ is a device in
`iimifed discoverabie mode and B" is a device in generai discoverabie mode. {Note that oniy
`limited discoverabie devices can be discovered using iimiied inquiry.)
`
`6.2.4 Conditions
`
`When limited inquiry is initiated by a Bluetooth device, it shall be in the
`INQUIRY state for at least TGAp(100) and perform inquiry using the LIAC.
`
`In order to receive inquiry response, the remote devices in range has to be
`made limited discoverable.
`
`Idle mode procedures
`
`1 December 1999
`
`AFFLT0294349
`
`Samsung Ex. 1119 p. 1121
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 8
`
`Generic Access Profile
`
`6.3 NAME DISCOVERY
`
`6.3.1 Purpose
`
`page 40 of 440
`
`Bluetooth-
`
`The purpose of name discovery is to provide the initiator with the Bluetooth
`Device Name of connectable devices (i.e. devices in range that will respond to
`Paging)-
`
`6.3.2 Term on Ul level
`
`‘Bluetooth Device Name Discovery’.
`
`6.3.3 Description
`
`6.3. 3.1 Name reguest
`
`Name request is the procedure for retrieving the Bluetooth Device Name from
`a connectable Bluetooth device. It is not necessary to perform the full link
`establishment procedure (see Section $3.?) in order to just to get the name of
`another device.
`
`Paging
`
`LMP name re
`
`LMP detach
`
`Figure 6.3: Name request procedure.
`
`6. 3. 3.2 Name discovery
`
`Name discovery is the procedure for retrieving the Bluetooth Device Name
`from connectable Bluetooth devices by performing name request towards
`known devices (i.e. Bluetooth devices for which the Bluetooth Device
`Addresses are available).
`
`1 December 1999
`
`Idle mode procedures
`
`AFFLT0294350
`
`Samsung Ex. 1119 p. 1122
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 41 of 440
`
`Generic Access Profile
`
`list of
`Bluetooth
`Device
`Addresses
`
`list of
`Bluetooth
`Device Names
`
`Name request
`
`Name request
`
`Name request
`
`Figure 6.4: Name discovery procedure.
`
`6.3.4 Conditions
`
`In the name request procedure. the initiator will use the Device Access Code of
`the remote device as retrieved immediately beforehand — normally through an
`inquiry procedure.
`
`6.4 DEVICE DISCOVERY
`
`6.4.1 Purpose
`
`The purpose of device discovery is to provide the initiator with the Bluetooth
`Address, clock, Class of Device, used page scan mode and Bluetooth device
`name of discoverable devices.
`
`6.4.2 Term on Ul level
`
`‘Bluetooth Device Discovery‘.
`
`Idle mode procedures
`
`1 December 1999
`
`AFFLT0294351
`
`Samsung Ex. 1119 p. 1123
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 8
`
`Generic Access Profile
`
`6.4.3 Description
`
`page 42 of 440
`
`Bluetooth-
`
`During the device discovery procedure, first an inquiry (either general or lim-
`ited) is performed, and then name discovery is done towards some or all of the
`devices that responded to the inquiry.
`
`make discoverable & connectable
`
`initiate
`device discovery
`
`is! of discovered Bluetooth devices
`(Bluetooth Device Addresses)
`
`ist cfdiscovered Bluetooth devices
`(Bluetooth Device Names)
`
`Na me discovery
`
`Figure 6. 5: Device discovery procedure.
`
`6.4.4 Conditions
`
`Conditions for both inquiry (genera! or limited) and name discovery must be ful-
`filled (i.e. devices discovered during device discovery must be both discover-
`able and connectable).
`
`6.5 BONDING
`
`6.5.1 Purpose
`
`The purpose of bonding is to create a relation between two Bluetooth devices
`based on a common link key (a bond). The link key is created and exchanged
`(pairing) during the bonding procedure and is expected to be stored by both
`Bluetooth devices, to be used for future authentication.
`
`In addition to pairing, the bonding procedure can involve higher layer initializa-
`tion procedures.
`
`6.5.2 Term on Ul level
`
`‘Bluetooth Bonding‘
`
`1 December 1999
`
`Idle mode procedures
`
`AFFLT0294352
`
`Samsung Ex. 1119 p. 1124
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 43 of 440
`
`Generic Access Profiie
`
`6.5.3 Description
`
`Two aspects of the bonding procedure are described here. Dedicated bonding
`is what is done when the two devices are explicitly set to perform only a cre-
`ation and exchange of a common link key.
`
`General bonding is included to indicate that the framework for the dedicated
`bonding procedure is the same as found in the normal channel and connection
`establishment procedures. This means that pairing may be performed suc-
`cessfully ifA has initiated bonding while B is in its normal connectable and
`security modes.
`
`The main difference with bonding, as compared to a pairing done during link or
`channel establishment, is that for bonding it is the paging device (A) that must
`initiate the authentication.
`
`6. 5.3. 1
`
`enerai bondin
`
`initiate bondin
`(BD_ADDR)
`
`Delete link key to
`paged device
`
`make airable
`
`Link esiabiish rnent
`
`Channel establishment
`
`Higher layer initiatisation
`
`Channel release
`
`LMP detach
`
`aired dE\|'l'Ce'-3
`
`Figure 6.6: General description of bonding as being the iink esiebiisnmeni procedure executed
`under specific conditions on both devices, foiiowed by an opfionai higher iayer initaiization
`process.
`
`Idle mode procedures
`
`1 December 1999
`
`AFFLT0294353
`
`Samsung Ex. 1119 p. 1125
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 8
`
`page 44 of440
`
`Generic Access Profile
`
`6.5.3.2 Dedicated bonding
`
`make pairable
`
`Paging
`
`LMP_name_req
`
`LMP_host_connection_re
`LMPacce _u ted
`
`Authentication
`
`LMP detach
`
`Figure 6.7’: Bonding as performed when the purpose of the procedure is only to create and
`exchange a iink key between two Biuetooth 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 LMP_host_request before initiating
`authentication.
`
`1 December 1999
`
`Idle mode procedures
`
`AFFLT0294354
`
`Samsung Ex. 1119 p. 1126
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 45 of 440
`
`Generic Access Profile
`
`7 ESTABLISHMENT PROCEDURES
`
`-M
`
`1
`
`2
`
`Link establishment
`
`Channel establishment
`
`Connection establishment
`
`' .:
`
`.-
`
`.-
`
`Table 7.1: Establishment procedures
`
`The establishment procedures defined here do not inciude 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 ofdevice;
`
`- 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 AOL type) between two Bluetooth devices using procedures from {E} and
`Exil-
`
`7.1.2 Term on Ul level
`
`‘Bluetooth link estabiishment’
`
`Establishment procedures
`
`1 December 1999
`
`AFFLT0294355
`
`Samsung Ex. 1119 p. 1127
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 8
`
`page 46 of440
`
`Generic Access Profile
`
`7.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 in security mode 1 or 2
`
`make connectabie
`
`Switch negotiation
`
`Link setup
`
`LMP host connection re
`LMP acoeted
`
`Authentication
`
`Encryption negotiation
`
`Link setup complete
`
`Figure 7'. 1: Link estabiishment procedure when the paging device (A) is in security mode 3 and
`the paged device (8) is in security mode 1 or 2.
`
`1 December 1999
`
`Establishment procedures
`
`AFFLT0294356
`
`Samsung Ex. 1119 p. 1128
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`Generic Access Profiie
`
`7.1.3.2 B in security mode 3
`
`page 47 of 440
`
`Bluetooth.
`
`make connectable
`
`Paging
`
`' M" '
`
`' ' é-witch. “negotiation” '” '
`
`"""Li}{k'gté.¥{ui$'WW
`
`LMP_host_connection_req
`L|'vlF'_accepted
`
`Authentication
`
`Authentication
`
`Encryption negotiation
`
`Link setup complete
`
`Figure ?. 2: Link establishment 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. 1119 p. 1129
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 8
`
`Generic Access Profile
`
`page 48 of440
`
`Bluetooth-
`
`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 (ie. 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 LMP_host_connection_req.
`When both devices are satisfied, they send LMP#setup_complete.
`
`Link establishment is completed when both devices have sent
`LM P_setup_comp|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}.
`
`7.2.2 Term on UI level
`
`'B|uetooth 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.
`
`1 December 1999
`
`Establishment procedures
`
`AFFLT0294-358
`
`Samsung Ex. 1119 p. 1130
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 49 of 440
`
`Generic Access Profiie
`
`7.2.3.1 B in security mode 2
`
`established link
`
`L2CAP_Con ne ctR eq
`
`Authentication
`
`'
`
`'
`
`'iéfi¢Eypz':§h'aé'gdi:éiibri'
`
`'
`
`'
`
`LZCAP 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 B in security mode 1 or3
`
`L2CAP_Con nectReq
`
`L2CAP ConnectRsp(+
`
`Figure 7. 4: Channei estabtishment 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 (L2CAP_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_C0nnectRsp).
`
`Establishment procedures
`
`1 December 1999
`
`AFFLT0294359
`
`Samsung Ex. 1119 p. 1131
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 8
`
`Generic Access Profile
`
`7.3 CONNECTION ESTABLISHMENT
`
`7.3.1 Purpose
`
`page 50 of440
`
`Bluetooth-
`
`The purpose of the connection establishment procedure is to establish a con-
`nection between applications on two Bluetooth devices.
`
`7.3.2 Term on Ul 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 Bin security mode 2
`
`established channel
`
`connect_est_req
`
`iiiiinenaicai-..a}.'
`
`I
`
`Encryption negotiation
`
`connec!_est_acc
`
`Figure 7.5: Connection estabiishmeni‘ procedure when the initiator {A} is in security mode 3
`and the acceptor (B) is in security mode 2.
`
`1 December 1999
`
`Establishment procedures
`
`AFFLT0294360
`
`Samsung Ex. 1119 p. 1132
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`Generic Access Profile
`
`7.3.3.2 B in security mode 1 or3
`
`page 51 of 440
`
`Bluetooth.
`
`established channel
`
`connect BS1 re
`
`connect__est_acc
`
`Figure 7.6: Connection establishment 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 protocol-dependent). This request may be a TCS SETUP mes-
`sage {5} in the case of a Bluetooth telephony application Cordiess TeEe{3?‘.t.}!':y
`ir'3".rofi:ie, or initialization of RFCOMM and establishment of DLC {4} in the case of
`a serial port-based application
`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 estabiishment 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
`
`AFFLT0294361
`
`Samsung Ex. 1119 p. 1133
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 8
`
`Generic Access Profile
`
`8 DEFINITIONS
`
`page 52 of440
`
`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.
`
`Idle 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.
`
`3.2 CONNECTION-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 ACL packets to be
`transmitted.
`
`SCO 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 alter 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. 1119 p. 1134
`
`

`
`BLUETOOTH 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 ofa connection to a Service. If not
`already done, this includes establishment ofa physical link, link and channel as
`well.
`
`8.3 DEVICE-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
`
`AFFLT0294363
`
`Samsung Ex. 1119 p. 1135
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 8
`
`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 channei.
`
`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
`
`AFFLT0294364
`
`Samsung Ex. 1119 p. 1136
`
`

`
`BLUETOOTH 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), LMP-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. 1119 p. 1137
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 8
`
`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
`
`value
`
`Tabie 9.1: Defined GAP timers
`
`.
`
`.
`
`Description
`
`Normal time span that a
`Blueteoth device performs
`inquiry.
`
`Minimum time in
`
`lNQU|RY_SCAN.
`
`Maximum time between
`
`repeated INQU lRY_SCAN
`enterings.
`
`A Bluetooth device shall
`not be in a discoverable
`
`mode less than TGAp(1D3).
`
`A Bluetooth device should
`not be in limited discover-
`able mode more than
`
`TGAp{10-4).
`
`Comment
`
`Used during inquiry and
`device discovery.
`
`A discoverable Bluetooth
`device enters
`
`INQUlRY_SCAN for at least
`TGAp{1 ) every TGAPFIO2}.
`
`Maximum value of the
`inquiry scan interval.
`
`Tiriquiry scan-
`Minimum time to be
`discoverable.
`
`Recommended upper limit.
`
`1 December 1999
`
`Annex A (Normative): 'l'imers and constants
`
`AFFLT0294366
`
`Samsung Ex. 1119 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-AUTHENTICATION
`
`The specification of authentication on link level is found in
`
`Verifier
`(initiator)
`
`Claimant
`
`inil_autheniication
`
`(link key or Kinit)
`
`{link key or Kinit)
`
`Generate
`random number
`
`|mp_au rand
`
`Calculate
`challenge
`
`Calculate
`response
`
`(ok or fail)
`
`Figure 10.1: LMP-authentication as defined by _:‘2;’.
`
`The secret key used here may be either an already exchanged link key or an
`initialization key created in the LMP—pairing procedure.
`
`Annex B (Informative): Information flows of related procedures 1 December 1999
`
`AFFLT0294367
`
`Samsung Ex. 1119 p. 1139
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 8
`
`page 58 of440
`
`Generic Access Profile
`
`10.2 LMP-PAIRING
`
`The specification of pairing on link level is found in E2}.
`
`Verifier
`
`<'“‘“a‘°'i
`
`.
`
`Generate
`random number
`
`LMP_in_rand
`LM P_acce pted
`
`Calculate Kinit
`
`Calculate Kinit
`
`|mp—authentication
`
`create link key
`
`Figure 10.2: LMP-pairing as defined in {E}.
`
`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 {.3} 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 fie-rvice E3':scov'e_.*y* .f5.ppi':r.:atic.2n ifirctiirs. This is just an example.
`
`1 December 1999
`
`Annex B (Informative): Information flows of
`
`AFFLT0294-368
`
`Samsung Ex. 1119 p. 1140
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 59 of 440
`
`Generic Access Profile
`
`initiate service discovery
`
`make connectable
`
`Link establishment
`
`C hannel establishment
`
`service discovery session '
`
`Channel release
`
`LMP detach
`
`Figure 10.3: Service discovery procedure.
`
`Annex B (Informative): Information flows of related procedures 1 December 1999
`
`AFFLT0294369
`
`Samsung Ex. 1119 p. 1141
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 8
`
`page 60 of440
`
`Generic Access Profile
`
`11 REFERENCES
`
`[1] Bluetooth Baseband Specification
`
`[2] Bluetooth Link Manager Protocol
`
`[3] Bluetooih Logical Link Control and Adaptation Protocol
`
`[4] Bluetooih RFCOMM
`
`[5] Bluetooth Telephony Control Specification
`
`[6] Bluetooth Service Discovery Protocol
`
`[Y] Bluetooth Service Discovery Application Profile
`
`[8] Bluetooth Cordless Telephony Profile
`
`[9] Bluetooth Serial Port Profile
`
`[10] Bluetooth Security Architecture (white paper)
`
`[11] Bluetooth Assigned Numbers
`
`1 December 1999
`
`References
`
`AFFLT0294370
`
`Samsung Ex. 1119 p. 1142
`
`

`
`SERVICE DISCOVERY
`PLICATION PROFILE
`
`%
`
`This %ocum nt defines the features and proce-
`' dureg for an pplication in a Bluetooth device
`avgilable igirmation pertinent to these
`§
`services.
`3
`5‘
`
`to di_ cover gervices registered in other
`Bluétooth
`vices and retrieve any desired
`
`AFFLT0294371
`
`Samsung Ex. 1119 p. 1143
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 8
`
`page 62 of-440
`
`Service Discovery Appiicarion Profiie
`
`1 December 1999
`
`AFFLT0294372
`
`Samsung Ex. 1119 p. 1144
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 63 of 440
`
`Service Discovery Application Profiie
`
`CONTENTS
`
`imrcsziuctimz ......................
`
`.................
`
`.........................
`
`.......
`
`..... £5
`
`1.’!
`
`1.12
`
`SjE"1'}b£.'!!55 and
`
`Frefiie
`
`2.1
`
`P:-sfiie stack
`
`Clonféguratians and roies
`User requéri-amerris and scenarios;..............................................?'{}
`Pro'Eie §Lenda=.n'1erataEs
`
`Corsformarzce ........................................................................... .71’?
`
`2.3
`2.4
`
`2.5
`
`1.5553“ interface aspects
`
`3:3
`3.2
`
`Appiicatian Eager
`
`4.1
`51.2
`
`The service ciéscovery angsiicaiion ............................................ ..'/'3
`Service p:‘irr*:i:ive3 a?}st{a<3f.':or1s ................................................. ..?5
`
`4.3 Message .<.=.ec;uer'::';=a charts {MESSCS} .......................................... .. ?’?’
`
`Service Biscmrery
`
`5.1
`
`An SDE3 PDQ exchange exampie...............................................8G
`
`LECAP ...............................................................
`
`.........
`
`................. "82
`
`8.1
`
`8.2
`
`53.3
`
`Charms} types .......................................................................... ..83
`
`Ségnaiiing ................................................................................. . .83
`
`Cc:r§"aguration options ...............................................................
`6.3.": Maximum Transmission Unit (MR
`6.3.2
`Finish Time--out
`
`Ciuaiéiy of Service ........................................................ "84
`6.3.3
`SDF‘ iransacfions and LECAF’ cormeciion fifetérrae ................... ..8c$
`
`6.4
`
`Link Manager
`
`7.1
`7.2
`
`"/13
`
`Link
`
`8.?
`
`8.2
`
`8.3
`
`8.5
`8.5
`
`Capabiééty
`3’.-"zrrrar
`
`Link poiicy
`
`Capability over*¢'iew .................................................................. ..88
`
`}na_L:§ry ...................................................................................... ..é"sS3
`
`inmziry scan .............................................................................. ..9{}
`
`Page scan ................................................................................ ..‘S3G
`Errcr behavior‘ .......................................................................... ..9G
`
`1 December 1999
`
`AFFLTD294373
`
`Samsung Ex. 1119 p. 1145
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 8
`
`page 64of440
`
`Service Discovenr Application Profile
`
`9
`
`9.1
`
`N<'>rmat€'v'erefer‘en:;es..................................................................91
`
`i)efmat§xms
`
`Agpenciix A éfinfarmative}: fiervica primitives and the
`Eiuataaath
`
`1 December 1999
`
`AFFLT0294374
`
`Samsung Ex. 1119 p. 1146
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 65 of 440
`
`Service Discovery Application Profiie
`
`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 (generaiiy termed capabiiifies) 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. 1119 p. 1147
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 8
`
`Service Discovery Application Profile
`
`1
`
`INTRODUCTION
`
`1.1 SCOPE
`
`page 66 of 440
`
`Bluetooth-
`
`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:{?} 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