This profile defines the features
and procedures for an application in a Bluetooth device to discover
services registered in other Bluetooth devices and retrieve any desired
available information pertinent to these services.
Essentially, 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 Protocol (SDP).
For more details : Download the K2
Specification from the SIG website, or visit the Documents
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 Protocol
With regard to this
profile, the service discovery application is a specific 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 two
devices. Service discovery interactions of the latter kind can be found
within the appropriate Bluetooth usage scenario profile documents.
The main purpose of this profile is to
describe the use of the lower layers of the Bluetooth protocol stack (LC
and LMP). To describe security related alternatives, also higher layers
(L2CAP, RFCOMM and OBEX) are included.
The service discovery
user application (SrvDscApp) in a local device (LocDev) interfaces with
the Bluetooth SDP client to send service inquiries and receive service
inquiry responses from the SDP servers of remote devices (RemDevs).
SDP uses the
connection-oriented (CO) transport service in L2CAP, which in turn uses
the baseband asynchronous connectionless (ACL) links to ultimately carry
the SDP PDUs over the air. Service discovery is tightly related to
discovering devices, and discovering devices is tightly related to
performing inquiries and pages. Thus, the SrvD-scApp interfaces with the
baseband via the BT_module_Cntrl entity that instructs the Bluetooth
module when to enter various search modes of operation.
roles are defined in this profile:
The LocDev or
RemDev role assigned to a device is neither permanent nor exclusive. A
RemDev may also have a SrvDscApp installed into it as well as an SDP
client, and a LocDev may also have an SDP server. In conjunction with
which device has an SrvDscApp installed, an SDP-client installed, and an
SDP-server installed, the assignment of devices to the above roles is
relative to each individual SDP (and related) transaction and which device
initiates the transaction. Thus, a device could be a LocDev for a
particular SDP transaction, while at the very same time be a RemDev for
another SDP transaction.
covered by this profile are the following:
Search for services by
Search for services by service attributes, and
- Local device (LocDev): A LocDev
is the device that initiates the service discovery procedure. A LocDev
must contain at least the client portion of the Bluetooth SDP
architecture. A LocDev contains the service discovery application
(SrvDscApp) used by a user to initiate discoveries and display the
results of these discoveries.
- Remote Device(s) (RemDev(s)): A
RemDev is any device that participates in the service discovery
process by responding to the service inquiries generated by a LocDev.
A RemDev must contain at least the server portion of the
Bluetooth SDP architecture. A RemDev contains a service records
database, which the server portion of SDP consults to create responses
to service discovery requests.
The first two cases represent searching for known
and specific services, as part of the user question "Is service A, or
is service A with characteristics B and C, available?" The latter
case represents a general service search that is a response to the user
question "What services are available?"
The Bluetooth user should in principle be
able to connect a Bluetooth device to any
other Bluetooth device. Even if the two connected devices dont share
any common application, it should be possible for the user to find this
out using basic Bluetooth capabilities.
Before any two
Bluetooth-equipped devices can communicate with each other the following
may be needed:
The devices need to be
powered-on and initialised. Initialization may require providing a PIN
for the creation of a link key, for device authorisation and data
A Bluetooth link has to be created, which may
require the discovery of the other device's BD_ADDR via an inquiry
process, and the paging of the other device.
While it may be seem natural to consider a LocDev
serving as a Bluetooth master and the RemDev(s) serving as Bluetooth
slave(s), there is no such requirement imposed on the devices
participating in this profile. Service discovery as presented in this
document can be initiated by either a master or a slave device at any
point for which these devices are members of the same piconet. Also, a
slave in a piconet may possibly initiate service discovery in a new
piconet, provided that it notifies the master of the original piconet that
it will be unavailable (possibly entering the hold operational mode) for a
given amount of time.
If conformance to
this profile is claimed, all capabilities indicated mandatory for this
profile shall be supported in the specified manner (process-mandatory).
This also applies to all optional and conditional capabilities for which
support is indicated.
requirements regarding pairing are imposed by this profile. Pairing may or
may not be performed. Whenever a LocDev performs service discovery against
as yet unconnected RemDev(s), it shall be the responsibility of the
SrvDscApp to allow pairing prior to connection, or to by-pass any devices
that may require pairing first. This profile is focused on only performing
service discovery whenever the LocDev can establish a legitimate and
useful base-band link with RemDev(s).
assumes that, under the guidance of the SrvDscApp, the LocDev shall be
able to enter the inquiry and/or page states. It is also assumed that a
RemDev with services that it wants to make available to other devices
(e.g. printer, a LAN DAP, a PSTN gateway, etc.) shall be able to enter the
inquiry scan and/or page scan states. For more information about the
inquiry and page related states see Section 8.
Since the SrvDscApp may
also perform service inquiries against already connected RemDevs, it is
not mandatory according to the profile that a LocDev always be the master
of a connection with a RemDev. Similarly, a RemDev may not always be the
slave of a connection with a LocDev.
Service Discovery Application
this subsection, the operational framework of the SrvDscApp is presented ,
the figure below shows alternative possibilities for a SrvDscApp.
Image reprinted from Bluetooth SDAP Profile, Figure
4.1 , page 73
alternatives shown above,(which are not exhaustive by any means), achieve
the same objectives but they follow different paths for achieving them. In
the first alternative (SrvDscApp_A), the SrvDscApp on a LocDev inquires
its user to provide information for the desired service search.
Following this, the
SrvDscApp searches for devices, via the Bluetooth inquiry procedure. For
each device found, the LocDev will connect to it, perform any necessary
link set-up, and then inquire it for the desired services. In the second
alternative (SrvDscApp_ B), the inquiry of devices is done prior to
collecting user input for the service search.
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
(SrvDscApp_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.
When a LocDev
performs a service discovery search, it does so against three different
types of RemDevs:
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.
To discover type 1 or 2 RemDevs, the
SrvDscApp needs to activate the Bluetooth inquiry and/or page processes.
For type 3 RemDevs, the latter processes are needed. To perform its task,
SrvDscApp needs to have access to the BD_ADDR of the devices in the
vicinity of a 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.
briefly describes the functionality of a SrvDscApp. This functionality is
presented in the form of service primitive abstractions that provide a
formal 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 indirectly.
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.
The table below contains a minimum set
of enabling service primitives to support a SrvDscApp. Low-level
primitives like openSearch(.) or closeSearch(.) 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
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 service
primitive. The service primitives shown next relate only to service
primitives whose invocation result or relate to an over-the-air data
exchange using the Bluetooth protocols. Additional service primitives can
be envisioned relating to purely local operations like service
registration, but these primitives are outside the scope of this
The above service
primitives return the requested information, whenever found. Based on the
way that these service primitives are supported by a Bluetooth 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 relevant information. Alternatively, a
Bluetooth stack implementation may have altogether different means for
providing the results of a search.
||a search for services
(service browsing) that belong to the list of browseGroup services
in the devices in the list of RemDevs; the search may be further
qualified with a list of RemDevRelation parameters.
||a search whether the
devices listed in the list of RemDevs support services in the
requested list of services; each service 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 attributeList are also retrieved.
||a search for RemDev in the
vicinity of a LocDev.
||a termination the actions
executed as a result of invoking the services primitive identified
by the primitiveHandle.
Message Sequence Charts
profile is concerned with three distinct Bluetooth procedures. Device
discovery, 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 figure below
summarises the key message exchange phases encountered during 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 RemDev with which the LocDev is currently
connected, inquiries and pages may not be executed. In the figure, the
conditions under which particular phases are executed or not are also
Image reprinted from Bluetooth SDAP Profile, Figure
4.2 , page 78
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 his/her device by (and possibly via)
RemDev(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.
SDP PDU Exchange Example
The figure below
shows two examples of SDP PDU exchanges. In particular, it shows PDU
exchange sequences for the inquiry and retrieval of any information
pertinent to a particular Bluetooth profile.
Image reprinted from Bluetooth SDAP Profile, Figure
5.1 , page 80
are shown utilising different SDP PDUs to ultimately retrieve the same
information the protocolDescriptorList attribute from devices
that support a specific Bluetooth profile. With the first alternative, the
desired information is derived in two steps.
- The LocDev sends an SDP_serviceSearchReq
PDU which contains a service search pattern composed of the UUID
associated with the desired profile. The desired profile (profile
XYZ) is identified by its UUID, denoted in the figure as
profile_XYZ_UUID. In its response PDU, the SDP server returns
one or more 32-bit service record handles whose corresponding service
records contain the profile_XYZ_UUID UUID. In the figure, only
one such handle is shown, denoted as prHndl.
- The LocDev then enters prHndl in an SDP_serviceAttribute
PDU together with one or more attribute IDs. In this example, the
attribute of interest is the protocolDescriptorList, whose
attribute ID is 0x0004. The SDP server then,in its response, returns
the requested protocol list.
In the event that no service
record containing the desired service search pattern is found in the SDP
server, the SDP_serviceSearchResp PDU will contain
an empty serviceRecordHandleList and a totalServiceRecordCount parameter
set to its minimum value. If the desired attributes do not exist in the
SDP server, the SDP_serviceAttributeResp PDU will
contain an empty attributeList and an attributeListByteCount parameter
set to its minimum value.
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_UUID) and the desired attribute(s) is provided
(attribute ID: 0x0004). 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 and/or the desired
attribute(s) is found in the SDP server, the SDP_serviceSearchAttributeResp
PDU will contain an empty attributeLists and an attributeListsByteCount
parameter set to its minimum value.
In this profile,
only connection-oriented channels shall be used. In particular, no L2CAP
broadcasts are to be used for this profile.
For the purpose
of retrieving SDP-related information, only a LocDev can initiate an L2CAP
connection request and issue an L2CAP connection request PDU; although
there are exceptions (see comments C1& C2 on SDAP Profile p82) .
Likewise with the corresponding L2CAP connection terminations, and the
same exceptional comments C1 and C2 apply. Other than that, SDAP does not
impose any additional restrictions or requirements on L2CAP signalling.
In the PSM field of the
Connection Request packet, the value 0x0001 (see section 'Signalling'
of L2CAP layer) shall be used to indicate the
request for creation of an L2CAP connection for accessing the SDP layer.
section describes the usage of configuration options in the service
Maximum Transmission Unit (MTU)
- 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 honouring any already agreed
upon QoS contracts with other devices and/or applications. It is
expected that during the lifetime of an L2CAP connection for SDP
transactions (also referred to as the SDP session) between two
devices, any one of these devices may become engaged in an L2CAP
connection with another device and/or application.
- If this new connection has
non-default QoS requirements, the MTU for the aforementioned SDP
session is allowed to be re-negotiated during the lifetime of this SDP
session, to accommodate the QoS constraints of the new L2CAP
Quality of Service
- The SDP transactions are carried over an
L2CAP reliable channel. The flush time-out value shall be set to its
default value 0xFFFF.
- The use of Quality of Service (QoS) and
QoS negotiation is optional. If QoS is to be negotiated, the default
settings shall be used. In particular, SDP traffic shall be treated as
a best-effort service type traffic.
Transactions and L2CAP Connection Lifetime
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 L2CAP layer to tear down these connections on its behalf
Since SDP servers are considered stateless,
tearing down an L2CAP connection after a service request PDU is sent
(as a true connectionless service may imply) will be detrimental to the
SDP transaction. Moreover, significant performance penalty will have to be
paid if, for each SDP PDU transmission, a new L2CAP connection is to be
created. Thus, L2CAP connections for SDP transactions 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 client and the server
have the same L2CAP connection continuously present. A minimal SDP
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
An SDP session may last less than the minimum
required in the event of unrecoverable (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 terminate the SDP session prior
to the completion of an SDP transaction.
In this section, the LMP
layer is discussed. Table 7.1 on the SDAP Profile ,( page 86), 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 operation of devices in
this use case. Therefore, these features shall never be activated by a
unit active in this use case.
Traffic generated during
service discovery interactions has no particular QoS requirements. As
such, no particular provision of the Bluetooth link is required to support
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
reason "unsupported LMP feature."
A unit shall always be able to handle the rejection
of the request for an optional feature.
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
Table 8.1 on the
SDAP Profile, (page 88-89) lists all features on the LC level
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 subsections apply whenever a LocDev performs service
searches with RemDevs to which it is already connected.
instructed by the SrvDscApp, the LocDev shall advise its baseband to enter
the inquiry state. Entry into this state may or may not be immediate,
however, depending on QoS requirements of any already existing and ongoing
The user of the
SrvDscApp shall be able to set the criteria for the duration of an
inquiry. Nevertheless, the actual residence time in the inquiry state must
comply with the recommendation given in section 10.7.3 of Bluetooth
Baseband Specification. When inquiry is invoked in a LocDev, the general
inquiry procedure shall be used using a GIAC.
Inquiry scans are
device-dependent policies outside the scope of this profile. Devices that
operate in a discoverable mode of operation, could be discovered by
inquiries sent by other devices. To be discovered by an inquiry resulting
from a SrvDscApp action, a RemDev must enter inquiry scans using the GIAC;
SrvDscApp needs to connect to a specific RemDev for inquiring about its
service records, the LocDev will advise its baseband to enter the page
state. Entry into this state may or may not be immediate, however,
depending on QoS requirements of any already existing and ongoing
Depending on the paging class (R0, R1, or R2)
indicated by a RemDev device, the LocDev shall page accordingly.
Just like inquiry
scans, page scans are device-dependent policies outside the scope of this
profile. Devices that operate in a connectable mode of operation, could
establish Bluetooth links with other devices from pages sent by these
other devices. To establish a link with a RemDev, a LocDev must send a
page that results from a SrvDscApp action using the RemDevs 48-bit
features on the LC level have to be activated by LMP procedures, errors
will usually be caught at that layer. However, there are some LC
procedures that are independent of the LMP layer, such as inquiry or
paging. Misuse of such features is difficult or sometimes impossible to
detect. There is no mechanism defined to detect or prevent such improper
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