Search InfoTooth

Advanced Search

Vote for Us

K2 - Service Discovery Application Profile

    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.

        Table Of Contents

2.1  Profile Overview

2.1.1   Introduction

    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.

2.1.2   Profile Stack

   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.

2.1.3   Configurations/Roles

    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.

2.1.4  User Requirements/Scenarios

    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 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.

2.1.5  Profile Fundamentals

    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.

2.1.6  Conformance

    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.

2.2  User Interface Aspects

2.2.1  Pairing

    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).

2.2.2  Mode Selection

    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.

2.3 Application Layer

2.3.1  The Service Discovery Application

    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:

1. trusted devices: These are devices that are currently not connected with the LocDev but the LocDev device has already an established trusted relation with.
2. unknown (new) devices: These are untrusted devices that are currently not connected with the LocDev.
3. connected devices: These are devices that are already connected to the LocDev.

2.3.2  Service Primitives Abstraction

    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.

    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.

2.3.3  Message Sequence Charts

    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

2.4 Service Discovery

    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.

2.4.1  An 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

    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.

1. 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’.
2. 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:

1. 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.

2.5 L2CAP

2.5.1  Channel Types

    In this profile, only connection-oriented channels shall be used. In particular, no L2CAP broadcasts are to be used for this profile.

2.5.2  Signalling

    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.

2.5.3  Configuration Options

    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.

2.5.4  SDP Transactions and L2CAP Connection Lifetime

    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.

2.6 Link Manager

2.6.1  Capability Overview

    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.

2.6.2  Error Behaviour

    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."

2.6.3  Link Policy

    There are no fixed master-slave roles for the execution of this profile.

2.7 Link Control

    Table 8.1 on the SDAP Profile, (page 88-89) lists all features on the LC level

2.7.1  Inquiry

    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.

2.7.2  Inquiry Scan

    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;

2.7.3  Paging

    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.

2.7.4  Page Scan

    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.

2.7.5  Error Behaviour

    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.