|
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
Page.
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).
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.
The following roles are defined in this profile:
- 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 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.
The scenarios covered by this profile are the
following:
- Search for services by service class,
- Search for services by service attributes, and
- Service browsing.
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 don’t
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 encryption.
- 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.
No particular 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).
This profile 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.
In 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
The SrvDscApp 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.
This section 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 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 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 profile.
| serviceBrowse |
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. |
| serviceSearch |
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. |
| enumerateRemDev |
a search for RemDev in the vicinity of a LocDev. |
| terminatePrimitive |
a termination the actions executed as a result of invoking
the services primitive identified by the primitiveHandle. |
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.
This 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 provided.
Image reprinted from Bluetooth SDAP Profile, Figure 4.2
, page 78
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 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.
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
Two alternatives 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.
This section describes the usage of
configuration options in the service discovery profile.
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 connection.
Flush Time-out
- The SDP transactions are carried over an L2CAP reliable channel. The
flush time-out value shall be set to its default value 0xFFFF.
Quality of Service
- 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.
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 L2CAP layer to ‘tear down?these connections on its behalf as well.
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 SDP transaction.
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 this profile.
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 appropriate.
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.
Whenever 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 connections.
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;
Whenever the 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 connections.
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 RemDev’s 48-bit BD_ADDR.
Since most 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 use.
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.
|
