The motivation for the RFCOMM protocol layer is rooted in the requirement to support legacy applications with initial Bluetooth implementations. The need for this serial communication function in the software stack was identified quite early in the SIG's formation. Just one month after the SIG was publicly announced, discussions ensued on developing the specification for the RFCOMM layer. At that time, the ETSI TS 07.10 standard [ETSI99] had already been identified as a candidate for a basis upon which to build Bluetooth serial communications. Requirements for Bluetooth serial communications include:

Multiplexed serial communications: . There may be many simultaneous clients of the serial interface in the stack, including IrOBEX, telephony control and networking clients. Thus the serial port needs to be shareable through multiplexed connections (which in turn might be supported by the protocol multiplexing in the L2CAP layer, over which distinct RFCOMM entities in different devices communicate).

RS-232 signal compatibility: . RS-232 is a widely used serial interface for the cables with which Bluetooth wireless communication needs to be compatible. Many applications are familiar with RS-232 interfaces, including the various control signals associated with RS-232; these include common signals such as Request to Send/Clear to Send (RTS/CTS), Data Terminal Ready/Data Set Ready (DTR/DSR), the RS-232 break frame and others. Emulating these signals allows RFCOMM to present to its clients the appearance of a serial port that is virtually the same as that used with a serial cable.

Remote status and configuration: . In a peer-to-peer environment, the two parties communicating over the serial link often need to determine the status and configuration of the remote serial interface so that the local serial interface can be configured in a compatible manner. The service discovery protocol, discussed in following sections, can be used to obtain basic information needed to establish a serial communications channel; following connection establishment the two ends of the serial interface need to be able to negotiate compatible serial communication settings for the connection.

Internal and external serial port: . To support the various uses of serial communications in Bluetooth applications, RFCOMM needs to support both an internal emulated serial port, in which the serial port parameters are used only locally (the parameters do not apply across the air-interface) as well as an external serial port, where the serial port parameters and status are transmitted across the RF link along with the data and may be used by the receiving serial port.

These requirements are not unique to Bluetooth environments, and the SIG realized that the aforementioned ETSI TS 07.10 standard was a good match for the needs of Bluetooth serial communications, so the SIG adopted much of that standard. However, TS 07.10 is not a perfect match for use in the Bluetooth protocol stack, so the SIG added some of its own modifications to adapt the ETSI standard for use in Bluetooth wireless communications. Among these additions and changes are:

Data frame adaptations: . Since Bluetooth communication has an underlying packet structure by virtue of the use of L2CAP, some of the data frame contents specified by TS 07.10 are unnecessary for RFCOMM. For example, the frame delimiter flags specified in TS 07.10 are discarded for the RFCOMM specification.

Connection establishment and termination: . Again, because Bluetooth communication has its own connection management in the transport protocol layers that RFCOMM uses, the connection management functions of TS 07.10 are superfluous for RFCOMM. The specification details how RFCOMM links are managed.

Multiplexing: . RFCOMM uses a subset of the multiplex channels specified for TS 07.10 and specifies the way in which some TS 07.10 multiplexing control commands are used in RFCOMM.

Applicability: . The RFCOMM specification mandates support of several features which are optional in the TS 07.10 standard. These features deal with exchanging information about the configuration and status of the serial connection and include negotiating the serial port and individual channel settings and retrieving the serial port status. In Bluetooth environments these functions are quite useful and in fact can be considered necessary for effective use of the air-interface; thus they are specified as mandatory to support in RFCOMM.

Flow control: . Typical serial ports pace the data transfer using XON/XOFF pacing or DTR signal pacing. For RFCOMM, the specification describes flow control mechanisms specific to the Bluetooth protocol stack, including flow control that applies to all multiplexed RFCOMM channels as well as per-channel pacing.

The remaining RFCOMM sections in this chapter review key points of the RFCOMM specification, in many cases highlighting the significance of the design choices for this protocol layer.

The relatively few pages^[2] devoted to RFCOMM in the specification belie its importance in the version 1.0 protocol stack. RFCOMM is the basis for most of the version 1.0 profiles and might also be used in some future profiles, although its primary purpose is to enable support for legacy applications in simple cable-replacement scenarios.^[3] The main reason that RFCOMM does not require many dozens of pages of explanation is the SIG's decision to adopt much of the ETSI TS 07.10 protocol (which itself is over 50 pages of specification). By specifying TS 07.10 as the basis for RFCOMM, the SIG has adopted a mature standard protocol and the specification needs to describe only the adaptation of this standard for Bluetooth environments. Much of the RFCOMM chapter of the specification focuses on describing which parts of TS 07.10 are relevant for RFCOMM, how those features are used and the modifications necessary to map TS 07.10 into the Bluetooth protocol stack.

RFCOMM uses an L2CAP connection to instantiate a logical serial link between two devices. In particular, an L2CAP connection-oriented channel is established that connects the two RFCOMM entities in the two devices. Only a single RFCOMM connection is permitted between two devices at a given time, but that connection may be multiplexed so that there can be multiple logical serial links between the devices.^[4] The first RFCOMM client establishes the RFCOMM connection over L2CAP; additional users of the existing connection can use the multiplexing capabilities of RFCOMM to establish new channels over the existing link; and the last user to drop the final RFCOMM serial link should terminate the RFCOMM connection (and hence the underlying L2CAP connection). Each multiplexed link is identified by a number called a Data Link Connection Identifier, or DLCI. Figure 8.2 depicts multiplexed serial communications links using RFCOMM over L2CAP. In the illustration the various clients of RFCOMM each see their own emulated serial port, distinguished by a DLCI value (depicted by the different line types in the figure). These separate channels are then multiplexed over the RFCOMM link, which in turn is carried over an L2CAP connection.

Figure 8.2. Multiplexed RFCOMM logical serial links (indicated by different line types) over a single RFCOMM connection, in turn over an L2CAP connection.

The specification allows for up to 60 multiplexed logical serial links over a single RFCOMM connection but does not mandate this level of multiplexing for RFCOMM implementations. In fact for most portable devices it is uncommon to have cases in which dozens of simultaneous serial links would be required in Bluetooth environments. Most devices are expected to support a fixed number of profiles, which will be a determining factor in how the protocol stack for those devices is implemented, including design tradeoffs such as the number of RFCOMM serial links supported. But consider also devices such as network access points that allow portable devices to use Bluetooth wireless communication to access larger networks (such as the Internet). The LAN Access profile (discussed in Chapter 15) specifies the use of PPP over RFCOMM, so a LAN access point device might indeed need many simultaneous serial connections to multiple devices. The RFCOMM specification supports this sort of usage by allowing more than one multiplexer session (that is, more than one instance of RFCOMM, in which case the multiplexing is achieved by using L2CAP's multiplexing capabilities), although such a capability is not mandated.

The RFCOMM chapter of the specification includes a discussion of two different sorts of devices that RFCOMM supports: communication endpoint (computer- or peripheral-style devices) and communication midpoint (modem-style devices). In general serial communications, these are often referred to as data terminal equipment (DTE) and data communications equipment (DCE), respectively. After making this distinction, though, the discussion concludes by stating that RFCOMM does not distinguish between these device types at all. In fact, it is not necessary for RFCOMM to do so; much as a standard serial cable can be configured for a direct serial connection or for null modem operation, RFCOMM also can be used in both manners. RFCOMM has included features to support DCE (modem-style) communications; these features may not be applicable for DTE communications. RFCOMM supports both device styles without needing to distinguish between them.

Typical cabled serial connections have a number of signals in the cable (usually nine for RS-232 communications, although all nine signals are not necessarily used in all applications). Bluetooth wireless communication obviously has no such signals because the transmission medium is the air-interface rather than a cable. In a multiplexed environment such as is defined by TS 07.10, it is desirable that each serial channel be viewed as an independent entity, with its own set of control and data signals. So even in a cabled environment some scheme is needed for multiplexing the serial signals. TS 07.10, and thus RFCOMM, do this by defining a specified control channel across which information is transmitted as data. That is to say, rather than setting and monitoring signal levels as is done with a standard RS-232 interface, RFCOMM uses commands and responses to communicate the state of the multiplexed serial interface (thus virtualizing the RS-232 signals).

RS-232 defines other states that are not directly represented by signals. Notable among these is the baud rate, or the clock frequency used to transmit and receive data. In standard cabled serial communications, a clock governs the time associated with the signal transition to and from low and high levels, which define the 0/1 bit patterns. Obviously both sides of the interface must use the same clock frequency, or baud rate, to correctly interpret the data that is transmitted across the wire. For wireless environments, however, there is no cable and thus no signal wire to pulse at a specified frequency. Clearly, though, Bluetooth wireless communication does employ clock timings to communicate over the air-interface at the baseband level. Since RFCOMM operates over the transport layers of the protocol stack, it makes use of the packet structure and transmission medium used by those lower layers. The baud rate of Bluetooth wireless communication is determined by the packet types and structures being sent over the air-interface. The actual communication will occur at the rate determined by the baseband protocol, regardless of what baud rate might be specified at the RFCOMM layer for serial port emulation. So while an application or other client of RFCOMM can specify a baud rate (this would be a typical action, especially for legacy applications, and RFCOMM allows it), the specified baud rate does not determine the actual data rate. In many cases, the data transmission rate using Bluetooth wireless communication could be faster than for typical cabled communications.

Curiously, the RFCOMM chapter of the core specification (volume 1) includes a section containing the sort of information (application considerations, interactions with other protocol stack layers and SDP service record data) that is usually found in the profile specifications (volume 2). This is an artifact of the development of the RFCOMM specification. As previously noted, RFCOMM specification development was underway almost from the beginning of the SIG's formation. Along with the lower-layer transport protocols, which consumed much of the SIG's attention at first, RFCOMM was one of the first protocols to reach a stable specification level (this is due partly to the fact that RFCOMM leverages the TS 07.10 standard and partly to the hard work applied to the RFCOMM specification by its owners in the SIG, since the SIG recognized that RFCOMM was a key element of the version 1.0 protocol stack and a foundation upon which other protocol layers and profiles were to be built). Most of the profiles were developed after the core specification was stable. The forward-looking authors of the RFCOMM portion of the specification had already included some of the information that subsequently became part of the serial port profile (covered in Chapter 14).

So the RFCOMM chapter of the specification gives some hints on using this layer of the protocol stack. The specification talks about Port Emulation and Port Proxy entities, the former mapping platform APIs to RFCOMM functions and the latter mapping RFCOMM to a "real" RS-232 external interface. The point, though, is that the authors of the RFCOMM specification not only have specified a protocol that is necessary for many legacy applications to make use of Bluetooth wireless communications but also have offered a few considerations for the applications that use that protocol.

In fact the programming model suggested in RFCOMM is a specific instance of the generalized model suggested in the section entitled "The Application Group" in Chapter 5 (refer back to Figure 5.4). In this case we suggest a thin layer of Bluetooth adaptation software for legacy applications that maps platform APIs to specific functions of the Bluetooth protocol stack. In the case of RFCOMM, which provides an emulated serial port, this adaptation software (which the specification calls a port emulation entity) needs to map the application's interactions with a "real" RS-232 serial port to the equivalent operations for the RFCOMM emulated serial port. For the most part these are expected to be initialization operations such as activating and configuring the serial port and establishing a serial connection; and finalization operations such as terminating the serial connection. Once a general serial port adaptation layer is in place in a system, all those legacy applications that use serial communication ought to be enabled to use Bluetooth transports via the RFCOMM emulated serial port.

As pointed out earlier, the use of serial ports is prevalent in devices and environments where Bluetooth wireless communication is likely to be used, and the majority of the version 1.0 profiles depend upon serial port communications. In the absence of a version 1.0 specification for general networking, the RFCOMM protocol provides an important utility for legacy applications. The implementation of this protocol, along with adaptation software for legacy applications that use serial communications, permits many simple cable replacement applications of Bluetooth wireless communication.

The need for a service discovery component in the protocol stack was recognized early in the process of developing the specification, although direct work on SDP did not commence until later. In early and mid 1998, many of the initial participants in the SIG were focusing on the transport protocols and key middleware protocols like RFCOMM. While the need for other protocols had been identified, task forces of experts to develop these protocols had not been assembled in all cases. In the case of SDP, some preliminary work had been started at Intel and Ericsson in the summer of 1998.

In early internal versions of the specification, service discovery was a section within the L2CAP part of the specification. Initially, L2CAP channels were modeled after a computer bus, and service discovery was concerned exclusively with the transport of Plug and Play parameters over this virtual bus. In September 1998, at a SIG meeting in London,^[6] author Bisdikian suggested that the addition of a transport protocol for Plug and Play parameters unnecessarily complicated the L2CAP specification, and that such a protocol merited its own service discovery portion of the Bluetooth specification.

In October 1998 the SIG held a developers conference in Atlanta which author Miller attended. Based upon conversations during that conference, Miller was asked to chair the service discovery task force of the SIG's software working group shortly thereafter. The following month the newly constituted group met for the first time as a formal SDP task force.

While at this time (late 1998) many of the protocol layers had been under development for several months, with some of them approaching levels of stability that would soon near final stages, SDP was still really in a nascent state of forming the requirements and the beginning of a proposal to address those requirements.

Among the identified objectives for Bluetooth SDP were:

Simplicity: . Because service discovery is a part of nearly every Bluetooth usage case, it is desirable that the service discovery process be as simple as possible to execute. For the SDP task force this also implied the reuse of other Bluetooth protocols to the extent possible.

Compactness: . As described in previous chapters, the formation of Bluetooth communication links between two devices can in some cases be time consuming. Since service discovery is a typical operation to perform soon after links are established, the SDP air-interface traffic should be as minimal as feasible so that service discovery does not unnecessarily prolong the communication initialization process.

Versatility: . The version 1.0 specification includes a number of profiles, and future revisions will undoubtedly add to the list, which is expected to continue to grow. Since an exhaustive set of profiles, usage cases and associated services cannot be foreseen or accurately predicted, it is important for SDP to be easily extensible and versatile enough to accommodate the many new services that will be deployed in Bluetooth environments over time. To support this objective the SDP task force chose a very broad definition of "service," so that the widest possible spectrum of features (services) could be supported in the future.

Service location by class and by attribute: . In the dynamic ad hoc networking environment it is important to enable client devices and users to quickly locate a specific service when they already know exactly (or at least largely) what they are looking for. It should be straightforward to search for a general class of service (say, "printer"), for specific attributes associated with that service (for example, "color duplex IBM printer") and even for a specific instance of a service (such as a specific physical printer).

Service browsing: . In addition to searching for services by class or attribute, it is often useful simply to browse the available services to determine if there are any of interest. This is a different usage scenario than is searching for specific services, and in some respects it is almost a contrary objective, but the SIG agreed that both usage models have merit, and they developed a solution that uses a consistent method to support both specific service searching and general service browsing.

These objectives led to the development of requirements for a simple, flexible protocol and data representation for service discovery in the protocol stack. Popular industry discovery protocols were reviewed, but none seemed to provide a good match for the SDP objectives—many of these technologies provide robust and comprehensive service discovery and access methodologies, but the SIG was really looking for a fairly low-level, simple, narrow-in-scope solution that met the rather modest objectives noted above in a straightforward manner.^[7] At this point Motorola® approached the SIG with a proposal to contribute some technology, suitable for use in Bluetooth service discovery, that Motorola had had under development for several years. Through a contributing adopter agreement Motorola was then able to participate in the SDP task force of the SIG (and in fact the Motorola representative served as editor of the SDP specification), with their contributed technology forming the basis for SDP.

So with the SDP effort underway in November 1998, the SDP requirements and scope were agreed upon and the specification development ensued, incorporating the ideas contributed by Motorola along with the many contributions by the other SIG member companies. Even though the real SDP work started later than for many other protocols, through hard work the SDP specification was completed, ratified and published along with the bulk of the other protocols in the stack in July 1999 in the version 1.0 specification.

The following sections describe some of the key facets of the SDP specification, including why these elements are significant and the rationale for including them in the specification.

Key to understanding the development of SDP is to understand its motivation and requirements. In fact, this information is included at the beginning of the SDP portion of the specification. As noted above, SDP is intended to allow devices in Bluetooth environments to locate available services. As the specification states, these environments are qualitatively different from traditional networks such as LANs or WANs. Devices and services are likely to come and go frequently in Bluetooth piconets. Thus SDP was developed to satisfy the requirements of such environments.

Some of the notable requirements for SDP are listed in the preceding section. These are also mentioned and expanded upon in the specification. Also of interest are those items that SDP does not attempt to address, at least in version 1.0 of the specification.^[8] The "Non-Requirements and Deferred Requirements" portion of the SDP specification can be summarized largely with the statement that SDP is narrow in scope, focusing primarily on discovery in Bluetooth environments and leaving more sophisticated service functions and operations to other protocols which might be used in conjunction with SDP.

SDP includes the notion of a client (the entity looking for services) and a server (the entity providing services). Any device might assume either role at a given time, acting sometimes as a service client and sometimes as a service provider (server).

The service provider needs to maintain a list of service records that describe the service(s) it provides; this list is called the service registry. A service record is simply a description of a given service in a standard fashion as prescribed by the specification. A service record consists of a collection of service attributes containing information about the class of the service (which might be printing, faxing, audio services, information services, and so on), information about the protocol stack layers that are needed to interact with the service, and other associated information such as human-readable descriptive information about the service. Figure 8.3 illustrates the general structure of a service registry with its constituent service records. Shown is a set of services, each with a service record handle (depicted by srvRecHnd[0] through srvRecHnd[j]) and a set of attributes per service (shown as srvAttribute[0:a] through srvAttribute[j:c]). Further explanation of the content of these service records follows.

Figure 8.3. General SDP service registry structure.

Service records consist of both universal service attributes and service-specific attributes. The universal service attributes are simply those parts of the service record that apply to all types of services, such as the service class and protocol stack information noted above. Service-specific attributes are those parts of the service record that are relevant only for a specific class or instance of a service. Examples of service-specific attributes could include attributes specific to a printing service (such as color, duplex and finishing capabilities), attributes specific to an audio service (such as data rate or encoding scheme) or attributes specific to a dial-up networking service (such as serial port configuration or modem setup information). Volume 1 of the specification includes definitions for a set of universal service attributes (those which could apply to all types of services), but it does not include service-specific attributes, since it would be impossible to specify and predict all of the attributes for every imaginable type of service. Service-specific attributes are defined in profiles (volume 2 of the specification). Since profiles describe a usage scenario and how the protocol stack is used, they effectively define a service. So, for example, the headset profile defines the service specific attribute "remote audio volume control" that applies to the headset service. While the universal service attributes can apply to all types of services, this does not mean that they are mandatory—it is not required that every service include every universal service attribute in its service record. In fact, only two of the universal service attributes are mandatory: the service class attribute, which defines the class, or type of the service, and the service record handle, which serves as a pointer, or reference to the service record and is used by the client to access the server's service record.

Each service attribute in a service record consists of an attribute identifier (attribute ID, a 16-bit unsigned integer) and an attribute value associated with that attribute ID. Each entry of the service record is one of these (attribute, value) pairs. Because these attributes describe all sorts of information, SDP uses the concept of a data element for the attribute value. A data element is simply a self-describing piece of data. The first part of a data element consists of a one-byte header that tells the actual type and size of the data. The remainder of the data element consists of the data values for the attribute, of the format and size specified by the data element header. Through the use of data elements, SDP allows attribute values to be of several types, including strings, Booleans, signed and unsigned integers of various sizes, and universally unique identifiers (UUIDs, discussed further below). Moreover, these data types can be lists of the scalar elements noted above, thus providing a flexible representation for the many data types of which attribute values might be composed.

Discovering a service in Bluetooth wireless communication reduces to a simple operation: the client specifies the service(s) of interest and the server responds, indicating any available services that match what the client specified. In practice for SDP this consists of the client's sending a request in the form of an SDP protocol data unit (SDP_PDU) that indicates what service(s) it is searching for and the server's sending back a response, also in the form of an SDP_PDU, that indicates what services match the request that the client has made. To accomplish this, the client needs a standard way to represent the service(s) of interest and the server needs a standard method to match its available services against the client's specification. For this purpose SDP introduces universally unique identifiers (UUIDs).

A UUID is a concept adopted from the International Organization for Standardization (ISO). UUIDs are 128-bit values that can be created algorithmically and, generally speaking, can be virtually guaranteed to be entirely unique—no other UUID ever created anywhere will have the same value.^[9] One advantage of using UUIDs is that new identifiers can be created for new services without requiring a central registry of identifiers maintained by the SIG, although the SIG does include a list of "well-known" UUIDs in the specification for those services related to the published profiles. So a client looking for a service just specifies the UUID associated with that class of service (or with the specific service) in its service search request, and the service provider matches that UUID against those of the services it has available to generate its response.

The SDP_PDUs exchanged between the client and server are simple transactions. The general SDP protocol flow requires only two transactions; the specification defines three different SDP transactions, but the third is really just a composite of the first two. A typical SDP transaction consists of:

Following the above transaction, the client will presumably use the information obtained in step 2 to open a connection to the service using some protocol other than SDP to access and utilize the service. Step 1 is called the ServiceSearch transaction and consists of the ServiceSearchRequest SDP_PDU from the client to the server and the ServiceSearchResponse SDP_PDU in return (from server to client). As noted above, the ServiceSearchResponse SDP_PDU contains handles to one or more services that match the request. In step 2, the client presents one or more of those handles in a ServiceAttributeRequest SDP_PDU which causes the server to generate a ServiceAttributeResponse SDP_PDU; this exchange is the ServiceAttribute transaction. In the ServiceAttributeResponse SDP_PDU will be the attribute values associated with the service that correspond to the attribute IDs that the client specified in the ServiceAttributeRequest SDP_PDU. These attributes may be a combination of universal service attributes and service-specific attributes, and in most cases should provide the client with enough information to subsequently connect to the service.

The specification defines a third SDP transaction, called the ServiceSearchAttribute transaction. This transaction consists of a ServiceSearchAttributeRequest SDP_PDU from the client to the server followed by a ServiceSearchAttributeResponse SDP_PDU from the server to the client. It is actually redundant to the first two transactions described above and is included for efficiency. What the ServiceSearchAttribute transaction allows is the combination of steps 1 and 2. That is, the client can form a single request that specifies not only services to search for but also the attributes to return for matching services in the server's response. The server then responds with handles to matching services as well as the requested attribute values for those matching services. An implementer thus has a choice between the two alternatives for SDP transactions.^[10] More importantly, though, the ServiceSearchAttribute transaction may in some cases be more efficient in terms of the number of bytes transmitted over the air-interface. The consolidated transaction itself requires more bytes than the individual transactions but could result in fewer total transactions. Especially in cases where many service records are being accessed, such as in a service browsing application, the ServiceSearchAttribute transaction might be more efficient.

In a nutshell, this is most of what is needed for SDP transactions. The specification also includes protocol definitions for special cases, including an error response SDP_PDU and a mechanism, called the continuation state, for dealing with server responses that cannot fit into a single SDP_PDU.^[11] The syntax of these protocol transactions and the data elements that they carry is detailed in the specification and is not reproduced here. A unique feature of the SDP chapter of the specification is the inclusion of several detailed protocol examples as an appendix to the SDP specification. The members of the service discovery task force of the SIG who developed the specification felt that because the actual byte streams generated for SDP transactions can be complex (even though the transactions themselves are conceptually simple), it would be useful to include the examples as a guide for implementers. The complexity is introduced mostly when complex data elements (such as DataElementSequences, which are lists of data elements and which can be nested) are carried in the SDP_PDUs. When these complex data types are included in SDP_PDUs, or when SDP_PDUs need to be split using the continuation state information, the various "count" fields that introduce segments of the SDP_PDUs need to accurately reflect the number of bytes that follow in that segment. The examples in the specification serve to clarify the correct construction of SDP_PDUs.^[12]

Figure 8.4 summarizes the SDP transactions. Shown in the figure are representations of the relevant arguments and parameters passed in the SDP_PDUs, although these are not complete lists of all arguments and parameters; the complete syntax is in the specification. As Figure 8.3 shows, only services and service attributes that are described by UUIDs are searchable. Attributes of a service which are not described by UUIDs are not searchable and can be retrieved only after a service has been located using a UUID attribute.

Figure 8.4. SDP transaction summary.

Since SDP was developed primarily for discovering services in Bluetooth environments, the applications most likely to make use of SDP will be those developed specifically to be aware of Bluetooth wireless communication (as opposed to legacy applications). One exemplary application for SDP usage is what we will call the Bluetooth Piconet Minder^[13] (or BPM application). Such an application is likely to be included, in one form or another, in many Bluetooth devices. A BPM application as we envision it would present a view of available devices and services in proximity (in a piconet) to the user and to other applications. This could include a user interface; one might imagine icons or other representations of devices and services. Such an application could give a user a central point to manage the Bluetooth connections to other devices and to select and make use of the services offered by those other devices. To support such functions, a BPM application might make use of service searching and service browsing and thus initiate SDP transactions to populate the service information that is exposed to the user and to other applications.

Certainly other applications designed for use in Bluetooth environments might use SDP. Every profile (or at least every "non-generic" profile that involves concrete usage scenarios) includes an SDP service record to be used when implementing that profile. Applications written specifically to exercise the protocol stack will probably need to execute SDP transactions to successfully instantiate the profiles. First, such applications will need to execute SDP transactions with another device to determine if that device offers the desired service, and if so, those applications will need to execute additional SDP transactions to obtain the information from the service record about how to access that service (this can include such information as the required protocol stack and associated parameters that the service uses).

In the case where multiple applications use SDP (perhaps one or more profile applications and a BPM application), it may be advantageous to implement a central SDP client and SDP server that are available to all the applications that need them. These SDP "helper applications" could be implemented as part of the common services layer that was described in Chapter 5. The applications could use the platform APIs to access the common SDP services which would generate the SDP transactions and pass the retrieved information back to the applications.

The Service Discovery Application Profile (SDAP) detailed in Chapter 12 offers guidance for application interactions with SDP. While, as previously noted, the specification does not define APIs, the SDAP does define primitive operations that could be mapped to APIs and events on many platforms, thus providing a basis for SDP common services.

There may be legacy applications that make use of service discovery, but such applications probably use some other industry discovery protocol (perhaps Jini™, Universal Plug and Play™, Salutation™, Service Location Protocol, the IrDA service discovery protocol, or some other protocol). Since SDP was developed for Bluetooth applications, legacy applications would not be expected to include this protocol without modification to the application. Even for these applications, though, SDP does offer some accommodation. One of the design points for SDP was to ensure that other popular industry discovery protocols could be used in conjunction with it. One of the things that can be discovered using SDP is that the service supports one or more other discovery protocols. Thus SDP might be used in the initial service discovery phase to locate the service; further SDP transactions might be used to discover that the service supports, say, Salutation; once this has been determined, the newly discovered protocol (Salutation in the example) can be used for further interaction with the service. SDP specifically supports this sort of operation. A SIG white paper [Miller99] describes how Salutation can be mapped to SDP. Similar mappings to other technologies should be possible, and the SIG is working toward formalizing some of these mappings as profiles, as discussed in Chapter 16.