BLUETOOTH SPECIFICATION Version 1.0 8
`
`Service Discovery Appiication Profiie
`
`page 74 of440
`
`Bluetooth-
`
`In the first two alternatives, page, link creation, and service discovery are done
`sequentially on a per RemDev basis; i.e., the LocDev does not page any new
`RemDev prior to completing the service search with a previous RemDev and (if
`necessary) disconnecting from it. In the last alternative (SrvDsoApp_C), the
`LocDev, under the control of the SrvDscApp. will first page all RemDevs, then
`will create links with all of these devices (up to a maximum of 7 at a time), and
`then inquire all the connected devices for the desired services.
`
`Just as an example, we focus on a SrvDscApp similar to the one represented
`by the SrvDscApp_A in Figure 4.1. In summary, SrvDscApp (for ease of nota-
`tion, the suffix '_A' has been dropped) has the following features:
`
`- The SrvDscApp activates Bluetooth inquiries following a user request for a
`service search,
`
`For any new RernDev found following an inquiry, the SrvDscApp will finish
`service discovery and terminate its link against this device prior to attempt-
`ing to connect to the next RemDev,
`
`For any RemDev already connected, the LocDev does not disconnect fol-
`lowing service discovery, and
`
`The user of the SrvDscApp has the option of a trusted and untrusted mode
`of operation, whereby the SrvDscApp permits connections —
`
`a) only with trusted RemDev, or
`
`b) with any of the devices above plus any newly discovered
`RemDevs that require nothing more beyond possibly pairing with
`the default all-zero PIN, or
`
`c) with any of the devices above, plus any additional RemDev for
`which the user explicitly enters a non-zero PIN.
`
`The above options have to do with the degree of user involvement in configur-
`ing and interacting with the SrvDscApp and setting the security levels that the
`user is willing to accept for the service searches. When selecting options (a) or
`(b), then for the devices with which no legitimate connections can be estab-
`lished, it is assumed that the SrvDscApp ignores them without any cue to its
`user (however, this too is an implementation issue).
`
`When a LocDev performs a service discovery search, it does so against three
`different types of RemDevs:
`
`1. trusted devices: These are devices that are currently not connected with the
`LocDev but the LocDev device has already an established trusted relation
`with.
`
`. unknown (new) devices: These are untrusted devices that are currently not
`connected with the LocDev.
`
`. connected devices.’ These are devices that are already connected to the
`LocDev.
`
`1 December 1999
`
`Application layer
`
`AFFLT0294-334
`
`Samsung Ex. 1019 p. 1156
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 75 of 440
`
`Service Discovery Appiication Profiie
`
`To discover type 1 or 2 RemDevs, the SrvDscApp needs to activate the
`Bluetooth inquiry andior page processes. For type 3 RemDevs, the latter pro-
`cesses are needed. To perform its task, SrvDscApp needs to have access to
`the BD_ADDR of the devices in the vicinity ofa LocDev, no matter whether
`these devices have been located via a Bluetooth inquiry process or are already
`connected to the LocDev. Thus, BT_module_Cntr in a LocDev shall maintain
`the list of devices in the vicinity of the LocDev and shall avail this list to the
`SrvDscApp.
`
`4.2 SERVICE PRIMITIVES ABSTRACTIONS
`
`This section briefly describes the functionality of a SrvDscApp. This functional-
`ity is presented in the form of service primitive abstractions that provide a for-
`mal framework for describing the user expectations from a SrvDscApp. It is
`assumed that the underlying Bluetooth stack can meet the objectives of these
`service primitive abstractions directly or indirect|y.5 The exact syntax and
`semantics of the service primitive abstractions (or simply "service primitives")
`may be platform-dependent (e.g. an operating system, a hardware platform,
`like a PDA, a notebook computer, a cellular phone, etc.) and are beyond the
`scope of this profile. However, the functionality of these primitives is expected
`to be available to the SrvDscApp to accomplish its task.
`
`Tsbie -iii contains a minimum set of enabling service primitives to support a
`SrvDscApp. Low-level primitives like openSearch(.) or c|oseSearch(.) are not
`shown and are assumed to be part of the implementation of the primitives
`shown whenever necessary. Different implementations of the Bluetooth stack
`shall (at a minimum) enable the functions that these service primitives provide.
`For example, the serviceSearch(.) service primitive permits multiple identical
`operations to be handled at once. A stack implementation that requires an
`application to accomplish this function by iterating through the multiple identical
`operations one-at-a-time will be considered as enabling the function of this ser-
`vice primitive? The service primitives shown next relate only to service primi-
`tives whose invocation result or relate to an over-the-air data exchange using
`the Bluetooth protocols. Additional service primitives can be envisioned relat-
`ing to purely local operations like service registration, but these primitives are
`outside the scope of this profile.
`
`. These service primitive abstractions do not represent programming interfaces. even though
`they may be related to them. The word ‘direct|y‘ is used to describe the possibility that the
`described function is the result of a single appropriate call of the underlying Bluetooth stack
`implementation. The word ‘indirectly’ is used to describe the possibility that the described
`function can be achieved by combining the results from multiple appropriate calls of the
`underlying Bluetooth stack implementation.
`. Even though the service primitives presented in this profile are assumed to act upon a local
`device for accessing physically remote devices, they are general enough to apply in cases
`where the ‘remote device‘ characterization is only a logical concept; i.e. inquired service
`records and service providers are located within the same device that invokes these primi-
`tives. This general situation is outside the scope of this profile.
`
`Application layer
`
`1 December 1999
`
`AFFLT0294-385
`
`Samsung Ex. 1019 p. 1157
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 8
`
`Service Discovery Application Profile
`
`page 76 of 440
`
`Bluetooth-
`
`semce Fflmmve
`abstraction
`
`serviceBrowse
`
`{LlST( Remflev)
`LIST( RemDevRe-iation )
`LIST( browseemup )
`getRemDevName
`stopRuie)
`
`servlcesearch
`(LlST( Rernoev J
`LlST( RemDevReiation }
`LlST( searchPattern,
`attributeust )
`gerRamDe vName
`stopRuie}
`
`en ume rate Rernflev
`(LIST( ciassOfDevice )
`stopRuie}
`
`terminate!‘-‘rimitlve
`
`{primitiveHandle
`return.-Qesuits)
`
`resulted action
`
`a search for services {service browsing) that belong to the
`list of browseGnoup services in the devices in the list of
`RemDevs: the search may be further qualified with a list of
`RemDevReiation parameters, whereby a user specifies
`the trust and connection relation of the devices to be
`
`searched; e.g. search only the devices that are in the Ram-
`Dev list for which there is a trust relation already estab-
`lished; when the gerRemDevName parameter is set to
`"yes," the names of the devices supporting the requested
`services are also returned; the search continues until the
`stopping rule stopRuie is satisfied
`
`a search whether the devices listed in the list of Remflevs
`
`support services in the requested list of services; each ser-
`vice in the list must have a service search pattern that is a
`superset of the searchPattern; for each such service the
`values of the attributes contained in the corresponding
`attributetist are also retrieved: the search may be further
`qualified with a list of RemDevRelatiori parameters,
`whereby a user specifies the trust and connection relation
`ofthe devices to be searched {e.g. search only the devices
`thatare in the Rem.-Devlist for which there is a trust relation
`already established); when the getRemDevName parame-
`ter is set to “yes," the names of the devices supporting the
`requested services are also returned; the search continues
`until the stopping rule sfopRuie is satisfied
`
`a search for RemDev in the vicinity of a LocDev; RemDev
`searches may optionally be filtered using the list of clas-
`sOfDevice (e.g. LAN APs); the search continues until the
`stopping rule stopRule is satisfied
`
`a termination the actions executed as a result of invoking
`
`the services primitive identified by the prirnitivel-iandlef
`optionally, this service primitive may return any partially
`accumulated results related to the terminated service
`
`primitive
`
`Table 4.1: Service primitives in support of SrvDscApp
`ii
`
`.
`
`It is assumed that each invocation of a service primitive can be identified by a primi-
`tiveHano'ie, the realization of which is implementation-dependent.
`
`The stopRuie parameter is used to guarantee a graceful termination of a ser-
`vice search. It could represent the number of search items found, or the dura-
`tion of search, or both. A Bluetooth stack implementation may not expose this
`parameter, in which case it should provide guarantees that all searches termi-
`nate within a reasonable amount of time, for example, say, 120sec.
`
`1 December 1999
`
`Application layer
`
`AFFLT0294-386
`
`Samsung Ex. 1019 p. 1158
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 77 of 440
`
`Service Discovery Application Profile
`
`The enumerateRemDev(.) service primitive is directly related to the inquiry
`mode of operation for the baseband. It also relates to the collection of RemDev
`that a LocDev is currently connected with. This service is exported to the SrvD-
`scApp via the BT_modu|e_Cntr, see Figure
`The interface between
`BT_modu|e_Cntr and baseband is for activating Bluetooth inquiries and col-
`lecting the results of these inquiries. The interface between the
`BT_modu|e_Cntr| and (an) L2CAP (implementation) is for keeping track of the
`RemDev that currentty are connected to the LocDev.
`
`The result of the enumerateRemDev(.) service primitive can be used with the
`serviceSearch(.) to search for desired services in the devices found. Once
`again, based on the implementation of the Bluetooth stack, this service primi-
`tive may not be provided explicitly, but its service may be provided within other
`service primitives; e.g. the serviceSearch(.).
`
`Missing primitive parameters shall be interpreted (whenever appropriate) as a
`general service search on the remaining parameters. For example, if the
`LIST( RemDev ) parameter is missing from the serviceSearch(.), it means that
`the search shall be performed against any device found in the vicinity of a
`LocDev. In this case, the first two service primitives may be combined to a
`single one.
`
`The above service primitives return the requested information, whenever
`found. Based on the way that these service primitives are supported by a Blue-
`tooth stack implementation, the results of a search may directly return by the
`corresponding calling function, or a pointer to a data structure may be returned
`that contains all the reievant information. Alternatively, a Bluetooth stack imple-
`mentation may have altogether different means for providing the results of a
`search.
`
`4.3 MESSAGE SEQUENCE CHARTS (MSCS)
`
`This profile is concerned with three distinct Bluetooth procedures. Device dis-
`covery, device name discovery, service discovery. Note that each one of these
`procedures does not preclude any other; e.g. to connect to a RemDev, a
`LocDev may have to first discover it, and it may also ask for its name. The
`MSCS relating to the first two procedures (i.e., device and name discovery) are
`provided in section 2 of LMl'HCl_MSCs:{ES}. Sections 3, 4.1 and 4.2 of
`Llv‘|iHC|_lv1SCs:§'t3§ provide the MSCs relating to the third procedure (i.e., ser-
`vice discovery). See also section 4 of BT_LM_spec:§-"«.ri. The first two proce-
`dures do not require host intervention, while the third does.
`
`§-"-sgLi!'€~? 4.2 summarizes the key message exchange ‘phases’ encountered dur-
`ing the execution of this profile. Not all procedures are present at all times, and
`not all devices need to go through these procedures all the time. For example,
`if authentication is not required, the authentication phase in the figure will not
`be executed. If the SrvDsvApp needs to inquire for services on a specific
`RernDev with which the LocDev is currently connected, inquiries and pages
`
`Application layer
`
`1 December 1999
`
`AFFLT0294-387
`
`Samsung Ex. 1019 p. 1159
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 78 of440
`
`Service Discovery Application Profile
`
`may not be executed. In the figure, the conditions under which particular
`phases are executed or not are also provided.
`
`i'-517'|“- NV‘;
`L-"-F’
`LM? .".':Ie res
`4'
`
`I
`
`needed only when
`J'ur_;u:'rJ':uc_.n .r§minsr.
`nun - .-:mm..-<:a'.exf rlorvf ::r:.d
`
`.'Jcr-dd! ordy m".c'n
`the use:'- £'r1'9ndl_v norm.‘
`.
`.
`.
`or .1 device 1:‘ r<:quJrcd
`needed cnl y when
`I riqiri ri Jig rrgu; l'1a=L
`.'1cr- :onne-:I:¢u' dev: :95
`n..-c-dz:-.-l
`/sruiy whrrn n-:::ir:'r.y ra.-:,1u|'r-.--m.-nrir
`u‘ic..-L.-u.;: ea :'im.‘.'::dc.-.-e p.u'r:'r-.n_.z.
`.!ULi:-\.'.'JL |'e:cu:.icn::
`5 z.'nr.~.:ypJ'.i'r)r-.
`.u-
`r:-L-zrrfcdl
`.':«:c_~dc:'.l only Ir.‘:r_-n 1.-iv.‘-luvs!
`tnIni.=.:-..~:ir.':I'rs
`S
`.'u.-gut I'.:i'I<>ns :..u'u- p.:‘.u-.r-
`:'rmr
`eriirxwul
`
`.f.2£.'Ar" ¢.‘S.)~It:Jr.‘n'_‘I'.IurJ
`.m SIJ1" wJJ'«::Ir.
`.-mu‘
`.m .‘iIJJ'-' xcr w-r
`
`1'-mt-r nu.-..-u
`
`i: am 2' na I: e an y
`canrzcc I: 1' on 5/1 5 n its
`as needed
`
`Figure 4.2: Biueiooth processes in support of this profile
`
`In addition to the MSC in Figure 4.2, Annex A shows what Bluetooth proce-
`dures and PDUs are needed to support the service primitives presented in
`Section vi
`
`1 December 1999
`
`Application layer
`
`AFFLT0294-388
`
`Samsung Ex. 1019 p. 1160
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 79 of 440
`
`Service Discovery Application Profile
`
`5 SERVICE DISCOVERY
`
`The service discovery application does not make use of SDP as a means of
`accessing a service, but rather as a means of informing the user of a LocDev
`about the services that are available to hisiher device by (and possibiy via)
`RernDev(s). BT-aware applications running in a local device can also use the
`procedures described in this and the following sections to retrieve any pertinent
`information that will facilitate the application in accessing a desired service in a
`remote device.
`
`‘fable 5.“: shows the SDP feature requirements in a LoCDev and in a RemDev.
`
`IS
`
`DP client
`
`Tabie 5.1: SDP feature requirements
`
`mere 5.2 shows the SDP PDUS can be exchanged between devices following
`this profile.
`
`Ability to Send
`
`Ability to Receive
`
`LocDev
`
`RernDev
`
`LocDev
`
`RemDev
`
`SDP_ErrorResponce
`
`SDP_ServiceSearchRequest
`
`SD P__ServioeSea rch Response
`
`SDP_ServiceA£tributeRequest
`
`SDP_ServiceAttributeResponse
`
`SDPWServiceSearchAttributeRequest
`
`SDP_ServioeSearchAtiributeResponse
`Comments:
`
`C1
`
`M
`
`C1
`
`M
`
`C1
`
`M
`
`C1
`
`M
`
`C1
`
`M
`
`C1
`
`M
`
`C1
`
`M
`
`M
`
`C1
`
`M
`
`C1
`
`M
`
`C1
`
`M
`
`01
`
`M
`
`C1
`
`M
`
`01
`
`M
`
`C1
`
`{C1}: With regard to this current profile. these PDU transmissions will not occur. Neverthe-
`less, since a device could act as a LccDev on some occasions and as a RemDev on others,
`these PDU transmission may still take place between these devices.
`
`Tabie 5.2: Allowed SDP PDUs
`
`Service Discovery
`
`1 December 1999
`
`AFFLT0294-389
`
`Samsung Ex. 1019 p. 1161
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 8
`
`page 80 of440
`
`Service Discovenr Application Profile
`
`5.1 AN SDP PDU EXCHANGE EXAMPLE
`
`Figtsre 5.1 shows two examples of SDP PDU exchanges. In particular, it shows
`PDU exchange sequences for the inquiry and retrieval of any information perti-
`nent to a particular Bluetooth profile.
`
`3-DP_fl9t'V1f-'039a1'€hR0qif
`
`4; ,
`" i"
`'
`
`_
`" "'
`
`‘
`
`,
`
`::r
`
`r:.'.'Jr'-'-Hlc.-¥'r.'{
`re E-.-. xvi‘.
`'..='..".=..-
`
`r.-.-=:;ri:I_l{==.".r1IcnL Oi L23‘.-LI"
`for .-'5'!‘
`
`-:o:i.'..:-rt;-"c.-:i
`
`mi.‘ c[
`‘i.
`I,
`
`.-3nP_.a:v1ca.A:::n:u:eizeqr,.
`
`..,..
`
`-.,,
`
`,.
`--"'---
`
`.-
`-‘
`
`-.
`'
`
`ED:-'___nrv.tc.s..n-cuts;-at '
`-m.n.-..r-.a,- ..-{
`-::..i! :.=|;.
`'
`.3‘. Lr ‘.::u_-.:_'..'
`I
`
`.2‘:-1
`
`:
`
`Figure 5.1: SDP PDU exchange exampies for retrieving pmtocolflescrfptorfists
`
`For each PDU sent, the figure shows which device sends it (shown on the
`starting side of an arrow) and any relative information that this PDU carries
`(shown on the ending side of an arrow). Note that the LocDev sends request
`PDUs, while the RemDev sends back response PDUs.
`
`Two alternatives are shown utilizing different SDP PDUs to ultimately retrieve
`the same information — the protocci‘DescriptorList attribute from devices that
`support a specific Bluetooth profile. With the first alternative, the desired infor-
`mation is derived in two steps.
`
`- The LocDev sends an SDP_serviceSearchReq PDU which contains a ser-
`vice search pattern composed of the UUID associated with the desired pro-
`file; see section 4.3 of BT_ASN:{2§. The desired profile (profile 'XYZ') is
`identified by its UUID, denoted in the figure as 'profiie_XYZ_UU|D.‘ In its
`response PDU. the SDP server returns one or more 32-bit service record
`handles whose corresponding service records contain the
`'profiIe_XYZ_UU|D' UUID. In the figure. only one such handle is shown,
`denoted as 'prHnd|'.
`
`The LocDev then enters prHnd| in an SDP_serviceAttribute PDU together
`with one or more attribute IDS. In this example, the attribute of interest is the
`
`‘I December 1999
`
`Servicetiisoovery
`
`AFFLT0294390
`
`Samsung Ex. 1019 p. 1162
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 81 of 440
`
`Service Discovery Application Profile
`
`protocoiDescripton'_ist. whose attribute ID is OXODO4. The SDP server then,
`in its response, returns the requested protocol list.
`
`In the event that no service record containing the desired service search pat-
`tern is found in the SDP server, the SDP_serviceSearchResp PDU will contain
`an empty serw'ceRecordHandieList and a totaiServiceRecordCount parameter
`set to its minimum value; see section 4.5.2 of BT_SDP_spec:§j‘i}.
`
`If the desired attributes do not exist in the SDP server, the
`SDP_serviceAttributeResp PDU will contain an empty attributetist and an
`attn'buteListByfeCount parameter set to its minimum value, see section 4.6.2 of
`BT_SDP_spec:{?‘j.
`
`With the second alternative, the desired attributes are retrieved in one step:
`
`- The LocDev sends an SDP_serviceSearchAttributeReq PDU where both
`the desired profile is included (service search pattern: profile_XYZ_UU|D)
`and the desired attribute(s) is provided (attribute ID: OXOOO4). in its response
`the SDP server will provide the requested attribute(s) from the service
`record(s) that matches the service search pattern.
`
`in case no service record containing the desired service search pattern andior
`the desired attribute(s) is found in the SDP server, the
`SDP_serviceSearchAttrfbuteResp PDU will contain an empty attributetists and
`an atfn'buteListsByteCount parameter set to its minimum value, see section
`4.7.2 of BT_SDP_spec:i?'}.
`
`While, in the example in Figgure 5.1, only very few service attributes are shown
`retrieved by the SDP client, additional information Could and should be
`requested. Particularly in cases where service information is to be cached for
`future use, an SDP client should also request any pertinent information that
`can aid in assessing whether cached information has become stale.
`The service attributes serviceDatabaseState. serviceRecoro'State, and
`serviceinfoi"imeToi_r've have been defined for this purpose in
`BT_SDP_spec:E?}; see sections 5.2.4. 5.1.3 and 5.1.8 respectively.
`
`Service Discovery
`
`1 December 1999
`
`AFFLT0294391
`
`Samsung Ex. 1019 p. 1163
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 8
`
`page 82 of440
`
`Service Discovery Appiicat.-‘on Profits
`
`6 LZCAP
`
`The following text, together with the associated subclauses, defines the man-
`datory requirements with regard to this profile.
`
`LZCAP procedure
`
`Support in LocDev
`
`Support in RemDev
`
`Channel types
`
`Connection-oriented channel
`
`Connectionless channel
`
`Signaiiing
`
`Connection Establishment
`
`Configuration
`
`Connection Termination
`
`Echo
`
`Command Rejection
`
`Configuration Parameter Options
`Maximum Transmission Unit
`
`Flush Time-out
`
`Quality of Service
`
`Comments:
`
`[X1]: This feature is not used in this profile. but its use by other applications running
`simultaneously with this profile is not excluded.
`
`[C1]; An SDP server shall not (and cannot) initiate an LZCAP connection for SDP
`transactions. Nevertheless, the device that the SDP server resides in may also have an
`SDP client that may initiate an L2CAP connection for SDP transactions. Such action does
`not contradict the execution of this profile. In any case. a RemDev shall be able to process
`incoming requests for connection establishment.
`
`[C2] Under normal operation. an SDP server shall not initiate the process of terminating an
`LZCAP oonnection for SDP. However. exceptional cases, such as when a RemDev shuts
`down during the execution on an SDP transaction, cannot be excluded. In such a case, prior
`to the final power-off, the RemDev may gracefully (or not!) terminate all its active LZCAP
`connections by sending connection termination PDUs. in any case. a RemDev shall always
`be able to process incoming requests for connection termination.
`
`Tabie 6.1:
`
`i_2CAP procedures
`
`1 December 1999
`
`AFFLT0294392
`
`Samsung Ex. 1019 p. 1164
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 83 of 440
`
`Service Discovery Application Profile
`
`6.1 CHANNEL TYPES
`
`In this profile, only connection-oriented channels shall be used. In particular, no
`L2CAP broadcasts are to be used for this profile.
`
`6.2 SIGNALLING
`
`For the purpose of retrieving SDP-related information, only a LocDev can
`initiate an LZCAP connection request and issue an L2CAP connection request
`PDU; for exceptions. see comments C1 and C2 on Tania 5. '5. Likewise with the
`corresponding L2CAP connection terminations. and the same exceptional
`comments C1 and C2 on ‘fat:-le 6.’: apply. Other than that, SDAP does not
`impose any additional restrictions or requirements on LZCAP signalling.
`
`In the PSM fieid of the Connection Request packet, the value 0x0001 (see sec-
`tion 5.2 of BT_L2CAP_spec:{fi,?) shall be used to indicate the request for
`creation of an L2CAP connection for accessing the SDP layer.
`
`6.3 CONFIGURATION OPTIONS
`
`This section describes the usage of configuration options in the service
`discovery profile.
`
`6.3.1 Maximum Transmission Unit (MTU)
`
`This profile does not impose any additional restrictions to MTU beyond the
`ones stated in section 6.1 of BT_L2CAP_spec:§5§. If no MTU negotiation takes
`place, the default MTU value in section 6.1 of BT_L2CAP_spec:{5ji shall be
`used.
`
`For efficient use of the communication resources, the MTU shall be selected as
`
`large as possible, while respecting any physical constraints imposed by the
`devices involved, and the need that these devices continue honoring any
`already agreed upon Q03 contracts with other devices andior applications. It is
`expected that during the lifetime of an L2CAP connection for SDP transactions
`(also referred to as the ‘SDP session‘, see Efiecticn 8.4) between two devices,
`any one of these devices may become engaged in an L2CAP connection with
`another device andior application. if this new connection has ‘non-default’ Q08
`requirements, the MTU for the aforementioned SDP session is allowed to be
`re-negotiated during the lifetime of this SDP session, to accommodate the Q08
`constraints of the new L2CAP connection.
`
`6.3.2 Flush Time-out
`
`The SDP transactions are carried over an LZCAP reliable channel. The flush
`
`time-out value (see section 6.2 of BT_L2CAP_spec:§5:E) shall be set to its
`default value 0xFFFF.
`
`1 December 1999
`
`AFFLT0294393
`
`Samsung Ex. 1019 p. 1165
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 8
`
`Service Discovery Application Profile
`
`6.3.3 Quality of Service
`
`page 84 of 440
`
`Bluetooth-
`
`The use of Quality of Service (Q03) and QoS negotiation is optional. if (103 is
`to be negotiated, the default settings in section 6.4 of BT_L2CAP_spec:i_5}
`shall be used. In particular, SDP traffic shall be treated as a best-effort service
`type trafiic.
`
`6.4 SDP TRANSACTIONS AND L2CAP CONNECTION
`LIFETIME
`
`While, in general, SDP transactions comprise a sequence of service request-
`and-response PDU exchanges, SDP itself constitutes a connectionless
`datagram service in that no SDP-level connections are formed prior to any
`SDP PDU exchange. SDP delegates the creation of connections on its behalf
`to the L2CAP layer. It is thus the responsibility of SDP — or, more correctly, of
`the SDP layer — to request the LZCAP layer to ‘tear down‘ these connections
`on its behalf as well.
`
`Since SDP servers are considered stateless. ‘tearing down’ an LZCAP connec-
`tion after a service request PDU is sent (as a true connectionless service may
`imply) will be detrimental to the SDP transaction. Moreover, significant perfor-
`mance penalty will have to be paid if, for each SDP PDU transmission, a new
`LZCAP connection is to be created. Thus, LZCAP connections for SDP trans-
`
`actions shall last more than the transmission of a single SDP PDU.
`
`An SDP session between an SDP client and an SDP server represents the
`time interval that the ciient and the server have the same L2CAP connection
`
`continuously present. A n1inimaiSDP transaction will represent a single
`exchange of an SDP request PDU transmission from an SDP client to an SDP
`server, and the transmission of a corresponding SDP response PDU from the
`SDP server back to the SDP client. With respect to this profile, under normal
`operational conditions, the minimum duration of an SDP session shall be the
`duration of a minimal SDP transaction.
`
`An SDP session may last less than the minimum required in the event of unre-
`coverable (processing or link) errors in layers below SDP in the LocDev and
`RemDev, or in the SDP layer and the service records database in the RemDev.
`An SDP session may also be interrupted by user intervention that may termi-
`nate the SDP session prior to the completion of an SDP transaction.
`
`The above minimum duration of an SDP session guarantees smooth execution
`of the SDP transactions. For improved performance, implementers may allow
`SDP sessions to last longer than the minimum duration of an SDP session. As
`a general implementation guideline, an SDP session shall be maintained for as
`long as there is a need to interact with a specific device. Since the latter time is
`in general unpredictable, SDP implementations may maintain timers used to
`time periods of SDP transaction inactivity over a specific SDP session.
`
`1 December 1999
`
`AFFLT0294394
`
`Samsung Ex. 1019 p. 1166
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 85 of 440
`
`Service Discovery Application Profile
`
`SDP implementations may also rely on explicit input received from a higher
`layer (probably initiated from the SrvDscApp itself) to open and close an SDP
`session with a particular device using low level primitives; e.g. openSearch(.)
`and cIoseSearch(.). Finally. an implementation may permit users to interrupt
`an SDP session at any time. see the terminatePrimitive(.) service primitive in
`Easotion e$.2.
`
`Normally, an SDP session shall not terminate by a RemDev. Yet, such an event
`can indeed occur, either having the RemDev gracefully terminating the SDP
`session, using the L2CAP connection termination PDU, or abnormally termi-
`nating the SDP by stopping responding to SDP requests or L2CAP signalling
`commands. Such an event may be an indication of an exceptional condition
`that SDP clientiserver implementers should consider addressing for the
`smooth execution of this profile. If a termination event initiates from a RemDev,
`an SDP client may want to consider clearing any information obtained by this
`RemDev. Such an exceptional event may imply that the SDP server has (or is
`about to) shut-down, in which case any service information retrieved from this
`server should automatically become stale.
`
`1 December 1999
`
`AFFLT0294395
`
`Samsung Ex. 1019 p. 1167
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 8
`
`Service Discovery Application Profile
`
`7 LINK MANAGER
`
`7.1 CAPABILITY OVERVIEW
`
`page 86 of 440
`
`Bluetooth-
`
`In this section, the LMP layer is discussed. In the table below. all LMP features
`are listed. The table shows which LMP features are mandatory to support with
`respect to this service discovery profile, which are optional and which are
`excluded. The reason for excluding features is that they may degrade opera-
`tion of devices in this use case. Therefore, these features shall never be acti-
`
`vated by a unit active in this use case.
`
`If any of the rules stated below are violated, the units shalt behave as defined
`in Section ?’.2.
`
`Traffic generated during service discovery interactions has no particular Q03
`requirements. As such, no particular provision of the Bluetooth link is required
`to support this profile.
`
`Lllll Procedure
`
`—|.
`
`Authentication
`
`Support in
`LMF
`
`Pairing
`
`Change link key
`
`Change the current link key
`
`Encryption
`
`Clock offset request
`
`Timing accuracy information request
`
`LMP version
`
`8 u ppo rted features
`
`Switch of master slave role
`
`Name request
`
`Detach
`
`Hold mode
`
`Sniff mode
`
`Park mode
`
`Power control
`
`F59°."*'53".‘-"':"‘:I-“P-"'.’\’
`
`—L 53
`
`—\ —L
`
`—L N
`
`—L 9°
`
`—|. P
`
`3
`
`Tabie ?.‘.|‘: LMP procedures
`
`OOOEZZOEEOZOEZZE
`
`1 December 1999
`
`Link Manager
`
`AFFLT0294396
`
`Samsung Ex. 1019 p. 1168
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 87 of 440
`
`Service Discovery Application Profile
`
`LM Procedure
`
`Eagpofl in
`
`Channel quality driven DMIDH
`
`Quality of service
`
`SCO links
`
`Control of multi-slot packets
`
`Concluding parameter negotiation
`
`Host connection
`
`Comments:
`
`[C1] No authentication or encryption is required specificaily by this profile. This profile will.
`however. not attempt to change the existing operational settings for these procedures.
`Nevertheless, when this profile is executed all by itself, the default operational settings are:
`- authentication: no active
`
`- encryption: no active
`In the latter case. a LocDev will always comply with the security requirements imposed by a
`RemDev. If it cannot comply. it will bypass the RemDev.
`
`{X1}: This feature is not used in this profile. but its use by other applications running simulta-
`neously with this profile is not excluded.
`
`Table 7.1: LMP procedures
`
`7.2 ERROR BEHAVIOR
`
`if a unit tries to use a mandatory feature. and the other unit replies that it is not
`supported, the initiating unit shall send an LMP_detach PDU with detach rea-
`son "unsupported LMP feature."
`
`A unit shall always be able to handle the rejection of the request for an optional
`feature.
`
`7.3 LINK POLICY
`
`There are no fixed master-slave roles for the execution of this profile.
`
`This profile does not state any requirements on which low-power modes to use,
`or when to use them. It is up to the Link Manager of each device to decide and
`request special link features as seen appropriate.
`
`Link Manager
`
`1 December 1999
`
`AFFLT0294397
`
`Samsung Ex. 1019 p. 1169
`
`

`
`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. 1019 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 th