BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 321 of 1082
`
`Logical Link Control and Adaptation Protocol Specification
`
`uetooth.
`
`APPENDIX B: IMPLEMENTATION GUIDELINES
`
`This section contains some guidelines for implementations. These guidelines
`are not part of the compliance tests. At the moment they are simply sugges-
`tions on how to solve some difficult problems.
`
`RTX TIMER
`
`implementations should not start this timer on an L2CAP Connection Request
`packet unless the physical link has been established. Otherwise the Baseband
`paging mechanism might increase the cost of the request beyond that of the
`minimal timeout value. If an implementation performs some form of security
`check it is recommended that the connection pending response he sent back
`prior to any consultation with a security manager that might perform Baseband
`authentication commands. If any security check requires user interaction, the
`link might timeout waiting for the user to enter a PIN.
`
`Q03 MAPPING TO LM AND LZCAP IMPLEMENTATIONS
`
`Token Rate
`
`The Link Manager (LM) should ensure data is removed from the transmission
`buffer at this rate. The LM should ensure the polling interval is fast enough to
`support this data rate. The polling interval should be adjusted if the packet type
`changes. If the buffer overflows, and the service type is Guaranteed, a Q08
`violation should be reported. If the service type is Best Effort. and a Token Rate
`was non-zero, a Q08 violation should also be reported.
`
`Given a Token Rate of UXFFFFFFFF, and Service Type of Guaranteed, the LM
`should refuse any additional connections from remote devices and disable all
`periodic scans.
`
`Token Bucket Size
`
`L2CAP implementations should ensure that a buffer meeting the size request
`is allocated for the channei. If no buffer is available. and the service type is
`Guaranteed. the request should be rejected. If no appropriately sized buffer is
`available, and the service type is Best Effort, the largest available buffer should
`be allocated.
`
`Peak Bandwidth
`
`if the token bucket buffer overflows, a Q03 violation should be raised.
`
`29 November 1999
`
`AFFLT0293549
`
`Samsung Ex. 1119 p. 321
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 8
`
`Logicat Link Controi and Adaptation Protocol Specification
`
`page 322 of €882
`
`Bluetooth-
`
`Latency
`
`The LM shouid ensure the polling interval is at least this value. If the polling
`interval necessary to support the token rate is less than this value, the smaller
`interval should be used. If this interval cannot be supported, a Q08 violation
`should be raised.
`
`Delay Variation
`
`The LM may ignore this value because there is no clear mapping between
`LZCAP packet delays and the necessary polling interval without requiring the
`LM to comprehend the length field in L2CAP packets.
`
`COLLISION TABLES
`
`Current Value
`
`Requested Value
`
`X
`
`Y
`
`X
`
`If (X < Y} then X. else Y
`
`Table ii.’ Resuit of Second Flush Timeout Request
`
`29 November 1999
`
`AFFLT0293550
`
`Samsung Ex. 1119 p. 322
`
`

`
`E
`This %ecifica on defines a protocol for locating ser-
`lCeo%l|'OVide by oravailablethrough a Bluetooth
`
`AFFLT0293551
`
`Samsung Ex. 1119 p. 323
`
`

`
`BLUETOOTH SPECEFICATION Version 1.0 8
`
`page 324 of €332
`
`Service Discovery Protocol
`
`29 November 1999
`
`AFFLT0293552
`
`Samsung Ex. 1119 p. 324
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 325 of 1082
`
`Senrice Discovery Protocol
`
`CONTENTS
`
`imroductim ................................................................................ ......32?
`
`1.1
`‘L2
`
`1.3
`
`Ganerai Descfipiion
`?~:§otiva‘Iion.
`
`Recguirements ......................................................................... .. -
`
`1.43» Nomrequiremenis and Deferred Require-n3ents........................
`1.5
`Conventions.....................................
`
`1.5.1
`
`Em And Byte Ordering Conventions.............................’
`
`Qvewiaw ......................................................................................... ..
`
`133.‘:
`
`2.2
`
`2.3
`
`C!éer:t~:’5en-'er'inieractéon..................._....._........................
`
`'4
`
`Service Record ....................................................................... .. 3
`
`Service
`
`2.5 mtribute
`
`2.6
`
`Service Ciass......................
`
`.
`
`.
`
`2.5.1
`
`A Printer Sawice Ciass ffxampie
`
`2.?
`
`Searching for
`
`2.?.2
`
`Service Search
`
`2.8
`
`Browsing for Services
`
`2.8.1
`
`Exarnpte Se.*“».-we Browsing Hierarchy ....................... ..
`
`Bata Repraseniatien .......
`3:3
`Data
`
`............................................................ ..
`
`3.2
`
`3.3
`
`3.4
`
`Sam Eéemenz Type
`
`Data Eiemeni Size
`
`Data Eierreeni Exampies ......................................................... ..
`
`Preteen! Descrigtion ...............................................................
`
`..... ..
`
`4.?
`4.2
`
`-3.3
`
`4.4
`
`4.5
`
`Transfer Byte Order
`Prntocoi Chats Unit
`
`$'»‘art%.3E fiesponses and Continuation State
`
`S€JP___Er:‘0rF<espcmse PDU ........................................ ..34?
`4.4.1
`Servicafiearch Transaction .................................................... ..3=:E8
`
`4.5.1
`
`SCIF’___8!eWicefiearchfiaqsstestF’£)L3............................._348
`
`SOP____E3erviceE52=3arc;hRespon3e
`4.5.2
`8ervice.£\ti:"it3uta
`
`4.6.1
`
`SDF’__ServiceAtir'ébutaRs3quesstPDU...................._.......351
`
`4.6.2
`
`SDF188r'viceAttrébuteRasp0nse PDU ....................... ..3.’:'s
`
`29 November 1999
`
`AFFLTD293553
`
`Samsung Ex. 1119 p. 325
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 326 of 1082
`
`Service Discovery Protocol
`
`4.?’
`
`Servicefiearohfittribute Transaczion
`
`4.???
`
`43.2
`
`SE3P‘__Sewi:;eSearc:11A11r'ibumfiequest P§3U ..
`
`354
`
`SE3P_ServioeSear'chAttribzziefiespomse PDU
`
`Service Afiriisute flefinitions ......................................................... "358
`
`5.1
`
`Universai Aiifibute fiefinifions ................................................ ..
`
`5.1.1
`
`5.1.2
`
`5.1.3
`
`5.1.4
`
`ServiceE?eco:'dHar2die Atirmute ................................. .358
`
`$erviceC$assEEZ>£.E:3’t Attribute ...................................... .. 59
`
`ServiceRe::or'dState »'3.‘ttri't3ui'.e.......,...............................359
`
`Eierviceifl Aitrimte .....................................................
`
`¥3:'otc-coEE}esoripiorL1s$Atf:ribute...................................36{}
`5.1.5
`5.1.5 Browsefsroumist
`
`5.1.7
`5.1.8
`
`Laragua§.geBa5eA1tri%:ute§Di_§s{ Atiribuie
`Serviceinf51’ime'FoLive Aitribute
`
`351
`
`Se:'viceAvaiiahiii1y
`5.1.9
`53.1.10 BiLse§oo’:hProf§ieE}e5sc;riptorijst Mtréiézste
`5.1.11 Dcn:a.=men1a1ic:r%.}RL. Aitriioute
`5.1.12 Ciienfléxecutabieuf-2LAitrE%3ute....................................364
`
`363
`
`5.1.13 icr3nURE_ Attribuie ...................................................... .365
`
`5.1.14 SarvizzeixiarneAttribute................................................3155
`
`5.1.15 SarviceflescriptionAt1ribLzte........................................356
`5.1.15 Provick:-zrfxiame a'3atta‘i'nu1e=.> .............................................. .356
`
`5.1.1? Reserved Linimrsaé Amiis.-ute
`
`!:3en*:ceE3isco~JeryServer Service (35335; Attribute Defiraiticsrss
`5.2.1
`ServiceRecordHar‘.dEe Atirmute ................................. ..3a’:‘:?’
`
`5.2.2 Servi{:eC§assEE3§_is1
`5.2.3
`Versionwasmb-er'i-ist A1tr‘sb:.:te
`
`.‘3erviceOa€:abaseE51ate .!—\t?z‘éhute ................................. .358
`
`Reeewed Attribute IDS ............................................... .368
`
`359
`Browse{3roup£)essriptor Service Ci:-zss Afiribute Definitions
`5.3.1
`ServiceC§assEDLE::~t Awibute ...................................... H389
`
`Groupiffi I-xtirihute
`5.3.2
`5.3.3 Reserved Afiribzrte
`
`Appendix A —- Baczkground Enformaticm ................................................. ..3?Q
`
`Appendix 8 -— Exampie 333? "fransactions ............................................. ..3'?1
`
`29 November 1999
`
`AFFLTD293554
`
`Samsung Ex. 1119 p. 326
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 327 of 1082
`
`Service Discovery Protocol‘
`
`1
`
`INTRODUCTION
`
`1.1 GENERAL DESCRIPTION
`
`The service discovery protocol (SDP) provides a means for applications to dis-
`cover which services are available and to determine the characteristics of
`those available services.
`
`1.2 MOTIVATION
`
`Service Discovery in the Bluetooth environment, where the set of services that
`are available changes dynamically based on the RF proximity of devices in
`motion, is qualitatively different from service discovery in traditional network-
`based environments. The service discovery protocol defined in this specifica-
`tion is intended to address the unique characteristics of the Bluetooth environ-
`ment. See V-Kgigzendix A Ea-::kg:'ci,:ri::I tnforrnal:ion,“ on page 3'Z{.'=, for further
`information on this topic.
`
`1.3 REQUIREMENTS
`
`The following capabilities have been identified as requirements for version 1.0
`of the Service Discovery Protocol.
`
`1. SDP shall provide the ability for clients to search for needed services based
`on specific attributes of those services.
`
`. SDP shall permit services to be discovered based on the class of service.
`
`. SDP shall enable browsing of services without a priori knowledge of the spe-
`cific characteristics of those services.
`
`. SDP shall provide the means for the discovery of new services that become
`avaiiable when devices enter RF proximity with a client device as well as
`when a new service is made available on a device that is in RF proximity
`with the client device.
`
`. SDP shall provide a mechanism for determining when a service becomes
`unavailable when devices leave RF proximity with a client device as well as
`when a service is made unavailable on a device that is in RF proximity with
`the client device.
`
`. SDP shall provide for services, classes of services, and attributes of ser-
`vices to be uniquely identified.
`. SDP shall allow a client on one device to discover a service on another
`
`device without consuiting a third device.
`
`8. SDP should be suitable for use on devices of limited complexity.
`
`9. SDP shall provide a mechanism to incrementally discover information about
`the services provided by a device. This is intended to minimize the quantity
`
`Introduction
`
`29 November 1999
`
`AFFLT0293555
`
`Samsung Ex. 1119 p. 327
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 8
`
`page 328 of
`
`Service Discovery Protocol‘
`
`Bluetooth-
`
`of data that must be exchanged in order to determine that a particular ser-
`vice is not needed by a client.
`
`10.SDP should support the caching of service discovery information by inter-
`mediary agents to improve the speed or efficiency of the discovery process.
`
`11 .SDP shouid be transport independent.
`
`12.SDP shall function while using L2CAP as its transport protocol.
`
`13.SDP shall permit the discovery and use of services that provide access to
`other service discovery protocols.
`
`14.SDP shat! support the creation and definition of new services without requir-
`ing registration with a central authority.
`
`1.4 NON-REQUIREMENTS AND DEFERRED REQUIREMENTS
`
`The Bluetooth SIG recognizes that the following capabilities are related to ser-
`vice discovery. These items are not addressed in SDP version 1.0. However,
`some may be addressed in future revisions of the specification.
`
`1. SDP 1.0 does not provide access to services. It only provides access to
`information about services.
`
`. SDP 1.0 does not provide brokering of services.
`
`. SDP 1.0 does not provide for negotiation of service parameters.
`
`. SDP 1.0 does not provide for billing of service use.
`
`. SDP 1.0 does not provide the means for a client to control or change the
`operation of a service.
`
`. SDP 1.0 does not provide an event notification when services, or information
`about services, become unavailable.
`
`. SDP 1.0 does not provide an event notification when attributes of services
`are modified.
`
`. This specification does not define an application programming interface for
`SDP.
`
`. SDP 1.0 does not provide support for service agent functions such as ser-
`vice aggregation or service registration.
`
`29 November 1999
`
`Introduction
`
`AFFLT0293556
`
`Samsung Ex. 1119 p. 328
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 329 of 1082
`
`Service Discovery Protocol
`
`1.5 CONVENTIONS
`
`1.5.1 Bit And Byte Ordering Conventions
`
`When multiple bit fields are Contained in a single byte and represented in a
`drawing in this specification, the more significant (high-order) bits are shown
`toward the left and less significant (low-order) bits toward the right.
`
`Multiple-byte fields are drawn with the more significant bytes toward the left
`and the less significant bytes toward the right. Multiple-byte fields are trans-
`ferred in network byte order. See Section 4.1 Transfer 3”-Syte {Dewar on page 344.
`
`Inlroduciion
`
`29 November 1999
`
`AFFLT0293557
`
`Samsung Ex. 1119 p. 329
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 8
`
`Service Discovery Protocoi
`
`2 OVERVIEW
`
`page 330 of €882
`
`Bluetooth-
`
`2.1 SDP CLIENT-SERVER INTERACTION
`
`Client
`
`Application
`
`Server
`
`Application
`
`SDP requests
` ’
`
`SDP responses
`(T
`
`Figure 2.1:
`
`The service discovery mechanism provides the means for client applications to
`discover the existence of services provided by server applications as well as
`the attributes of those services. The attributes of a service include the type or
`class of service offered and the mechanism or protocol information needed to
`utilize the service.
`
`As far as the Service Discovery Protocol (SDP) is concerned. the configuration
`shown in Figure 1 may be simplified to that shown in Figure 2.
`
`SDP requests
`
`SDP responses
`
`Figure 2.2:
`
`29 November 1999
`
`Overview
`
`AFFLT029355B
`
`Samsung Ex. 1119 p. 330
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 331 of 1082
`
`Service Discovery Protocol‘
`
`SDP involves communication between an SDP server and an SDP client. The
`server maintains a list of service records that describe the characteristics of
`services associated with the server. Each service record contains information
`
`about a single service. A client may retrieve information from a service record
`maintained by the SDP server by issuing an SDP request.
`
`if the client, or an application associated with the client, decides to use a ser-
`vice, it must open a separate connection to the service provider in order to uti-
`lize the service. SDP provides a mechanism for discovering services and their
`attributes (including associated service access protocols). but it does not pro-
`vide a mechanism for utilizing those services (such as delivering the service
`access protocols).
`
`There is a maximum of one SDP server per Bluetooth device. (If a Bluetooth
`device acts only as a client, it needs no SDP server.) A single Bluetooth device
`may function both as an SDP server and as an SDP client. If multiple applica-
`tions on a device provide services, an SDP server may act on behalf of those
`service providers to handle requests for information about the services that
`they provide.
`
`Similarly, multiple client applications may utilize an SDP client to query servers
`on behalf of the client applications.
`
`The set of SDP servers that are available to an SDP client can change dynam-
`ically based on the RF proximity of the servers to the client. When a server
`becomes available, a potential client must be notified by a means other than
`SDP so that the client can use SDP to query the server about its services. Sim-
`ilarly. when a server leaves proximity or becomes unavailable for any reason.
`there is no explicit notification via the service discovery protocol. However, the
`client may use SDP to poll the server and may infer that the server is not avail-
`able if it no longer responds to requests.
`
`Additional information regarding application interaction with SDP is contained
`in the Bluetooth Service Discovery Profile document.
`
`29 November 1999
`
`AFFLT0293559
`
`Samsung Ex. 1119 p. 331
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 8
`
`Service Discovery Protocoi
`
`2.2 SERVICE RECORD
`
`page 332 of H382
`
`Bluetooth.
`
`A service is any entity that can provide information, perform an action, or con-
`trol a resource on behaif of another entity. A service may be implemented as
`software. hardware, or a combination of hardware and software.
`
`All of the information about a service that is maintained by an SDP server is
`contained within a single service record. The service record consists entirely of
`a list of service attributes.
`
`Service Record
`
`Service Attribute 1
`
`Service Attribute 2
`
`Service Attribute 3
`
`Service Attribute N
`
`Figure 2.3: Service Record
`
`A service record handle is a 32-bit number that uniquely identifies each service
`record within an SDP server. It is important to note that, in general, each han-
`dle is unique only within each SDP server. If SDP server 81 and SDP server
`S2 both contain identical senrice records (representing the same senrice), the
`service record handles used to reference these identical service records are
`
`completely independent. The handle used to reference the service on S1 will
`be meaningless if presented to S2.
`
`The service discovery protocol does not provide a mechanism for notifying cli-
`ents when service records are added to or removed from an SDP server.
`
`While an L2CAP (Logical Link Control and Adaptation Protocol) connection is
`established to a server, a service record handle acquired from the server will
`remain valid unless the service record it represents is removed.
`If a service is
`removed from the server, further requests to the server (during the L2CAP con»
`nection in which the service record handle was acquired) using the services
`(now stale) record handle will result in an error response indicating an invalid
`service record handle. An SDP server must ensure that no service record han-
`dle values are re-used while an L2CAP connection remains estabiished. Note
`that service record handles are known to remain valid across successive
`L2CAP connections while the ServiceDatabaseState attribute value remains
`
`unchanged. See the ServiceRecordState and ServiceDatabaseState attributes
`in Section ti Service Attribute iieiinitéons on page
`
`There is one service record handle whose meaning is consistent across all
`SDP servers. This service record handle has the value 0x00000000 and is a
`
`29 November 1999
`
`Overview
`
`AFFLT0293560
`
`Samsung Ex. 1119 p. 332
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 333 of 1082
`
`Service Discovery Protocol
`
`Bluetooth.
`
`handle to the service record that represents the SDP server itself. This service
`record contains attributes for the SDP server and the protocol it supports. For
`exampie, one of its attributes is the list of SDP protocol versions supported by
`the server. Service record handle values 0x00000001-OXOOOOFFFF are
`reserved.
`
`29 November 1999
`
`AFFLT0293561
`
`Samsung Ex. 1119 p. 333
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 8
`
`Service Discovery Protocol
`
`2.3 SERVICE ATTRIBUTE
`
`page 334 of €032
`
`Bluetooth-
`
`Each service attribute describes a single characteristic of a service. Some
`examples of service attributes are:
`
`ServiceC|assiD List
`
`Identities the type of service represented by a service record.
`In other words, the list of classes of which the service is an
`instance
`
`Se rvicel D
`
`Uniquely identifies a specific instance of a service
`
`Protoco|DescrlptorList
`
`Specifies the protocol stacl<(s) that may be used to utilize a
`service
`
`ProviderName
`
`|conURL
`
`Servicetslame
`
`The textual name of the individual or organization that pro-
`vides a service
`
`Specifies a URL that refers to an icon image that may be
`used to represent a service
`
`A text string containing a human-readable name for the ser-
`vice
`
`Serviceflescrlptiori
`
`A text string describing the service
`
`See Eéerstiran 5.’? Lirmrersai Attribute t3etin'a=‘.':cns ore. page 358, for attribute defini-
`tions that are common to all service records. Service providers can also define
`their own service attributes.
`
`A service attribute consists of two components: an attribute ID and an attribute
`value.
`
`Service Attribute
`
`Attribute ID
`
`Attribute Value
`
`Figure 2.4: Service Attribute
`
`29 November 1999
`
`AFFLT0293562
`
`Samsung Ex. 1119 p. 334
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 335 of 1082
`
`Service Discovery Protocol‘
`
`2.4 ATTRIBUTE ID
`
`An attribute ID is a 16-bit unsigned integer that distinguishes each service
`attribute from other service attributes within a service record. The attribute ID
`also identifies the semantims of the associated attribute value.
`
`A service class definition specifies each of the attribute IDs for a service class
`and assigns a meaning to the attribute value associated with each attribute ID.
`
`For example. assume that service class C specifies that the attribute value
`associated with attribute ID 12345 is a text string containing the date the ser-
`vice was created. Assume further that service A is an instance of service class
`C. If service A's service record contains a service attribute with an attribute ID
`
`of 12345, the attribute value must be a text string containing the date that ser-
`vice A was created. However, services that are not instances of service class C
`
`may assign a different meaning to attribute ID 12345.
`
`All services belonging to a given service class assign the same meaning to
`each particular attribute ID. See ESe-cticn
`Seririce
`page
`
`In the Service Discovery Protocol, an attribute ID is often represented as a data
`element. See Section 3
`Representation on page 341.
`
`Type
`
`Size Index
`
`I-II
`<—5—H—3—i>1j1Ber
`
`Figure 2.5:
`
`2.5 ATTRIBUTE VALUE
`
`The attribute value is a variable length field whose meaning is determined by
`the attribute ID associated with it and by the service class of the service record
`in which the attribute is contained. In the Service Discovery Protocol, an
`attribute value is represented as a data element. (See Section 3 Data Repre-
`seawtation on page 34?.) Generally. any type of data element is permitted as an
`attribute value, subject to the constraints specified in the service class defini-
`tion that assigns an attribute ID to the attribute and assigns a meaning to the
`attribute value. See Section
`Servi:.:e Attribute iltetinitiorzs on page 358, for
`attribute value examples.
`
`29 November 1999
`
`AFFLT0293563
`
`Samsung Ex. 1119 p. 335
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 8
`
`Service Discovery Protocol‘
`
`2.6 SERVICE CLASS
`
`page 336 of
`
`Bluetooth-
`
`Each service is an instance of a service class. The service class definition pro-
`vides the definitions of all attributes contained in service records that represent
`instances of that class. Each attribute definition specifies the numeric value of
`the attribute ID, the intended use of the attribute value, and the format of the
`attribute value. A service record contains attributes that are specific to a ser-
`vice class as well as universal attributes that are common to all services.
`
`Each service class is also assigned a unique identifier. This service class iden-
`tifier is contained in the attribute value for the ServiceC|asslDList attribute, and
`is represented as a UUID (see Section 2.7.‘? iititfi on
`33?). Since the for-
`mat and meanings of many attributes in a service record are dependent on the
`service class of the service record, the ServiceC|ass|DList attribute is very
`important. Its value should be examined or verified before any class-specific
`attributes are used. Since all of the attributes in a service record must conform
`
`to all of the service’s classes, the service class identifiers contained in the Ser-
`
`viceC|asslDList attribute are related. Typically, each service class is a subclass
`of another class whose identifier is contained in the list. A service subclass def-
`
`inition differs from its superclass in that the subclass contains additional
`attribute definitions that are specific to the subclass. The service class identifi-
`ers in the ServiceC|ass|DList attribute are listed in order from the most specific
`class to the most general class.
`
`When a new service ciass is defined that is a subclass of an existing service
`class, the new service class retains all of the attributes defined in its super-
`class. Additional attributes will be defined that are specific to the new service
`class. In other words, the mechanism for adding new attributes to some of the
`instances of an existing service class is to create a new service class that is a
`subclass of the existing service class.
`
`2.6.1 A Printer Service Class Example
`
`A color postscript printer with duplex capability might conform to 4 Service-
`Class definitions and have a ServiceC|ass|DList with UU|Ds (See SE‘rGI.EDi'i 23".’:
`Ut.iit') en page 33?.) representing the following Serviceclasses:
`
`DuplexCo|orPostscriptPrinterServiceC|ass|D,
`Co|orPostscriptPrinterServiceC|assID,
`PostscriptPrinterServiceC|ass|D,
`PrinterServiceC|ass|D
`
`Note that this example is only illustrative. This may not be a practical printer
`class hierarchy.
`
`29 November 1999
`
`Overview
`
`AFFLT0293564
`
`Samsung Ex. 1119 p. 336
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 337 of 1082
`
`Service Discovery Protocol‘
`
`2.7 SEARCHING FOR SERVICES
`
`Once an SDP client has a service record handle. it may easily request the val-
`ues of specific attributes, but how does a client initially acquire a service record
`handle for the desired service records? The Service Search transaction allows
`
`a client to retrieve the service record handles for particular service records
`based on the values of attributes contained within those service records.
`
`The capability search for service records based on the values of arbitrary
`attributes is not provided. Rather, the capability is provided to search only for
`attributes whose values are Universally Unique Identifiers‘ (UU|Ds). Important
`attributes of services that can be used to search for a service are represented
`as UU|Ds.
`
`2.7.1 UUID
`
`A UUID is a universally unique identifier that is guaranteed to be unique across
`all space and all time. UUIDs can be independently created in a distributed
`fashion. No central registry of assigned UUIDs is required. A UUID is a 128-bit
`value.
`
`To reduce the burden of storing and transferring 128-bit UUID values, a range
`of UUID values has been pre-allocated for assignment to often-used, regis-
`tered purposes. The first UUID in this pre-allocated range is known as the
`Bluetooth Base UUID and has the value 00000000-0000-1000-700$
`
`0O805F9B34FB, from the Bluetooth Assigned Numbers document. UUID val-
`ues in the pre-allocated range have aliases that are represented as 16-bit or
`32-bit values. These aliases are often called 16-bit and 32-bit UU|Ds, but it is
`important to note that each actually represents a 128-bit UUID value.
`
`The full 128-bit value of a 16-bit or 32-bit UUID may be computed by a simple
`arithmetic operation.
`
`128_bit_va|ue = 16_bit_va|ue * 295 + B|uetooth_Base_UUID
`
`128_bit_va|ue = 32_bit_va|ue * 295 + B|uetooth_Base_UUID
`
`A 16-bit UUID may be converted to 32-bit UUID format by zero-extending the
`16-bit value to 32-bits. An equivalent method is to add the 16-bit UUID value to
`a zero-valued 32-bit UUID.
`
`Note that two 16-bit UUlDs may be compared directiy, as may two 32-bit
`UU|Ds or two 128-bit UUlDs. If two UUlDs of differing sizes are to be com-
`pared. the shorter UUID must be converted to the longer UUID format before
`comparison.
`
`1. The format of UUIDs is defined by the International Organization for Standardization in ISO!
`IEC 1157821996. ''Information technology— Open Systems Interconnection - Remote Proce-
`dure Call {RPC)"
`
`Overview
`
`29 November 1999
`
`AFFLT0293565
`
`Samsung Ex. 1119 p. 337
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 8
`
`Service Discovery Protocol‘
`
`2.7.2 Service Search Patterns
`
`page 338 of
`
`Bluetooth-
`
`A service search pattern is a list of UU|Ds used to locate matching service
`records. A service search pattern is said to match a service record if each and
`every UUID in the service search pattern is contained within any of the service
`record's attribute values. The UU|Ds need not be contained within any specific
`attributes or in any particular order within the service record. The service
`search pattern matches if the UUIDs it contains constitute a subset of the
`UU|Ds in the service record's attribute values. The only time a service search
`pattern does not match a service record is if the service search pattern con-
`tains at least one UUID that is not contained within the service record's
`
`attribute values. Note also that a valid service search pattern must contain at
`least one UUID.
`
`2.8 BROWSING FOR SERVICES
`
`Normally, a client searches for services based on some desired characteris-
`tic(s) (represented by a UUID) of the services. However, there are times when
`it is desirable to discover which types of services are described by an SDP
`server's service records without any a priori information about the services.
`This process of looking for any offered services is termed browsing. In SDP, the
`mechanism for browsing for services is based on an attribute shared by all ser-
`vice classes. This attribute is called the BrowseGroupList attribute. The value
`of this attribute contains a list of UUIDS. Each UUID represents a browse group
`with which a service may be associated for the purpose of browsing.
`
`When a client desires to browse an SDP server’s services, it creates a service
`search pattern containing the UUID that represents the root browse group. All
`services that may be browsed at the top level are made members of the root
`browse group by having the root browse group's UUID as a value within the
`BrowseGroupList attribute.
`
`Normally, if an SDP server has relatively few services, all of its services will be
`placed in the root browse group. However, the services offered by an SDP
`server may be organized in a browse group hierarchy, by defining additional
`browse groups below the root browse group. Each of these additional browse
`groups is described by a service record with a service class of
`BrowseGroupDescriptor.
`
`A browse group descriptor service record defines a new browse group by
`means of its Group ID attribute. In order for a service contained in one of these
`newly defined browse groups to be browseable, the browse group descriptor
`service record that defines the new browse group must in turn be browseable.
`The hierarchy of browseable services that is provided by the use of browse
`group descriptor service records allows the services contained in an SDP
`server to be incrementally browsed and is particularly useful when the SDP
`server contains many service records.
`
`29 November 1999
`
`Overview
`
`AFFLT0293566
`
`Samsung Ex. 1119 p. 338
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`Service Discovery Protocol
`
`2.8.1 Example Service Browsing Hierarchy
`
`page 339 of 1082
`
`Bluetooth.
`
`Here is a fictitious service browsing hierarchy that may illuminate the manner in
`which browse group descriptors are used. Browse group descriptor service
`records are identified with (G); other service records with (S).
`
`Pubiic Browse R oot
`
`| Eniertainmeni(G)
`
`|
`
`Games (G)
`L
`Btarcraft (S) l
`
`Movies ((3)
`I
`| ABug's Life (3) l
`
`i News(G)
`‘
`| Dictionaryl (S)
`
`R efere nce (G)
`
`‘
`
`i Encyc|ope1:|iaX(S)
`
`|
`
`New York Times (8)
`
`Local N ewsp aper (S)
`
`London Times (3)
`
`Figure 2.6:
`
`This table shows the services records and service attributes necessary to
`implement the browse hierarchy.
`
`Service Name
`
`Service Class
`
`Attribute Name
`
`Attribute Value
`
`Entertainment
`
`BrowseGroupDescri'ptor
`
`BrowseGroupL'
`
`Browseg roupDescriptor
`
`BrowseGroupL'
`
`GrouplD
`
`Pub|icBrowseRoot
`
`Entertainmentlfl
`
`Pub|icBrowseRoot
`
`Reference
`
`BrowseG rou pDescr1ptor
`
`BrowseGroupL’
`
`Pub|icBrowseRoot
`
`GroupID
`
`News|D
`
`GrouplD
`
`BrowseGroupDescriptor
`
`BrowseGroupL'
`
`Group|D
`
`BrowseGroupDescriptor
`
`BrowseGroupL’
`
`Video Game Class ID
`
`BrowseGroupL'
`
`GroLiplD
`
`Reference|D
`
`Entertainment|D
`
`GamesID
`
`Entertainment|D
`
`MoviesiD
`
`GameslD
`
`29 November 1999
`
`AFFLT0293567
`
`Samsung Ex. 1119 p. 339
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 8
`
`Service Discovery Protocol
`
`page 340 of €832
`
`Bluetooth-
`
`A Bug's Life
`
`Dictionary Z
`
`Movie Class ID
`
`BrowseGroupList
`
`Dictionary Class ID
`
`BrowseGroupi_:'st
`
`Encyclopedia X
`
`Encyclopedia Class ID
`
`BrowseGroupList
`
`MovielD
`
`ReferenceID
`
`ReferenceID
`
`New York Times
`
`London Times
`
`Newspaper ID
`
`Newspaper ID
`
`BrowseGrcupList
`
`NewspaperID
`
`BrowseGroupl.ist
`
`NewspaperiD
`
`Local Newspaper
`
`Newspaper ID
`
`BrowseGroupList
`
`NewspaperID
`
`Tabie 2.1:
`
`29 November ‘I999
`
`AFFLT029356B
`
`Samsung Ex. 1119 p. 340
`
`

`
`BLUETOOTH SPECIFICATION Version 1.0 B
`
`page 341 of 1082
`
`Service Discovery Protocol
`
`3 DATA REPRESENTATION
`
`Attribute values can contain information of various types with arbitrary com-
`plexity; thus enabling an attribute list to be generally useful across a wide vari-
`ety of service classes and environments.
`
`SDP defines a simple mechanism to describe the data contained within an
`attribute value. The primitive construct used is the data element.
`
`3.1 DATA ELEMENT
`
`A data element is a typed data representation. It consists of two fields: a
`header field and a data field. The header field, in turn, is composed of two
`parts: a type descriptor and a size descriptor. The data is a sequence of bytes
`whose length is sp