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
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
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
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.
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.
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)
The following section describe how the
individual characteristics (services) of the different
devices are stored.
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
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
- 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.
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.
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.
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
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.
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.
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
- 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.
The data is a sequence of bytes whose length is specified
in the size descriptor and whose meaning is (partially) specified by the
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.
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