Service Discovery Protocol (SDP)

   The service discovery protocol (SDP) provides a means for applications to discover which services are available and to determine the characteristics of those available services.

    A specific Service Discovery protocol is needed in the Bluetooth environment, as the set of services that are available changes dynamically based on the RF proximity of devices in motion, qualitatively different from service discovery in traditional network-based environments. The service discovery protocol defined in the Bluetooth specification is intended to address the unique characteristics of the Bluetooth environment.

For more details : Download the SDP Specification from the SIG website, or visit the Documents Page.

        Table Of Contents

7.1  SDP Protocol Setup

7.1.1  Overview

    SDP is a simple protocol with minimal requirements on the underlying transport. It can function over a reliable packet transport (or even unreliable, if the client implements timeouts and repeats requests as necessary). SDP uses a request/response model where each transaction consists of one request protocol data unit (PDU) and one response PDU. However, the requests may potentially be pipelined and responses may potentially be returned out of order.

    SDP uses a request/response model where each transaction consists of one request protocol data unit (PDU) and one response PDU. In the case where SDP is used with the Bluetooth L2CAP transport protocol, only one SDP request PDU per connection to a given SDP server may be outstanding at a given instant. In other words, a client must receive a response to each request before issuing another request on the same L2CAP connection. Limiting SDP to sending one unacknowledged request PDU provides a simple form of flow control.

*Diagram Source: Courtesy of Bluetooth SIG, SDP Specs, Fig 2.1 , p 330

7.1.2  PDU Format

    Every SDP PDU consists of a PDU header followed by PDU-specific parameters. The header contains three fields:

• PDU ID field identifies the type of PDU. I.e. its meaning and the specific parameters.
• TransactionID field uniquely identifies request PDUs and is used to match response PDUs to request PDUs.
• ParameterLength field specifies the length (in bytes) of all parameters contained in the PDU.

    Parameters may include a continuation state parameter, described below; PDU-specific parameters for each PDU type are described later in separate PDU descriptions.

7.1.3   Partial Responses and Continuation State

   Some SDP requests may require responses that are larger than can fit in a single response PDU. In this case, the SDP server will generate a partial response along with a continuation state parameter. The continuation state parameter can be supplied by the client in a subsequent request to retrieve the next portion of the complete response.

7.1.4  Error Handling

    Each transaction consists of a request and a response PDU. Generally, each type of request PDU has a corresponding type of response PDU. However, if the server determines that a request is improperly formatted or for any reason the server cannot respond with the appropriate PDU type, it will respond with an error PDU (SDP_ErrorResponse) .

7.2  SDP Services

    The following section describe how the individual characteristics (services) of the different devices are stored.

7.2.1  Service Record

    A service is any entity that can provide information, perform an action, or control a resource on behalf 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.

7.2.2  Service Attribute

   Each service attribute describes a single characteristic of a service. Some examples of service attributes are ServiceClassIDList & ProviderName . Some attribute definitions are common to all service records , but service providers can also define their own service attributes.

A service attribute consists of two components: an attribute ID and an attribute value.

• 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 semantics of the associated 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 the section 'Data Representation' below for more information.

7.2.3  Service Class

    Each service is an instance of a service class. The service class definition provides 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 service class as well as universal attributes that are common to all services.

    Each service class is assigned a unique identifier ,this service class identifier is contained in the attribute value for the ServiceClassIDList attribute, and is represented as a 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.

7.3  Service Discovery

    The whole point of the SDP is to allow bluetooth devices to discover what other bluetooth devices can offer (what services). SDP allows this in various means. Searching means looking for specific service, while Browsing means looking to see what services are actually being offered.

7.3.1  Searching for Services

    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 (UUIDs). Important attributes of services that can be used to search for a service are represented as UUIDs. Service search pattern are used to locate the desired service. A service search pattern is a list of UUIDs (service attributes) used to locate matching service records.

7.3.2  Browsing for 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 service 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.

7.4  Data Representation

    As mentioned above, In the Service Discovery Protocol, an attribute value is represented as a data element. A data element is a typed data representation. It consists of two fields: a header field and a data field.

7.4.1  Data Element header field

The header field is composed of 2 parts, a Type Descriptor and a Size Descriptor.

• Type Descriptor: A data element type is represented as a 5-bit type descriptor. The type descriptor is contained in the most significant (high-order) 5 bits of the first byte of the data element header.
• Size Descriptor: The data element size descriptor is represented as a 3-bit size index followed by 0, 8, 16, or 32 bits. The size index is contained in the least significant (low-order) 3 bits of the first byte of the data element header.

7.4.2  Data Element data field

   The data is a sequence of bytes whose length is specified in the size descriptor and whose meaning is (partially) specified by the type descriptor.

7.5  Service Discovery Background info

7.5.1  Service Discovery

    As computing continues to move to a network-centric model, finding and making use of services that may be available in the network becomes increasingly important. Services can include common ones such as printing, paging, FAX-ing, and so on, as well as various kinds of information access such as telecon-ferencing, network bridges and access points, eCommerce facilities, and so on ?most any kind of service that a server or service provider might offer. In addition to the need for a standard way of discovering available services, there are other considerations: getting access to the services (finding and obtaining the protocols, access methods, "drivers" and other code necessary to utilize the service), controlling access to the services, advertising the services, choos-ing among competing services, billing for services, and so on. This problem is widely recognized; many companies, standards bodies and consortia are addressing it at various levels in various ways. Service Location Protocol (SLP), Jini ^TM , and Salutation ^TM , to name just a few, all address some aspect of service discovery.

7.5.2  Bluetooth Service Discovery

    The Bluetooth Service Discovery Protocol (SDP) addresses service discovery spe-cifically for the Bluetooth environment. It is optimized for the highly dynamic nature of Bluetooth communications. SDP focuses primarily on discovering services available from or through Bluetooth devices. SDP does not define methods for accessing services; once services are discovered with SDP, they can be accessed in various ways, depending upon the service. This might include the use of other service discovery and access mechanisms such as those mentioned above; SDP provides a means for other protocols to be used along with SDP in those environments where this can be beneficial. While SDP can coexist with other service discovery protocols, it does not require them. In Bluetooth environments, services can be discovered using SDP and can be accessed using other protocols defined by Bluetooth.

Note , the above text contains excerpts from the Bluetooth SIG's Specification, as well as various interpretations of the Specs. For complete details of the various sections, consult the actual Bluetooth Specification.