Service Discovery in Bluetooth

Eugene A. Gryazin Group for Robotics and Virtual Reality Department of Computer Science Helsinki University of Technology gryazin@cs.hut.fi

ABSTRACT This document is devoted to organization of different levels of Service Discovery

Protocol at Bluetooth, and as to relationship of devices at usage of it.

Keywords Service Discovery Protocol, SDP, Bluetooth, Service Class, Service Attribute, SDP Client, SDP Server

1.

INTRODUCTION

Service Discovery Protocol (SDP) enables network devices, applications, and services to seek out and find other complementary network devices, applications, and services needed to properly complete specified tasks. The network computing industry has eagerly embraced technologies in this field, welcoming an ever-increasing variety of new service discovery protocols. In this paper will described Bluetooth SDP [1] offer their own unique service discovery methods as part of their protocol stack. Sun has enriched Java with its introduction of Jini. Microsoft promotes Universal Plug and Play (UPnP). The IETF has adopted the service location protocol (SLP). Salutation, an independent consortium of leading technology companies, has also advanced a nonproprietary service discovery protocol that is currently utilized by several shipping products[2]. But Bluetooth offers own hardware implementation of the given protocol.
2. SERVICE DESCOVERY PROTOCOL

SDP is a simple protocol with minimal requirements on the underlying transport. It can function over a reliable packet transport (or even unreliable, if the client implements timeouts and repeats requests as necessary). SDP uses a request/response model where each transaction consists of one request protocol data unit (PDU) and one response PDU. However, the requests may potentially be pipelined and responses may potentially be returned out of order. In the specific case where SDP utilises the Bluetooth L2CAP transport protocol, multiple SDP PDUs may be sent in a single L2CAP packet, but only one L2CAP packet per connection to a given SDP server may be outstanding at a given instant. Limiting SDP to sending one unacknowledged packet provides a simple form of flow control.

The SDP defines how a Bluetooth clients application shell acts to discover available Bluetooth servers services and their characteristics. The protocol defines how client can search for a service based on specific attributes without the client knowing anything of the available services. The SDP provides means for discovery of new services become becoming available when the client enters an area where a Bluetooth server is operating. The SDP also provides functionality for detecting when a service is no longer available [1].

Diagram Source: [1], Fig 2.1, p. 330

Every SDP PDU consists of a PDU header followed by PDU-specific parameters. The header contains three fields: - PDU ID field identifies the type of PDU. I.e. its meaning and the specific parameters (1 byte length). - TransactionID field uniquely identifies request PDUs and is used to match response PDUs to request PDUs (2 byte length). - ParameterLength field specifies the length (in bytes) of all parameters contained in the PDU (2 byte length). Parameters may include a continuation state parameter, described below; PDU-specific parameters for each PDU type are described later in separate PDU descriptions. Some SDP requests may require responses that are larger than can fit in a single response PDU. In this case, the SDP server will generate a partial response along with a continuation state parameter. The continuation state parameter can be supplied by the client in a subsequent request to retrieve the next portion of the complete response. It have only two fields InfoLenght (1 byte) and Continuation Information (InfoLenght bytes) Each transaction consists of a request and a response PDU. Generally, each type of request PDU has a corresponding type of response PDU. However, if the server determines that a request is improperly formatted or for any reason the server cannot respond with the appropriate PDU type, it will respond with an error PDU (SDP_ErrorResponse) . Devices working with SDP have the following services: 2.1 Service Record A service is any entity that can provide information, perform an action, or control a resource on behalf of another entity. A service may be implemented as software, hardware, or a combination of hardware and software. All of the information about a service that is maintained by an SDP server is contained within a single service record. The service record consists entirely of a list of service attributes. Service Attribute Each service attribute describes a single characteristic of a service. SDP has next service attributes: ServiceRecordHandle, ServiceClassIDList, ServiceRecordState, ServiceID, ProtocolDescriptionList, BrowseGroupList, LanguageBaseAttributeIDList, ServiceInfoTimeToLive, ServiceAvaliability, BluetoothProfileDescriptorList, DocumentationURL, ClientExecutibleURL, IconURL,

ServiceName, ServiceDescription, ProviderName. Some attribute definitions are common to all service records, but service providers can also define their own service attributes in reserved fields. A service attribute consists of two components: an attribute ID and an attribute value. - An attribute ID is a 16-bit unsigned integer that distinguishes each service attribute from other service attributes within a service record. The attribute ID also identifies the semantics of the associated attribute value. - The attribute value is a variable length field whose meaning is determined by the attribute ID associated with it and by the service class of the service record in which the attribute is contained. In the Service Discovery Protocol, an attribute value is represented as a data element. See the section Data Representation below for more information. Service Class Each service is an instance of a service class. The service class definition provides the definitions of all attributes contained in service records that represent instances of that class. Each attribute definition specifies the numeric value of the attribute ID, the intended use of the attribute value, and the format of the attribute value. A service record contains attributes that are specific to a service class as well as universal attributes that are common to all services. Each service class is assigned a unique identifier, a UUID. A UUID is a universally unique identifier that is guaranteed to be unique across all space and all time. UUIDs can be independently created in a distributed fashion. No central registry of assigned UUIDs is required. A UUID is a 128bit value as rule, but also possible aliases (16 and 32 bit UUID), which can extended to standard size using next procedure [1]:
128_bit_value = 16_bit_value * 296 + Bluetooth_Base_UUID 128_bit_value = 32_bit_value * 296 + Bluetooth_Base_UUID

Service Discovery The whole point of the SDP is to allow bluetooth devices to discover what other bluetooth devices can offer (what services). SDP allows this in various means. Searching means looking for specific service, while Browsing means looking to see what services are actually being offered. Searching for Services The Service Search transaction allows a client to retrieve the service record handles for particular service records based on the values of attributes contained within those service records. The capability search for service records based on the values of arbitrary attributes is not provided. Rather, the capability is provided to search only for attributes whose values are Universally Unique Identifiers (UUIDs).

Important attributes of services that can be used to search for a service are represented as UUIDs. Service search pattern are used to locate the desired service. A service search pattern is a list of UUIDs (service attributes) used to locate matching service records. Browsing for Services This process of looking for any offered services is termed browsing. In SDP, the mechanism for browsing for services is based on an attribute shared by all service classes. This attribute is called the BrowseGroupList attribute. The value of this attribute contains a list of UUIDs. Each UUID represents a browse group with which a service may be associated for the purpose of browsing. When a client desires to browse an SDP servers services, it creates a service search pattern containing the UUID that represents the root browse group. All services that may be browsed at the top level are made members of the root browse group by having the root browse groups UUID as a value within the BrowseGroupList attribute. Data Representation As mentioned above, In the Service Discovery Protocol, an attribute value is represented as a data element. A data element is a typed data representation. It consists of two fields: a header field and a data field. Data Element header field The header field is composed of 2 parts, a Type Descriptor and a Size Descriptor. - Type Descriptor: A data element type is represented as a 5-bit type descriptor. The type descriptor is contained in the most significant (highorder) 5 bits of the first byte of the data element header. - Size Descriptor: The data element size descriptor is represented as a 3-bit size index followed by 0, 8, 16, or 32 bits. The size index is contained in the least significant (low-order) 3 bits of the first byte of the data element header. Data Element data field The data is a sequence of bytes whose length is specified in the size descriptor and whose meaning is (partially) specified by the type descriptor.
3. DEVICE INTERACTION USING SDP

retrieved via SDP facilitates service assess by using it to properly condition the local Bluetooth stack to assess the desired service. SDP provides direct support for the following set of services inquiries: 1) search for service by service class; 2) search for service by service attributes; 3) service browsing. The above service inquiry scenarios can se realized twofold: 1) by performing the service searches on a particular device that a user consciously has already connected to, and/or 2) by performing the service searches by unconsciously connecting to device discovered in a devices vicinity. Both of the above approaches require that devices need first to be discovered, then linked with, and then inquired about the services they support. Service discovery is tightly related to discovering devices, and discovering devices is tightly related to performing inquiries and pages.

Diagram Source: [3], Fig 2.1, p. 68

Interoperability between devices from different manufacturers is provided for a specific service and use case, if the devices conform to a Bluetooth SIG-defined profile specification. The Bluetooth protocol stack contains a Service Discovery Protocol (SDP) [1], that is used to locate services that a available on or via devices in the vicinity of a Bluetooth enabled device. Having located what services are available in a device, a user may then select to use one or more of them. Yet even though SDP is not directly involved in assessing services, information

Interaction devices has a next roles: LOCAL device (LocDev): A LocDev is the device that initiates the service discovery procedure. A LocDev must contain at least the client portion of the Bluetooth SDP architecture. A LocDev contains the service discovery application (SRVDscApp) used by a user to initiate discoveries and display the results of this discoveries. REMOTE Device(s) (RemDev(s)): A RemDev is any device that participates in the service discovery process by responding to the service inquiries generated by a LocDev. A RemDev must contain at least server portion of the Bluetooth SDP architecture. A RemDev contains a service records database whith the server portion of SDP consults to create responses to service discovery requests. Before any two Bluetooth equipped devices can communicate with each other the following may be needed: 1) The devices need to be powered-on and initialized. Initialization may require providing a PIN for the creation of a link key. For device authorization and data encryption.

2) A Bluetooth link has to be created, which may require the discovery of the other devices BD_ADDR via inquire process and the paging of the other device. Service Discovery support next application primitive for interaction between devices: - serviceSearch(); - serviceBrowse(); - enumerateRemDev(); -terminatePrimitive(). This primitives provide support interaction implemented by Blutooth SDP[3].
4. CONCLUSION

5.

REFERENCES

1. Bluetooth SIG, Specification of the Bluetooth System Core, Version 1.0B volume 1,1999. Part E. http://www.bluetooth.com/link/spec/bluetooth_e.pdf 2. Dipanjan Chakraborty, Harry Chen, "Service Discovery in the future for Mobile Commerce", accepted for publication by Association for Computing Machinery (ACM) Crossroads, Winter 2000 (7.2). http://www.cs.umbc.edu/~dchakr1/papers/mcommerce.htm l 3. Bluetooth SIG, Specification of the Bluetooth System Profiles, Version 1.0B volume 1,1999. Part K:2 http://www.bluetooth.com/link/spec/bluetooth_k2.pdf 4. T. Hodes and R. Katz. Composable Ad hoc Locationbased Services for Heterogeneous Mobile Clients. ACM Wireless Networks, 1998. Special issue on Mobile Computing. http://citeseer.nj.nec.com/hodes98composable.html

Service discovering in Bluetooth protocol realized only basic methods for searching and recognition of devices and proposed services, but for utilization and implementing mentioned above services need another, more sophisticated system based on native SDP procedures and using highlevel technology [1,4].