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.
| 2.1 | Profile Overview |
| 2.1.1 | Introduction |
| 2.1.2 | Profile Stack |
| 2.1.3 | Configurations/Roles |
| 2.1.4 | User Requirements/Scenarios |
| 2.1.5 | Profile Fundamentals |
| 2.1.6 | Conformance |
| 2.2 | User Interface Aspects |
| 2.2.1 | Pairing |
| 2.2.2 | Mode Selection |
| 2.3 | Application Layer |
| 2.3.1 | The Service Discovery Application |
| 2.3.2 | Service Primitives Abstraction |
| 2.3.3 | Message Sequence Charts |
| 2.4 | Service Discovery |
| 2.4.1 | An SDP PDU Exchange Example |
| 2.5 | L2CAP |
| 2.5.1 | Channel Types |
| 2.5.2 | Signalling |
| 2.5.3 | Configuration Options |
| 2.5.4 | SDP Transactions and L2CAP Connection Lifetime |
| 2.6 | Link Manager |
| 2.6.1 | Capability Overview |
| 2.6.2 | Error Behaviour |
| 2.6.3 | Link Policy |
| 2.7 | Link Control |
| 2.7.1 | Inquiry |
| 2.7.2 | Inquiry Scan |
| 2.7.3 | Paging |
| 2.7.4 | Page Scan |
| 2.7.5 | Error Behaviour |
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 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 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.
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.
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).
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.
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.
T his 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
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.
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.
T able 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.
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.
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.
Depending on the paging class (R0, R1, or R2) indicated by a RemDev device, the LocDev shall page accordingly.
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 RemDevs 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.