Service Discovery
Introduction
Computing is part of almost everyone’s daily routine. From communicating via e-mail and mobile phone to shopping online, computing has found its way into mainstream living. As more people use mobile phones, personal digital assistants (PDAs) and laptop computers to perform daily tasks, it becomes critical that people be able to find services in their local area in a standard way that makes them easy to connect to and use.
The evolution of networking parallels the evolution of computing. As computers evolved from special-purpose, high-cost devices to general-purpose, low-cost devices, so too have networks evolved from single-function and limited-access (university and military networks), to open, multifunction platforms built around core standards (Transmission Control Protocol/Internet Protocol [TCP/IP], Hypertext Transfer Protocol [HTTP], Hyper Text Markup Language [HTML]). But the very success of such open and truly global networks can create its own problems. A key problem is one that every Internet user has experienced: the “finding stuff” problem. We know the information or service we need is out there, but we don’t know how to find it. Most of our first online experiences were slightly overwhelming as we grappled with quantities of information presented to us. Hence, the rise of search engine technology (such as Google) and specialized portals that categorize information for us (such as Yahoo!). The more information there is out there, the more help we need finding it.
As computers became smaller and more powerful, a new category called information appliance emerged; it includes PDAs, ultra-light laptops, high-end phones, and Web tablets. These devices are typically used in many different scenarios—at home, at the office, and on-the-move. New types of connectivity available on these appliances is creating a new kind of networking: spontaneous and instant (ad-hoc) networks of consumer devices that join and leave a network at will. Much of the power in this new wave of appliances lies in their potential to connect to other devices, similar to or different from themselves. The purpose of connecting is not just to form a network, but to do something, like send a file, print a file, access a Web page or perform a transaction.
As these networked appliances become more popular, a problem emerges: to benefit from this kind of connectivity, the appliances need to work together. The appliances and services must be able to discover each other, negotiate what they need to do and proceed with business—with no intervention from the user. In corporate networks, the problem of finding services is often handled by a directory service. A directory-centric approach relies on the availability of a centralized or federated directory of available services. A given member of the network (a client) finds a service by asking the directory to look it up. The client sends an input query (name, address, or other wide-ranging criteria) to the directory, which then responds by sending a list of matching services back to the client.
For this system to work, the directory must be configured with information about available services that are updated either by an administrator, or by new services registering directly with the directory as they become available. This approach is common in traditional wired (or enterprise) networks. For example, the Domain Name Service (DNS), Lightweight Directory Access Protocol (LDAP) and the Common Object Request Broker Architecture (CORBA) Naming Service all provide directory services where a client queries the directory using some criteria. These systems work well for relatively stable environments—where the available services change relatively infrequently compared to the overall set of services. However, these systems are not ideal for ad-hoc networks, where no centralized services (such as directory services) may be present, where the resources of the appliances are themselves limited, and where the network itself is unreliable. This problem led to the development of less directory-centric approaches to the “finding stuff” problem, and, in particular, to the use of service discovery protocols and frameworks, which allow participants in a network to co-operate in advertising and using services with minimal external infrastructure.
Before reading this chapter, you should have a basic understanding of the layers of a Bluetooth stack, in particular Logical Link Control and Adaptation Protocol (L2CAP) and the Radio Frequency Communication (RFCOMM) protocol. You will also need a good understanding of the C programming language, along with some knowledge of Java.
Introduction to Service Discovery
The term service discovery is used to describe the way a networked device (or client) discovers available services on the network. The emphasis is on being able to discover at runtime what services exist, and how to talk to those services. Service discovery makes it possible to have zero configuration networks—where the user doesn’t have to manually configure the network. Instead, the network configures itself as it discovers new available services. The ability to self-configure is critical to ad-hoc networks because:
There is no other infrastructure available, such as a directory service.
The network is unreliable, so connections will appear/disappear.
Nodes themselves—such as the supplier of a service—will move in and out of the network.
Discovery protocols specify the “rules of engagement” between those seeking a service (clients) and the service provider (servers). Discovery protocols aim to minimize the configuration required in the system and to maximize the system’s flexibility. Key features of a discovery protocol are:
“Spontaneous” discovery and configuration of network services
Low (preferably zero) administrative requirements
Automatic adaptation to the changing nature of the network: addition or removal of nodes, or services
Service Discovery Protocols
There are several discovery protocols available, each with different characteristics and a different focus (see Table 5.1 for a summary of service discovery protocols). We will examine these protocols in more detail at the end of this chapter.
Table 5.1
Summary of Service Discovery Protocols
| Protocol | Originator | Comment |
| Salutation | Salutation Consortium | Originally designed for printers, faxes, copiers |
| Service Location Protocol (SLP) | Sun, IETF RFC 2608 | Generic service discovery protocol intended for corporate networks |
| Jini | Sun/JavaSoft | Extends the Java platform and language to allow dynamic, self-configuring networking |
| UPnP and Simple Service Discovery Protocol (SSDP) | Microsoft, IETF Draft | Extends Microsoft Plug and Play to a wider, networked world |
| Service Discovery Protocol (SDP) | Bluetooth SIG | Designed for Bluetooth ad-hoc networks |
Bluetooth SDP
It should be no surprise to discover that service discovery is fundamental to the architecture of the Bluetooth standard. Given that Bluetooth is explicitly designed to facilitate ad-hoc networking between a wide variety of devices, it places a strong emphasis on how those devices discover and use services in the network. The standard does not assume that any form of centralized or federated directory service exists, and so is one of the few discovery protocols that is truly peer-to-peer in nature (see Figure 5.1 for a comparison of service discovery protocols).
The standard defines a Service Discovery Protocol (SDP) that enables a client to directly query a device it detects on the network about the services offered by that device. We have characterized Bluetooth Service Discovery as being protocol-dependent, in that it mandates the use of the underlying Bluetooth communication protocol as the basis for service discovery. However, it’s important to note the following:
Bluetooth SDP could indeed be implemented using other underlying transport mechanisms.
Higher-level protocols (such as TCP/IP) may be run over Bluetooth.
The latter attribute allows Bluetooth clients to use other forms of service discovery (for example, Jini) once they have bootstrapped themselves with initial services in the Bluetooth network. It also means that Bluetooth SDP may be integrated with a number of the other service discovery protocols. We will discuss some examples of this at the end of the chapter.
Architecture of Bluetooth Service Discovery
To understand the architecture of service discovery in Bluetooth, three key elements need to be considered: Service Discovery data structures, the Service Discovery Protocol, and the Service Discovery Application Profile (SDAP). The SDP, a part of the Bluetooth specification, describes both the data structures that represent information about services and the protocol used to communicate between SDP components. SDAP stipulates how SDP can, and should, be used by Bluetooth applications. Next, we’ll discuss the high-level architecture of each of these elements.
The Structure of Service Records
A Bluetooth application user will need to access an entity on a remote device that will do something for the user. The remote entity is called a service. A service might provide information, carry out an action, or access a resource. In order for a user to find information about what services are provided by a device, the device must have an SDP server. The SDP server contains enough information about each supported service to allow it to be accessed by the user (or client). For a particular service (and there may be many services on one device) a service record contains a description of that service. The description takes the form of a sequence of service attributes, each one describing a piece of information about the service. Within the SDP server, each service record is uniquely identified by a service record handle (a 32-bit number). This handle is unique only within the scope of the SDP server.
A service class defines the set of service attributes that a particular service record may have. In other words, a service record is a particular instance of a class of services. For example, a service record whose service class is PrinterClass is a collection of attributes that describe a specific printer service. In fact, a service record may be an instance of multiple different service classes, each with their own set of service attributes. This is useful for building hierarchies of service types. A service class B can be said to be a subclass of service class A if it contains all of the service attributes of A and also adds its own attributes. You can tell what service classes a particular service record instance belongs to by looking at a particular attribute of the record, namely the ServiceClassIDList attribute. The Bluetooth specification defines 15 service attributes that are common to all service records. They’re not mandatory, but when used they have to conform to the definition in the Bluetooth specification. These are the Universal Attribute Definitions, and they include attributes likeServiceClassIDList, ServiceRecordHandle, and ProtocolDescriptorList (a list of protocol stacks that may be used to access the service).
A service attribute is a name-value pair that includes an attribute ID and an attribute value. The attribute ID uniquely identifies the attribute within the scope of the service record. The attribute ID also identifies the type of the associated attribute value (for example, whether the attribute value is a text string, an unsigned integer, a Boolean, and so on). Since an attribute ID is unique only within the scope of a service record, the same ID can be used in different service records to represent different attributes of different types.
An attribute value can contain data of arbitrary complexity, rather than just simple types. This is accomplished using data elements. A data element is made up of a header and a data field. The header field includes a size descriptor and a type descriptor. The size descriptor identifies the size (in bytes) of the data in the data element. The type descriptor identifies the type of data stored in the data element, such as:
Signed twos-complement integer
Universally Unique Identifier (UUID)
Data element alternative (a sequence of data elements from which one element is selected)
One of the valid types for a service attribute ID is a UUID, as defined by the International Organization for Standardization (ISO) [in ISO/IEC 11578:1996 “Information technology – Open Systems Interconnection – Remote Procedure Call (RPC)”]. These 128-bit numbers are guaranteed to be unique across all space and time (actually, unique until A.D. 3400, based on the UUID algorithm).
One of the key uses of UUIDs is as a type for the members of the ServiceClassIDList. That is, each service class is uniquely identified by a UUID. A set of pre-defined service classes is provided in the Bluetooth Assigned Numbers specification. Another use of UUID is as a unique identifier for a particular service instance. This identifier is the ServiceID service attribute. Later, you’ll see that UUIDs play a key role in searching a service discovery server.
The basic structure of the datatypes used by Bluetooth Service Discovery is summarized in the sample SDP server shown in Figure 5.2. For simplicity’s sake, the service class identifiers are shown as text strings rather than UUIDs.
A client wanting to access the service records of a service discovery server can do so in one of two ways: they can search for a particular service record or they can browse the available service records. The search capability of the Service Discovery Protocol is simple but effective. It allows a client to specify a list of UUIDs and then retrieve a list of service record handles for service records, whose attributes contain all of the UUIDs specified by the client. Later in this chapter, you’ll see how this mechanism is used in practice.
To support the browsing of service records, Bluetooth Service Discovery uses special service attributes and service classes that allow for the construction of a browseable hierarchy. A service class called BrowseGroupDescriptor is defined. A service record that is an instance of this class is analogous to a directory in a file hierarchy—it’s a place in a hierarchy where related services can be stored, or where child BrowseGroupDescriptor records can be stored. The BrowseGroupList attribute of a service record specifies the list of BrowseGroupDescriptors that a service record instance is a member of (it may be in more than one). The members of this list attribute are the UUIDs of the BrowseGroupDescriptor records. So, a client can browse the Service Discovery Server by specifying the UUID of the Browse Group of interest as a search pattern to the server. This search will match all service records that have specified this BrowseGroupDescriptor UUID in their BrowseGroupList attribute.
Before looking at the Service Discovery Protocol, it’s worth considering the semantics of a service attribute value. Although the Bluetooth specification says that an attribute ID describes both the type and the semantics of an attribute value, this is somewhat sketchy. The semantics of an attribute value are not, in fact, codified within a service attribute. Instead, the meaning of a particular attribute value is understood by the client application once it knows what service class the attribute’s service record belongs to. For example, a client accessing a service record of service class 0x1113 (the last 16 bits of the UUID for the Wireless Application Protocol [WAP] service class) must know, at application development time, that the service attribute with attribute ID 0x0306 is the attribute that identifies the Internet Protocol (IP) network address of a WAP Server. This information is not made available to it at runtime for presentation to the end user, for example. If you’re familiar with richer software abstractions for discovering network services, this example illustrates the opportunities for an abstract layer of primitives to hide some of the programming detail from an application developer.
The Service Discovery Protocol
So, how exactly do clients discover services in their local areas? Services are discovered using the Service Discovery Protocol, a simple protocol that communicates between SDP clients and servers. It can be implemented over any reliable packet-based transport layer, though it’s typically implemented over the Logical Link Control and Adaptation Protocol. The Service Discovery Protocol includes a set of Protocol Data Units (PDUs) that contain the basic requests and responses needed to implement the functionality of Bluetooth Service Discovery. The actual PDU format and protocol are not directly relevant to an application programmer who will work exclusively through the API of a Bluetooth stack. But it’s worth summarizing the protocol here since the stack API is usually derived from the structure of underlying PDUs.
An SDP PDU contains a PDU ID, a transaction ID, and a parameter length in its header. Its body contains some number of additional parameters—what these parameters are depends on which type of transaction the PDU contains. The PDU ID identifies the type of transaction. The following are transaction types supported by the protocol:
With the exception of SDP_ErrorResponse, the transaction types are Request/Response pairs. For an SDP implementation to match an incoming Response with a previously issued Request, a number is assigned to the Request that is unique among currently outstanding Requests. This is the Transaction ID. The SDP_ErrorResponse PDU is generated if a Request PDU is improperly formatted, or if some other error has prevented the generation of an appropriate Response PDU. The parameters of this PDU will give you some information about the nature of the error. The ServiceSearch transaction, embodied in a Request/Response pair, searches for services containing service records that match a submitted search pattern. The search pattern (of UUIDs) is passed as a Request PDU parameter; the service record handles of the matching service records are then passed in a Response PDU parameter. The ServiceAttribute transaction retrieves particular service attributes from a specified service record. The parameters of the Request PDU specify the service record handle of the target record, as well as the list of attribute IDs to be retrieved. A list of attribute values is passed in a parameter in the Response PDU. The capabilities of the two preceding transactions are combined in the ServiceSearchAttribute transaction. This transaction retrieves attributes matching the specified Attribute list from the service records matching a specified search pattern.
Developing An Abstract C API for SDP
The Service Discovery Protocol of the Bluetooth specification identifies the protocol data units exchanged between protocol peer entities. Ultimately, it’s not the role of the specification to provide an API. So, we start here by providing an API in C that covers the low-level functionality of the protocol. Coding examples in the rest of the text reference this API.
The API uses an “object-oriented” flavor with liberal use of opaque types. All memory management is performed by the API implementation.
First, we look at the API needed from the server point of view—in other words, an API allowing for the creation and advertising of service records.
Next, we present the API from the client’s point of view—in other words, an API for the retrieval of service records and their attributes in order to use the information.
Discovering Services
We’ve put together a practical guide to help you make sense of using SDP to advertise and discover services within a network. Following on the previous section, we’ll create and advertise a service record on a server device using the API in the earlier section titled “Developing An Abstract C API for SDP.” We’ll then connect to the SDP server and find a specific service record or browse service records from a client device. But first, let’s discuss how to use the Class of Device (CoD) to assist in short-circuiting the service discovery process.
Short-Circuiting the Service Discovery Process
Every Bluetooth device can contain a Service Discovery Server (SDS) that advertises the services available on that particular device, be it a mobile phone, PDA, or something else. It can do this by making available the service records that describe those services. A client starts by finding a Bluetooth device. Then they use the SDS to pinpoint a service or to browse available services. Bluetooth device discovery can help short circuit this service discovery process. During the device inquiry process (before any ACL connection is made between devices), the low-level Frequency Hopping Synchronization (FHS) packet is exchanged between discovering and discovered devices. One of the pieces of information in the FHS packet is the Class of Device. The CoD is a 24-bit value composed of three parts: Major Device Class, Minor Device Class and Major Service Class. Checking these values can be beneficial when determining if a connection should be opened to the device. For example, if a PDA is looking for a printer, it can tell immediately from the CoD if a discovered device can print. It doesn’t have to open a connection to the SDS and check the Service Discovery Database (SDDB) of the discovered device. So, a client will know if a device hosts the required service before a connection is made. This “short-circuiting” of service discovery is powerful and increases the speed and efficiency of service discovery. The Bluetooth SIG controls the values of the three CoD attributes. For further information on the CoD, see [SPEC], part B, section 4.4.1.4, and [ASSN] section 1.2.
Creating and Advertising a Service
If the CoD indicates that a service or category of service is available, then a connection can be opened to the SDS on the discovered device. This connection can be used to find an exact match service or to determine the precise mechanism to interact with a service. In general, the service record should only be advertised when the service is available, and the service itself should be responsible for this. (The service is advertised as part of a service bootstrapping process, and conversely, advertising the service is stopped as part of service termination.)
To create a service record, individual data elements that correspond to the attribute values of the service attributes need to be constructed. They are then added into the service record. The following piece of code in this section creates a service record for an Example service. The Example service belongs to the Example service class. This service class has a class description that defines the contents of the service record that defines the Example service. The service description in Table 5.2 lists each of the attributes contained in an Example service record, including the name, ID, value type, and meaning.
a) This service attribute has the definition as given by the corresponding universal attribute definition, available in the SDP protocol specification [SPEC] part E, section 5.1.
b) This service attribute provides a list of UUIDs that identify the classes (or class definitions) of which this service is an instance. In this case, the class list contains the single ID for the Example class.
c) This service attribute provides a list of the protocols and protocol attributes needed for a client to access this service. In this case, the protocol list contains the single Bluetooth protocol L2CAP, and its attribute is the Protocol Service Multiplexor (PSM) value for the service (this PSM value is assigned dynamically at runtime by the L2CAP implementation).
d) This service attribute contains a list of natural languages supported, and for each language a triple: the ISO language identifier, the encoding used for attributes in this language, and the base ID to be used for all attributes that encode natural language strings in this language (see ServiceName).
e) This service attribute contains the name of the service in a natural language. The offset is added to the base language ID as given in the LanguageBaseAttributeIdList to give the ID for the ServiceName attribute in the given language.
The code samples that follow are pseudo-code samples that use our abstract C API. Variables are typically declared close to their first use rather than in an initial declaration block. This is illegal in C (though not in C++), but it improves readability and is an aid to understanding.
As you can see, creating and advertising individual service records can be an involved process. In an upcoming section, we will explore how the API can be improved with “helper” functions based on the use of the Bluetooth profiles. Now, we’ll look at the client side of service discovery and the two ways a service can be discovered: by looking for a specific service or by browsing.
Discovering Specific Services
The Bluetooth Service Discovery Protocol allows for services to be discovered on the basis of a series of attributes with values of type UUID. In reality, when talking about discovering specific services, one of the most important attributes of a service, if not the most important, is the ServiceClassIDList. It provides a list of the classes to which the service belongs. For example a Headset service as defined by the Headset profile belongs to ServiceClass Headset and ServiceClass Generic Audio. The following code is used to search for an instance of the Example service, as defined in the previous section.
If the service class ID used to perform the search represents the most specific class needed, then any service represented by the returned service records can be used. Individual attributes which further refine the search may be given, but with our C API, they must be attributes whose values are of type UUID. To provide a search facility using non-UUID type attributes would mean writing this code yourself. This could be done by performing a base search with the UUID types, and then accessing the appropriate non-UUID attributes and comparing them with the values given. The next section shows how this could be done, by discussing how individual service attributes are examined.
Using Service Attributes
Once a client has retrieved service records, the service record’s attributes can be examined. The client can retrieve the service name attribute for displaying to the user in the language of the Locale of the user machine. For example, this is how a user in a French Locale would do it:
Browsing for Services
If the service Class ID for a particular service is unknown, or if a client wants to browse the services on a device, the service discovery protocol provides a way to do this. To be “browseable,” a service must be explicitly marked as browseable with a BrowseGroupList attribute in its service record. If the service record doesn’t have this attribute, it can’t be browsed. The BrowseGroupList attribute contains the list of UUIDs that identifies the groups that a service belongs to. A well-known root browse group UUID (called PublicBrowseRoot) is defined by the SIG (see the [ASSN] section 4.4). Because the root is a well-known UUID, a client knowing nothing about services always has a place to start browsing. A group is defined by a BrowseGroupDescriptor service record. This service record has two attributes of interest: the GroupID (whose UUID value is contained in a service’s BrowseGroupList), and the BrowseGroupList attribute, which specifies the list of browse groups to which this group itself belongs. The BrowseGroupDescriptor service class definitions are given in [SPEC], part E, section 5.3, and its service class ID is defined in the [ASSN], section 4.4.
If you want the Example service to be in a Sample Services group—a group available from the root browse group—you would define a Browse group with this name and some GroupID UUID to tag the group. You’d then insert this tag into the BrowseGroupList of the Example Service. Of course, the BrowseGroupList of the Sample Services group must contain the root browse group. The following code shows how the Sample Service browse group is created and how the Example service is put into that group.
The Example Service (as defined in the previous section) needs to have the following code added in order to be included in the Sample Group. The code should be added just before the service record is advertised.
This code makes the Example Service browseable from the Sample Browse Group.
Clients can now discover the service by browsing on their mobile devices. The specific client code for doing this is not given as it will follow the template given already in the earlier section “Discovering Specific Services.”, but it employs the following algorithm:
A service search is performed using the UUIDS for both the Public Browse Group (defined by the SIG as a 16-bit UUID of value 0x1002), and the BrowseGroupDescriptorServiceClassId (defined by the SIG as a 16-bit UUID of value 0x1001). This specific search should yield only those BrowseGroupDescriptors service records that are browseable from the public root. In this instance, given the preceding Example code, this search would yield one record, the SampleGroup record. From this, we extract the Group ID, and perform another search using this UUID as the sole UUID in the search pattern. This will yield any service records that are members of the group—in other words, which have the Group ID in their BrowseGroupList (in addition to the BrowseGroupDescriptor service record itself). In this instance, the Example service record will be returned.
Service Discovery Application Profile
Bluetooth profiles define usage scenarios for Bluetooth devices as well as the functionality that should be available from the underlying protocol stack. The profiles don’t present individual programming interfaces (which would be platform-dependent), but instead present a platform-neutral description of functionality to be provided by an application that realizes the profile.
In the previous section, we presented a C-based API for service discovery. If you are familiar with the SDP protocol, you’ll notice that the API is based on the description of the protocol PDUs exchanged between the protocol’s client and server entities. It’s not based on the Service Discovery Application Profile, for reasons that will become clear shortly. The SDAP is a usage scenario describing the functionality a Service Discovery Application (SrvDscApp) should provide to an end user on a Local Device (LocDev) so that user can discover services on a Remote Device (RemDev). The SDAP doesn’t specify an API that will provide this functionality, but suggests primitives that can be mapped to an API. This differs from most other profiles that describe functionality without using primitives. The primitives are:
a) Enumerate Remote Devices This primitive is used for device discovery and would likely be implemented by the baseband inquiry mechanism.
b) Search Services This primitive is used to search for specific services based on the class of the service or the class of service and some specific attributes of the service. It would likely be implemented by the searchServices functionality (shown in the previous section).
c) Browse Services This primitive is used to browse services according to the browse groups. It would likely be implemented by functionality (as shown in the Browsing Services section).
d) Terminate Primitive This primitive is used to terminate a previously started primitive.
The SrvDscApp is only necessary on the LocDev device—the client device. Though the profile says devices without user interfaces are not candidates for LocDev, devices can still use the procedures defined by the profile to exercise the SDP protocol. For instance, where another application profile (such as Serial Port Profile) is using SDP to recover applicable service records. We look at this scenario in the next section, “Service Discovery Non-Application Profiles.” Primitives c and d give the necessary procedures for this usage (which are covered by the API in the previous section). Adding APIs to cover the first two primitives creates an interface that achieves the functionality of the SDAP.
Service Discovery Non-Application Profiles
No, it’s not a misprint. The title is deliberately jarring to draw your attention to the fact that most profiles detailed in the Bluetooth specification have a service discovery component. This component specifies the structure and content of the service record that accompanies the service (or application) that realizes the profile. The SDAP (in addition to dealing with application functionality for service discovery) specifies the procedures that an application realizing a profile must use to perform service discovery.
If these procedures are upheld, interoperability is ensured. For example, an application that realizes a profile should be able to advertise its service via the Service Discovery Server and be found by any client on any device that accesses the profile’s SDP record—according to the service discovery procedures described by the SDAP. This example of an individual profile’s service discovery component (see Table 5.3) describes the Serial Port profile’s service record.
The serial port profiles describe a usage scenario where two applications, A and B, are communicating via a serial cable emulation. Device B, which acts the role of the server, must register the previous record with the SDDB. As the profile states, this is the most generic type of service, which indicates nothing of the application functionality. So, additional service class IDs can be inserted into the ServiceClassIDList. As you saw in the previous section, the amount of code needed to create and advertise a service record can be extensive. The API offered to the developer can be improved by providing an API for the serial port profile itself:
This function performs most of the drudgery of the previous section, and provides a service record ready to be registered with the SDDB. Of course, any updates or extra information needed can be added with the usual API.
Java, C, and SDP
The Bluetooth Service Discovery Protocol doesn’t prescribe an API for programmers to use. Although both the SDP transactions and data representation imply the structure of an API, Bluetooth stack implementations vary widely in the APIs and programming abstractions they provide. Some stacks represent SDP transactions asynchronously, through a function call for making a request and a separate callback for replies. Others provide one synchronous function that blocks the caller while waiting for a reply. Stacks also differ in the level of abstraction of their function calls. Some stacks provide functions that return, in essence, raw SDP PDUs that the programmer must then disassemble and interpret—for example, the abstract C API examined earlier. Others return structured data from which the relevant data elements are more easily extracted. Some stacks provide richer abstractions that allow a programmer to carry out simple, routine tasks in fewer steps (for particular profiles, for example). When choosing a stack, it’s wise to consider the design and richness of an SDP API to ensure that you can write readable, maintainable code as efficiently as possible, without giving up access to all the features and flexibility you need. Is it more important for you to be able to create, populate, and advertise a service record in one or two function calls, or to have full control over each PDU element in minute detail?
When considering abstraction levels, programming language is a key choice. Most stacks expose C APIs, while others provide Java or C++ interfaces. Service Discovery is arguably the Bluetooth component best placed to take advantage of the richness and usability of the Java programming platform. Java, in particular the Java 2 Platform Micro Edition (J2ME), is rapidly becoming the platform of choice for developing embedded wireless applications. This is evidenced by its adoption by industry heavyweights Nokia, Motorola, Siemens, Matsushita, Sharp, and others. It provides a level of portability, maintainability and ease of programming that languages such as C do not. Of particular relevance here is the potential for rich SDP abstractions that can largely remove the programmer from the detail of PDUs and completely remove them from error-prone pointer and memory manipulation.
As part of Java Community Process (JCP)—the vehicle for standardizing the Java platform—a set of standard Java APIs for Bluetooth is being developed. The Java Specification Request (JSR) 82 Expert Group is carrying out this work. Motorola chairs the group, with contributing experts from a number of companies, including Rococo Software. At the time of writing, the first full version of this specification is due for publication at the end of 2001. Implementations of this standard will allow programmers to implement Bluetooth applications within the J2ME environment in a standard and portable way.
Historically, Java as a programming language for embedded applications has suffered most from one criticism—it was too slow and bulky. This was true in its early versions, primarily since it is an interpreted language and the Virtual Machines in which applications ran weren’t optimized, but this has changed. Many developments contributed to Java becoming a key open platform for embedded application development in general, and wireless development in particular. Virtual Machines have been optimized for such environments—for example, the “KVM” in Sun’s J2ME Connected Limited Device Configuration (CLDC). Virtual Machines have found their way into silicon, with Java bytecodes being interpreted directly on the chip. The Jazelle product suite from ARM and the MachStream platform from Parthus are good examples of this. Java has also been tailored for particular platforms, with precompilers providing the performance power required by embedded applications without sacrificing the advantages of the Java platform.
In addition to the abstractions possible for SDP implementations in Java, the J2ME platform provides a useful Input/Output (I/O) framework that can be applied to Bluetooth application development. A key element of the J2ME specification is the Generic Connection Framework (GCF). It’s a mechanism that allows a programmer to create different types of networking connections through a standard Connector interface. In a Bluetooth extension to the GCF, a Connector could create instances of Bluetooth-specific connection classes, say RFCOMMConnection or L2CAPConnection. Since this is a standard networking framework used by all J2ME applications, programmers can quickly produce Java Bluetooth applications by applying existing techniques and design patterns.
Rococo Software (www.rococosoft.com) provides an implementation of the standard Java Bluetooth APIs, along with a simulator that allows programmers to run their applications and test their use cases without the need for underlying Bluetooth hardware or stacks.
Other Service Discovery Protocols
Let’s elaborate on some other discovery protocols: the Salutation Consortium’s Salutation service discovery protocol, the Internet Engineering Task Force (IETF)’s Service Location Protocol (SLP), Microsoft’s Universal Plug and Play (UPnP), and Sun Microsystems’ Jini.
Salutation
Formed in 1995 by a group of U.S. and Japanese companies, the Salutation Consortium defines an architecture for networking devices, applications, and services. The core focus of the group (and most implementations of the standard to date) has been to enable seamless access to office equipment such as fax machines, printers, copiers, and so on. However, the standard has evolved to include phones, PDAs, and general electronic equipment. The Salutation architecture defines a uniform way of labeling devices with descriptions of their capabilities and with a single, common method of sharing that information.
The architecture is composed of Salutation Managers (SLMs), which coordinate all aspects of registering new services and searching for services on behalf of clients. It also contains Transport Managers (TMs), which sit between the SLMs and the rest of the system (see Figure 5.3 for an illustration of the Salutation architecture). This architecture allows Salutation to be “transport independent.” That is, a separate TM may be written for each underlying transport required, and the SLM, which provides the core functionality of the system, remains transport neutral. SLMs act as repositories for local service information as well as brokers who seek services on behalf of clients. SLMs periodically check available services to update their repositories. Table 5.4 outlines the functions of the Salutation protocol.
Table 5.4
| Function | Description |
| Announcing Presence | Through cooperation between Salutation Managers (SMs). Register with a known, probably local SM. |
| Discovering Other Services | Send queries to the local SM. SMs coordinate and return results. |
| Describing Services | Structured description of services as functional units, which in turn contain attribute records. Functional units identify the “type” or “features” of a service. Attributes provide much more detail. Standard functional unit definitions exist for well-defined services (print, fax). |
| Self Configuration | Salutation does not address this issue. |
| Invoking Services | Flexible. Provides for vendor-specific protocols, SLM-managed sessions providing transport independence, as well as defined (standard) data and protocols for selected functional units. The defined APIs can be implemented on most platforms. |
| Transports | Transport independent architecture |
| More Information | www.salutation.org |
Service Location Protocol
Service Location Protocol (SLP) originated from a working group of the Internet Engineering Task Force (IETF). It’s a language-independent protocol for automatic resource discovery on IP-based networks. SLP is designed to be lightweight and decentralized with minimal administration requirements. SLP (like some of the other service discovery protocols) makes use of UDP/IP multicast functionality in TCP/IP. This makes it particularly useful for networks where there is some form of centralized administrative control, such as corporate and campus networks. The discovery mechanism is based on service attributes, which are used to characterize a service. The SLP architecture has three main components:
User Agent (UA) Performs service discovery on a client’s behalf (which might be a user or an application).
Service Agent (SA) Advertises the service’s location and characteristics on behalf of services, and registers this information with the Directory Agent.
Directory Agent (DA) Accumulates service information received from SAs in its repository and responds to service requests from UAs.
User Agents send a Service Request describing the service they seek to one or more Directory Agents. The Directory Agents respond with Service Replies describing services that match the query (see Figure 5.4).
Services are located by their address, the so-called service: URL. The address format is composed of the prefix service:, the service type, the network address and, optionally, a path. Service types can be of concrete or abstract type. For example, they may either name a particular service type (which is usually a particular protocol), or name a family of service types. For example, in the service: URL:
service:printer:lpr://www.rococosoft.com/laserprinter
the service type is service:printer:lpr, a service type name with abstract type printer and concrete type printer:lpr.
SLP doesn’t mandate the presence of a DA. Users Agents will try to locate a DA when they first start up, but if they don’t find any, they will try to operate directly with service agents. When a DA starts to operate on the network, it advertises its presence and all agents that receive the advertisement can start using the DA. Small networks with few services and users may not require a DA on the network. The DA is designed to allow the system to scale in larger networks without imposing undue network traffic. Both Sun Microsystems and Hewlett Packard, among others, have implemented SLP in their products.
Table 5.5 outlines the functions of SLP.
Table 5.5
| Function | Description |
| Announcing Presence | Register with DA. |
| Discovering Other Services | Query DA. Can also multicast a service request in the absence of a DA. |
| Describing Services | Attribute value pairs. |
| Self Configuration | Does not address this area. An IP device when plugged onto a network will have to be configured with an IP address, subnet mask and optionally a gateway and DNS server. |
| Invoking Services | Does not address this area. |
| Transports | TCP/IP |
| More Information | www.srvloc.org |
Jini
Jini is a distributed service-oriented architecture developed by Sun Microsystems. Jini is considered an extension of the Java language and platform. The key concept in Jini is the service, which can be almost anything: a process, a piece of hardware, a communications stream, or a user. Services can be collected together to achieve a task. A collection of Jini services forms a Jini federation: services coordinate with each other within the federation and can join and leave a federation dynamically. Services communicate with each other using a service protocol, which is defined as a set of interfaces in Java. The standard itself provides a base set of interfaces to facilitate core interaction between services—a given implementation of the system may extend these as needed.
A key component of Jini is the lookup service. Services are found and resolved by a lookup service. The lookup service is the central bootstrapping mechanism for the system and provides the major point of contact between the system and the system’s users. The lookup service maps interfaces indicating the functionality provided by a service to sets of objects that implement the service. Additionally, descriptive entries associated with a service allow more fine-grained selection of services based on properties people understand. A service is added to a lookup service by a pair of protocols called discovery and join—first the service locates an appropriate lookup service (by using the discovery protocol), then it joins it (by using the join protocol). Having joined, a service is now a member of a federation.
Communication between services occurs using Java Remote Method Invocation (RMI). RMI is a Java-based extension to traditional remote procedure call (RPC) mechanisms. One important extension is that it enables actual code, not just data, to be exchanged between services.
This allows services to provide not only a description of the service they offer to the lookup service, but also the actual client-code (called a service object) that is configured to access the service (see Figure 5.5). Clients can then receive this service object as part of the lookup, and access the service directly.
Table 5.6 outlines the functions of Jini.
Table 5.6
| Function | Description |
| Announcing Presence | Unicast/Multicast to Jini lookup services and subsequent registration. |
| Discovering Other Services | Query lookup service(s) with properties of services of interest. |
| Describing Services | Registration information composed of attribute/value pairs. |
| Self Configuration | Does not directly address this area. An IP device when plugged onto a network will have to be configured with an IP address, subnet mask, and optionally a gateway and DNS server. From then on, the lookup services can be used. |
| Invoking Services | Download service proxy and use proxy to access service. |
| Transports | TCP/IP and proxies to other transports. |
| More Information | www.jini.org |
Universal Plug and Play (UPnP)
In January 1999, Microsoft announced its Universal Plug and Play (UPnP) initiative. The UPnP initiative seeks to extend the original Microsoft Plug and Play peripheral model to a highly-dynamic world of many network devices supplied by many vendors. UPnP defines a set of lightweight, open, IP-based discovery protocols that allow appliances (telephones, televisions, printers, game consoles, and so on) to exchange and replicate relevant data between themselves and the PCs on the network. UPnP is a “wire-only” protocol—it defines the format and meaning of what is transmitted between members of the network and says nothing about how the standard is actually implemented. It requires TCP/IP and HTTP to be present to operate.
UPnP uses the Simple Service Discovery Protocol (SSDP) to discover services on IP-based networks. SSDP can be operated with or without a lookup or directory service in the network. SSDP operates on the top of the existing open standard protocols, using the HTTP over both Unicast UDP and Multicast UDP.
When a service wants to join the network, it first sends out an advertise (or announcement) message notifying the world about its presence. In the case of multicast advertising, the service sends out the advertisement on a reserved multicast address. If a lookup or directory service is present, it can record the advertisement. Meanwhile, other services in the network can directly see these advertisements as well. The “advertise” message contains a URL that identifies the advertising service and a URL to a file that provides a description of the advertising service. Devices can also cancel advertisements in order to leave a network.
When a service client wants to discover a service, it can either contact the service directly through the URL provided in the service advertisement, or it can send out a multicast query request.
Table 5.7 outlines the functions of UPnP.
Table 5.7
| Function | Description |
| Announcing Presence | Use SSDP and Directory service proxies (optional). |
| Discovering Other Services | Listen to SSDP multicast channel directly or contact a directory service proxy. |
| Describing Services | XML description of the service is made available at a specified URL. |
| Self Configuration | DHCP (if available) or AutoIP, and multicast DNS. |
| Invoking Services | UPnP does not address this area. |
| Transports | TCP/IP and proxies to other transports |
| More Information | www.upnp.org |
The Future of SDP
The SDP protocol is a low-level, lightweight, compact, and efficient service discovery protocol. Its inclusion in the Bluetooth protocol stack was considered critical to Bluetooth technology’s success as its use spread across many types of devices exporting varied services. But, as you’ve seen, SDP is one of many protocols that deal with the concept of service discovery. One of the key issues is interoperability of the various protocols. One of the Bluetooth white papers [Mill99] deals with the mapping of the SDP protocol to the Salutation service discovery architecture. In the immediate future of SDP, the Bluetooth SIG is defining the Extended Service Discovery Protocol. This “new” protocol is expressed as a profile (dependent on the Generic Access Profile) and allows the Universal Plug and Play (UPnP) protocol suite to run over a Bluetooth stack. The suite runs directly over L2CAP using a connection management layer (to provide flow control, and so on), or over IP, either as currently defined by the LAN Access profile or using the new Personal Area Profile (PAN). As such, the core SDP protocol remains unchanged, but it is used to discover the UPnP service that can then be used. Though not proposed at present, a similar profile could be developed for the Jini service discovery protocol.
Summary
The problem of how a device locates useful services and applications in a distributed network is common in many domains. In Bluetooth, it is the Service Discovery Protocol (SDP) that addresses this problem. Unlike many other lookup or discovery protocols, SDP is a true peer-to-peer protocol that does not rely on centralized, third-party infrastructure. The service record is the unit used to describe a Bluetooth Service. Service records are made up of attributes that capture information about a service. These attributes may contain data that is reasonably complex in structure, through the use of data elements, in addition to simple types.
There are a number of ways to query the services that a particular Bluetooth device supports. The first approach is to use the Class of Device (CoD) which may be extracted from the Frequency Hopping Synchronization (FHS) packet. The CoD contains, among other information, the Major Service Class of the device. This may be used to decide if a remote device is of interest to the inquiring device, and helps to short-circuit the service discovery process. Secondly, a client may search the service discovery server. They may search for specific attributes—most importantly the ServiceClassIDList attribute. A client may also search for service records containing attributes with values that match a specified list of UUIDs. Finally, a client may browse a hierarchy of service records by searching for a particular BrowseGroupDescriptor (or “directory” in the hierarchy).
Bluetooth SDP does not mandate a particular programming interface or set of programming abstractions. We presented an abstract C API that exposes the functionality of SDP to the programmer. We examined how, using this API, we would create and advertise a service, discover specific services, use service attributes and browse for services. There are opportunities for richer APIs that provide “helper” functions based on the use of Bluetooth profiles. Such functions could take the drudgery out of some of the coding effort.
The Service Discovery Application Profile (SDAP) is a usage scenario describing the functionality of a Service Discovery Application. It consists of suggested primitives that may be implemented in terms of the underlying SDP API. These primitives are used both by local devices discovering services on remote devices, and also by other Bluetooth profiles that need to advertise their services via SDP.
Though many Bluetooth stack implementations expose a C language API, Java is gaining ground as a platform for developing embedded wireless applications. As part of the Java Community Process, standard Java Bluetooth APIs are being defined. They will be components of the Java 2 Platform, Micro Edition (J2ME).
Future developments in Bluetooth SDP include the definition by the Bluetooth SIG of the Extended Service Discovery Protocol. This Profile will provide a mechanism for integrating the Universal Plug and Play (UPnP) protocols with Bluetooth SDP.
Solutions Fast Track
Introduction to Service Discovery
The term service discovery is used to describe the way a networked device (or client) discovers available services on the network. Service discovery makes zero configuration networks possible—the user doesn’t have to manually configure the network.
Key features of a discovery protocol are: spontaneous discovery and configuration of network services, low (preferably zero) administrative requirements, automatic adaptation to the changing nature of the network (addition or removal of nodes or services), and interoperability across platforms.
Bluetooth Service Discovery is protocol-dependent; it mandates the use of the underlying Bluetooth communication protocol as the basis for service discovery. However, Bluetooth SDP could indeed be implemented using other underlying transport mechanisms, and higherlevel protocols (such as TCP/IP) may be run over Bluetooth.
Architecture of Bluetooth Service Discovery
For a particular service (and there may be many services on one device) a service record contains a description of that service. The description takes the form of a sequence of service attributes, each one describing a piece of information about the service.
Within the SDP server, each service record is uniquely identified by a service record handle. A service class defines the set of service attributes that a particular service record may have. In other words, a service record is a particular instance of a class of services.
A service attribute is a name-value pair that includes an attribute ID and an attribute value. The attribute ID uniquely identifies the attribute within the scope of the service record.
An attribute value can contain data of arbitrary complexity, rather than just simple types. This is accomplished using data elements. A data element is made up of a header and a data field.
The Service Discovery Protocol includes a set of Protocol Data Units (PDUs) that contain the basic requests and responses needed to implement the functionality of Bluetooth Service Discovery. An SDP PDU contains a PDU ID, a transaction ID, and a parameter length in its header. Its body contains some number of additional parameters, depending on which type of transaction the PDU contains.
Discovering Services
Every Bluetooth device can contain a Service Discovery Server (SDS) that advertises the services available on that particular device, be it a mobile phone, PDA, or something else. It can do this by making available the service records that describe those services.
The Bluetooth-defined Class of Device (CoD) value can tell a discovering device if a connection should be opened to the discovered device—it doesn’t have to open a connection to the SDS and check the Service Discovery Database (SDDB) of the discovered device, “short-circuiting” service discovery.
The Bluetooth Service Discovery Protocol allows for services to be discovered on the basis of a series of attributes with values of type UUID. In reality, when talking about discovering specific services, one of the most important attributes of a service, if not the most important, is the ServiceClassIDList.
Service Discovery Application Profile
The SDAP is a usage scenario describing the functionality a Service Discovery Application (SrvDscApp) should provide to an end user on a local device (LocDev) so that user can discover services on a Remote Device (RemDev). The SDAP doesn’t specify an API that will provide this functionality, but suggests primitives that can be mapped to an API.
Most profiles detailed in the Bluetooth specification have a service discovery component that specifies the structure and content of the service record that accompanies the service (or application) and which realizes the profile. The SDAP (in addition to dealing with application functionality for service discovery) specifies the procedures that an application realizing a profile must use to perform service discovery. If these procedures are upheld, interoperability is ensured.
Java, C, and SDP
As part of Java Community Process (JCP), a set of standard Java APIs for Bluetooth is being developed and is due for publication at the end of 2001. Implementations of this standard will allow programmers to implement Bluetooth applications within the J2ME environment in a standard and portable way.
A key element of the J2ME specification is the Generic Connection Framework (GCF), a mechanism that allows a programmer to create different types of networking connections through a standard Connector interface. This would allow programmers to quickly produce Java Bluetooth applications by applying existing techniques and design patterns.
Other Service Discovery Protocols
The Bluetooth SDP may be integrated with a number of the other service discovery protocols, including Salutation, UPnP, Service Location Protocol (SLP), and Jini.
The Salutation architecture defines a uniform way of labeling devices (fax machines, printers, copiers, and also phones, PDAs, and general electronic equipment) with descriptions of their capabilities and with a single, common method of sharing that information.
Salutation is “transport independent,” that is, a separate Transport Manager may be written for each underlying transport required, and the Salutation Manager, which provides the core functionality of the system, remains transport neutral.
SLP is a language-independent protocol for automatic resource discovery on IP-based networks. Like some of the other service discovery protocols, it makes use of UDP/IP multicast functionality in TCP/IP. This makes it particularly useful for networks where there is some form of centralized administrative control, such as corporate and campus networks.
Jini is a distributed service-oriented architecture, considered an extension of the Java language and platform. Services communicate with each other using a service protocol, which is defined as a set of interfaces in Java. The standard itself provides a base set of interfaces to facilitate core interaction between services. A key component of Jini is the lookup service.
Communication between services in Jini occurs using Java Remote Method Invocation (RMI). RMI is a Java-based extension to traditional remote procedure call (RPC) mechanisms. One important extension is that it enables actual code, not just data, to be exchanged between services.
Universal Plug and Play (UPnP) defines a set of lightweight, open, IP-based discovery protocols that allow appliances to exchange and replicate relevant data between themselves and the PCs on the network. UPnP is a “wire-only” protocol—it defines the format and meaning of what is transmitted between members of the network and says nothing about how the standard is actually implemented. It requires TCP/IP and HTTP to be present to operate.
UPnP uses the Simple Service Discovery Protocol (SSDP) to discover services on IP-based networks. SSDP can be operated with or without a lookup or directory service in the network. SSDP operates on the top of the existing open standard protocols, using the HTTP over both Unicast UDP and Multicast UDP.
The Future of SDP
SDP is one of many protocols that deal with the concept of service discovery. One of the key issues is interoperability of the various protocols.
In the immediate future of SDP, the Bluetooth SIG is defining the Extended Service Discovery Protocol. This “new” protocol is expressed as a profile (dependent on the Generic Access Profile) and allows the Universal Plug and Play (UPnP) protocol suite to run over a Bluetooth stack. Though not proposed at present, a similar profile could be developed for the Jini service discovery protocol.
Frequently Asked Questions
The following Frequently Asked Questions, answered by the authors of this book, are designed to both measure your understanding of the concepts presented in this chapter and to assist you with real-life implementation of these concepts. To have your questions about this chapter answered by the author, browse to www.syngress.com/solutions and click on the “Ask the Author” form.
A: The Bluetooth Service Discovery Protocol (SDP) is a distributed, peer-to-peer lookup mechanism for discovering which services are supported by inrange Bluetooth devices. It is defined in the Bluetooth Specification.
Q: How are services represented in SDP?
A: A service on a Bluetooth device is described in an SDP service record, which is stored in the device’s “Service Discovery Database.” A service record consists of service attributes, each of which describes some information about the available service.
Q: How does Class of Device (CoD) relate to SDP?
A: The CoD may be retrieved from a Frequency Hop Synchronization (FHS) packet. This information contains, among other things, the Major Service Class of the device. This tells the discovering device what “kind” of device it has discovered (e.g., a printer, an access point, and so on) Using this information, the discovering device can rule out certain devices that are not interesting, and only query the Service Discovery Databases of those devices that are interesting. For many application types, this is likely to result in an efficiency gain.
Q: What’s the difference between SDP and SDAP?
A: SDP is a part of the core Bluetooth specification and defines the data representation of SDP data structures as well as the set of transactions used to communicate between SDP clients and servers. The Service Discovery Application Profile (SDAP) is one of the Bluetooth profiles defined by the Bluetooth SIG. It describes usage scenarios for a Service Discovery Application, and suggests primitives for achieving these scenarios that may be implemented in terms of the underlying SDP API.