How an end user will employ Bluetooth wireless technology varies from person to person. Two people with the same model phone that incorporates Bluetooth wireless technology might want to use it for different purposes. One person might want to be able to download video games to the phone or use the phone as a TV remote control. The other person might want to use the same model phone to unlock car doors or operate kitchen appliances and garage doors.
One way for both people to achieve their goals is to make it possible to download Bluetooth applications onto their PDAs and cell phones to customize those handheld devices. To make downloading applications a viable possibility you need a standard application-programming interface (API) that will let programmers write Bluetooth applications that work across many different hardware platforms.
The Java programming language is the ideal choice for this standard API for Bluetooth wireless technology. A Java API enables applications to run on different hardware, operating systems or class of device. In addition to portability, the Java language provides several other benefits:
- Rapid development of applications because of the abstractions and high-level programming constructs provided by an object-oriented programming language.
- Java class file verification and security features provide protection against malicious applications. These features make it feasible to customize devices by downloading applications.
- Large developer community: The developer talent needed for programming in the Java language already exists and there is no need to grow a developer community.
For these reasons, the decision was made to develop a standard API for Bluetooth wireless technology using the Java programming language. An expert group whose members represented 21 companies started work on defining this API in December 2000 under the Java Community Process. The effort to develop Bluetooth APIs was given the designation Java Specification Request 82, or JSR-82.
Drafts of the JSR-82 specification, also known as the Java APIs for Bluetooth wireless technology (JABWT), were made available for public review in the fourth quarter of 2001, and the 1.0 version of the specification was released in March 2002. In this article we'll provide some of the main technical details that make up the JSR-82 spec. In Part 1, we'll look at how the JSR-82 spec was defined and at both the RFCOMM and device discovery layers. In Part 2, we'll examine the service discovery layer and the API for the Object Exchange Protocol (OBEX). (Note: The complete JABWT specification can be downloaded from http://jcp.org/jsr/detail/082.jsp)
Goals and Design
The main goal of the JSR-82 specification was to define an API that could be used by all Bluetooth devices that support the Java 2 Platform, Micro Edition (J2ME). J2ME is intended for embedded devices, and the expert group felt that these devices would be the first to implement the Bluetooth API. Hence, the API was built using standard J2ME APIs and the Generic Connection Framework (GCF) defined in the Connected, Limited Device Configuration (CLDC). Thus JABWT could be ported to any Java platform that supports the GCF. With the definition of JSR-197 (http://jcp.org/jsr/detail/197.jsp), which extends the GCF to Java 2 Platform, Standard Edition (J2SE), JSR-82 can now be implemented on both J2SE and J2ME devices.
Figure 1 shows an example of how JSR-82 fits within the J2ME architecture. Though it is shown here on a mobile information device profile (MIDP) device, JSR-82 does not depend on the MIDP APIs.
Figure 1: Diagram of a CLDC+MIDP+JABWT architecture.
The lowest-level block in Figure 1 is the system software or the host operating system. The host operating system has the host part of the Bluetooth protocol stack and other libraries that are used internally and by native applications of the system. Native Bluetooth applications interface with the operating system directly.
Though the initial thinking was to define an API based on the Bluetooth profiles, the JSR-82 expert group realized that the number of Bluetooth profiles is constantly growing. The expert group decided to provide support for only basic protocols and profiles rather than introducing new API elements for each Bluetooth profile. Although it is difficult to predict the needs of future Bluetooth profiles, the hope is that the design of JSR-82 will allow Bluetooth profiles to be written in the Java programming language.
In version 1.1 of the Bluetooth specification, Bluetooth profiles are built using the OBEX protocol, the logical link control and adaptation protocol (L2CAP), or the RFCOMM protocol. For this reason, all three of these communication protocols are incorporated in JSR-82. In addition, the JSR-82 specification addresses the following profiles: the generic access profile, the service discovery application profile, the serial port profile, and the generic object exchange profile.
While defining the Java Bluetooth API, the JSR-82 expert group recognized that the OBEX protocol could be used over a number of different transports (e.g., IrDA or Bluetooth wireless technology). Therefore, the OBEX API is defined to be transport independent. There is a separate Java package, javax.obex, for the OBEX part of the API. An IrDA device could implement the javax.obex package and not implement the javax.bluetooth package, which contains the Bluetooth API.
Bluetooth Control Center
The JSR-82 specification introduced the concept of a Bluetooth control center (BCC). The J2ME platform allows multiple Bluetooth applications to run concurrently. The BCC resolves any conflicts that arise as applications contend for Bluetooth resources, request different configurations of the Bluetooth system, or request different levels of security.
The policies enforced by the BCC are expected to vary for different types of devices. Therefore, the details of how BCC operates will depend on the Bluetooth stack and hardware used. The JSR-82 specification only lists the functions of the BCC and leaves the implementation details to the API implementers.
The JSR-82 implementation, including the BCC, depends on the underlying Bluetooth system and the J2ME implementation. The Bluetooth stack underlying a JSR-82 implementation must be qualified for the generic access profile, the service discovery application profile, and the serial port profile. The stack must also provide access to its service discovery protocol, RFCOMM, and L2CAP layers.
Systems using JSR-82 must comply with these requirements because APIs developed under the Java Community Process are not allowed to have optional elements. The whole Java package must be implemented on a device if any part of it is implemented. This was the most challenging part of defining the JSR-82 specification: to fit a changing, growing Bluetooth specification with many optional elements into a Java API where no options are allowed.
JSR-82 Functionality
The functionality provided by JSR-82 falls into three major categories:
- Discovery
- Communication
- Device Management
Discovery includes device discovery, service discovery and service registration. Communication includes establishing connections between devices and using those connections for Bluetooth communication between applications. These connections can be made over several different protocols, namely RFCOMM, L2CAP and OBEX. Device management allows for managing and controlling these connections. It deals with managing local and remote device states and properties. In addition, it facilitates the security aspects of connections.
In the remainder of Part 1, we'll examine device discovery and the RFCOMM connection layer. In Part 2, we'll continue by looking at the support JSR-82 offers for service discovery and OBEX.
Understanding Device Discovery
Device discovery is the process of locating the Bluetooth devices that are in the area. Device discovery requires the local device to broadcast an inquiry request and wait for Bluetooth devices in the area to respond. In order to determine if a device responds to an inquiry request, the Bluetooth specification has defined three different discoverable modes (general, limited, and not discoverable) and two different inquiry types (general and limited).
When a device issues a general inquiry, all devices in the general and limited discoverable modes will respond to the request. For example, Figures 2 and 3 show a cell phone performing a general inquiry and only the general and limited discoverable devices respond to the inquiry request. When a limited inquiry is issued, only those devices that are limited discoverable will respond. If a device is not discoverable, it never responds to an inquiry request.
Figure 2: Cell phone performing a general inquiry.
Figure 3: All limited and general discoverable devices respond to a general inquiry.
In order to set the discoverable mode, JSR-82 defines the setDiscoverable() method in the LocalDevice class. The argument of the setDiscoverable() method is the discoverable mode that the local device should use for responding to inquiries.
The DiscoveryAgent class is the main class for all discovery operations in JSR-82.
The DiscoveryAgent has startInquiry() and retrieveDevices() methods. The startInquiry() method is used to start an inquiry.
The startInquiry() method takes two arguments, the type of inquiry to perform (limited or general) and a DiscoveryListener. An application must create a class that implements the DiscoveryListener interface. This class will define the deviceDiscovered() and inquiryCompleted() methods, which are used within device discovery.
The startInquiry() method is a non-blocking call. This means that the call to startInquiry() will return before the inquiry is actually completed. When the inquiry ends, the inquiryCompleted() method is called by the JABWT implementation on the DiscoveryListener.
The deviceDiscovered() method is called by the JSR-82 implementation each time a remote Bluetooth device is found. The arguments passed are the RemoteDevice object that represents the remote Bluetooth device that was found along with its DeviceClass.
The RemoteDevice class provides methods that allow the application to gather additional information on the remote device like the device's Bluetooth address or user-friendly name. The DeviceClass provides additional information on the type of device and the types of services that are available on the device. This information can be used to determine if a service search should be performed on the remote device.
The retrieveDevices() method does not actually perform an inquiry. Instead, the retrieveDevices() method either returns devices found during a previous inquiry or the set of devices that the local device commonly connects to. This method determines which set of devices to return based upon an argument to the method. The retrieveDevices() method provides an application with a hint about at what devices may be in the area, but it does not guarantee that any of the devices can be connected to.
RFCOMM: Delivering Serial Port Emulation
The RFCOMM protocol provides RS-232 serial port emulation between two Bluetooth devices. JSR-82 does not define any new interfaces or classes to allow applications to utilize RFCOMM. Instead, JSR-82 uses used existing interfaces and classes that are part of the GCF defined in CLDC. All connections start with Connector.open(). The string passed to Connector.open() specifies which protocol to use and which device to connect to.
The RFCOMM connection string follows the GCF standard connection string format by dividing the string into three parts: the scheme, target, and parameters. The scheme for RFCOMM is btspp.
The first two letters in btspp, "bt", stand for Bluetooth. The last three letters stand for "serial port profile", which is the Bluetooth profile realization of RFCOMM. The scheme is separated from the target by "://". In connection strings used by clients, the target is the Bluetooth address and service channel identifier separated by a colon. In connection strings used by servers, the target is the keyword "localhost:" followed by the universally unique identifier (UUID) of the service.
The UUID is placed in the server's service record in the ServiceClassIdList attribute (see Part 2 for additional information about service records). After the target, there are a variety of parameters that can be specified including the security requirements on the connection and the service's name.
The following are valid RFCOMM client connection strings:
btspp://00803d000001:1
btspp://008034ad2AA1:3;authenticate=true
The following are valid RFCOMM server connection strings:
btspp://localhost:efca5621975548568f27b437f6e5e6b2
btspp://localhost:93007CA747114F42b1dcce878a65391f;name=MyService
When a client connection string is passed to Connector.open(), a StreamConnection object is returned. With the StreamConnection object, the application is able to retrieve input and output streams to read and write data to the server. The connection ends when the application calls close().
When a server connection string is passed to Connector.open(), a StreamConnectionNotifier object is returned. An application can use this object to call acceptAndOpen() to wait for a client to connect to the server. Once a client connects to the server, the acceptAndOpen() method returns a StreamConnection object. Like the client, the server is able to use the StreamConnection object to read and write data using the input and output streams provided by the StreamConnection object.
On to Part 2
That wraps up Part 1 of our series on the emerging JSR-82 specification. In Part 2, we'll continue the discussion by looking at the service discovery layer and the OBEX API defined by JSR-82. To view Part 2, click here.
Author's Note: These two articles are based on a forthcoming book called Bluetooth Application Programming with the Java APIs by the authors. The complete JABWT specification can be downloaded from http://jcp.org/jsr/detail/082.jsp.
About the Authors
C Bala Kumar is the specification lead for JSR-82. He leads the systems software team on wireless platforms for Motorola's Semiconductor Products Sector. Bala received his Masters in Electrical Engineering at The University of Texas at Austin and can be reached at c.bala.kumar@motorola.com.
Paul J. Kline is the maintenance lead for JSR-82. He works on software architectures for wireless platforms for Motorola's Semiconductor Products Sector. Paul received his Ph.D. from The University of Michigan and can be reached at paul.kline@motorola.com.
Timothy J. Thompson is the OBEX architect on the JSR-82 specification team. He works on software architectures for wireless platforms for Motorola's Semiconductor Products Sector. Timothy received his Masters in Computer Science at Texas A&M University and can be reached at tim.thompson@motorola.com.
