Up to Karl's Index | On to SDP Working Document

The Bluetooth Service Discovery Protocol

The Bluetooth SDP provides a means by which service applications running on different Bluetooth enabled devices may discover each other's existence, and exchange information to determine their characteristics.

SDP Overview
Diagram from the Bluetooth 1.1 Specification Document,
page 543 fig 1.1 "Overview of the lower software layers".

We have chosen as our SLIP project to develop a minimal implementation of this protocol. Each Bluetooth device runs a single specialised SDP Server application with a known, fixed local address which handles SDP requests and responses:
  • Applications may register services which they wish to offer across the Bluetooth network with their local SDP Server.
  • Applications may request lists of available services, or the address of specific services available on the local network from their local Bluetooth SDP Server.
  • SDP Servers periodically exchange service database information with each other so as to remain up-to-date with the services available on the local network.
  • SDP Servers additionally provide the communication channels between a client and server service. Clients request connections to each service through their local SDP Server.
As a support for this SDP behaviour we have developed an additional layer of Bluetooth behaviour on top of that previously developed on the processor board. This mostly comprises a working Link Manager. It is this Communications Module on which I myself largely worked. This layer provides the SDP Server with the functionality necessary to:
  • discover the addresses of neighbouring Bluetooth devices.
  • Open and close links with these devices.
  • Transmit and receive data over these links with neighbouring SDP Servers

We have chosen to diverge slightly from the Bluetooth Specification Documents for this minimal implementation in having the SDP Server itself provide communications for its local clients. That is - the SDP Server multiplexes and demultiplexes the data streams as necessary. SDP clients communicate with each other only through their local SDP Server. This allows the Bluetooth Link Manager layer to direct all incoming communications to its local SDP Server for further dissemination. A useful future extension would be to incorporate this Multiplexing facility into the Link Manager layer proper [see Future extensions].

The Working Document
Once the group had decided the project outline, I produced a Draft Proposal Document which detailed the breakdown of SDP operations, and the necessary Bluetooth layer support. This document specifies those Bluetooth functions which are required to support communication channels between SDP Servers following the Bluetooth Specification Documents.

Specifically I determined that an equivalent of the following functions was required:
  • L2CA_ConnectReq: To request a connection with the SDP Server on another Bluetooth device.
  • L2CA_DisconnectReq: To close a connection.
  • L2CA_DataWriteReq: To write data to an open connection.
  • L2CA_DataRead: To read data from an open connection.
  • L2CA_ConnectInd: To inform the local SDP Server of an incoming connection request.
  • L2CA_DisconnectInd: To inform the local SDP Server of a disconnected connection.
  • HCI_Inquiry: To allow the SDP Server to discover neighbouring Bluetooth devices

This Draft Proposal Document has now been adopted with only minor changes as our SDP Working Document. Only those functions indicated above from the document have been implemented, as it became apparent that the other proposed functions were unecessary for our simplified implementation.

The Bluetooth SDP Requirements
The Bluetooth 1.1 Specification Documents outline specific requirements which should be met by an implementation of the SDP. These are listed below, verbatim from page 335.

It is clear that we have successfully followed met requirements 1 through 8. The remaining requirements are currently only partially satisfied.
Incremental discovery and database caching have not been implemented, and only the ACL transport medium has been utilised, though this is only a limitation of our minimal Bluetooth implementation.

It is my belief that our basic approach could easily be extended to meet the remaining requirements.

The following capabilities have been identified as requirements for version 1.0 of the Service Discovery Protocol.

  1. SDP shall provide the ability for clients to search for needed services based on specific attributes of those services.
  2. SDP shall permit services to be discovered based on the class of service.
  3. SDP shall enable browsing of services without a priori knowledge of the specific characteristics of those services.
  4. SDP shall provide the means for the discovery of new services that become available when devices enter RF proximity with a client device as well as when a new service is made available on a device that is in RF proximity with the client device.
  5. SDP shall provide a mechanism for determining when a service becomes unavailable when devices leave RF proximity with a client device as well as when a service is made unavailable on a device that is in RF proximity with the client device.
  6. SDP shall provide for services, classes of services, and attributes of services to be uniquely identified.
  7. SDP shall allow a client on one device to discover a service on another device without consulting a third device.
  8. SDP should be suitable for use on devices of limited complexity.
  9. SDP shall provide a mechanism to incrementally discover information about the services provided by a device. This is intended to minimize the quantityof data that must be exchanged in order to determine that a particular service is not needed by a client.
  10. SDP should support the caching of service discovery information by intermediary agents to improve the speed or efficiency of the discovery process.
  11. SDP should be transport independent.
  12. SDP shall function while using L2CAP as its transport protocol.
  13. SDP shall permit the discovery and use of services that provide access to other service discovery protocols.
  14. SDP shall support the creation and definition of new services without requiring registration with a central authority.

Valid CSS! Valid HTML 4.01!