Developing Wireless Bluetooth Applications in J2ME
Portable, secure, and highly usable
Jan. 5, 2005 12:00 AM
Mobile communication comes into our daily lives very quickly, and as of today several wireless technologies have become standard. In this article I'll briefly review Bluetooth principles and the principles of Java development for Bluetooth on mobile devices.
The Java APIs for the Bluetooth wireless technology (JABWT) standard, defined by the JSR 82 specification (www.jcp.org/en/jsr/detail?id=82), supports the rapid development of Bluetooth applications that are portable, secure, and highly usable. Wireless device manufacturers have responded to the JABWT specification by announcing mobile phones and other products that will run JABWT applications.
What Is Bluetooth?
According to the latest Bluetooth 1.2 specification (www.bluetooth.org/spec/), Bluetooth wireless technology is a short-range communications system that's intended to replace the cable(s) connecting portable and/or fixed electronic devices. The Bluetooth core system consists of a radio frequency (RF) transceiver, baseband, and protocol stack. The system offers services that enable the connection of devices and the exchange of a variety of classes of data between these devices. Actually it's a wireless communication protocol that, like HTTP or FTP, operates in a client/server architecture. It uses the 2.4 GHz band known in the U.S. as the Industrial-Scientific-Medical (ISM) band. The 802.11b wireless LAN protocol operates in this band as well, although they are intended for different needs and don't interfere with each other.
Bluetooth is a completely different way to communicate compared to cables, since during a typical operation a physical radio channel is shared by a group of devices that are synchronized to a common clock. One device provides the synchronization reference and is known as the master. All other devices are known as slaves. A group of devices synchronized in this way form a so-called piconet. A master and a single slave use point-to-point communication; if there are multiple slaves, point-to-multipoint communication is used. A master unit is the device that initiates the communication. A device in one piconet can communicate to another device in another piconet, forming a scatternet. The physical channel is subdivided into time units known as slots. Data is transmitted between Bluetooth devices in packets that are positioned in these slots. Above the physical channel there is a layering of links and channels and associated control protocols. The hierarchy of channels and links from the physical channel upward consists of a physical channel, a physical link, logical transport, a logical link, and a L2CAP channel. In Figure 1 we can see a high-level view of the architecture of the Bluetooth protocol stack.
The radio layer is the physical wireless connection. To avoid interference with other devices that communicate in the ISM band, the modulation is based on fast frequency hopping. Bluetooth divides the 2.4 GHz frequency band into 79 channels, 1 MHz apart (from 2.402 to 2.480 GHz), and uses this spread spectrum to hop from one channel to another, up to 1,600 times per second.
The baseband layer is responsible for controlling and sending data packets over the radio link. It provides transmission channels for both data and voice. The baseband layer maintains Synchronous Connection-Oriented (SCO) links for voice and Asynchronous Connectionless (ACL) links for data. SCO packets are never retransmitted but ACL packets are to ensure data integrity. The Host Controller Interface (HCI) controls the low-level operation of the radio and is the interface between the Bluetooth device and the host computer. Logical Link Controller Adaptation Protocol (L2CAP) multiplexes all data passing through the Bluetooth device. However, audio signals have direct access to the HCI. The Service Discovery Protocol (SDP) finds services on remote Bluetooth devices. RFCOMM is widely known as the virtual serial port protocol, because it allows a Bluetooth device to simulate the functionality of a serial port.
At the application level it can be any application that needs to exchange data through a wireless connection. Object Exchange Protocol (OBEX) is widely used and allows you to exchange object data (such as files). It's interesting that the Object Exchange (OBEX) API was developed by Java enthusiasts and became a subpackage of JSR 82.
Bluetooth profiles exist to ensure interoperability among Bluetooth-enabled devices and applications from different manufacturers and vendors. A profile defines the roles and capabilities for specific types of applications. Bluetooth devices cannot interact unless they conform to a particular profile. There are a number of different profiles in a Bluetooth specification, such as Synchronization, Serial Port, and LAN Access. The Synchronization Profile defines the application requirements for Bluetooth devices that need to synchronize data on two or more devices. The Serial Port Profile defines the requirements for Bluetooth devices that need to set up connections that emulate serial cables and use the RFCOMM protocol. The LAN Access Profile defines how Bluetooth devices can access the services of a LAN using PPP, and shows how PPP mechanisms can be used to form a network consisting of Bluetooth devices.
Security is provided in three ways: pseudo-random frequency hopping, authentication, and encryption. Frequency hops make it difficult for anyone to eavesdrop. Authentication allows a user to limit connectivity to specified devices. Encryption uses secret keys to make data intelligible only to authorized parties.
Now we can see how easy it is to connect two devices with Bluetooth using Java. The Java Bluetooth API relies on the Java Generic Connection Framework, which limited it to J2ME for a long time. However, now it's been proposed to include GCF in J2SE, and the Bluetooth API can be made accessible for a broader range of systems. The Java APIs for Bluetooth define two packages: javax.bluetooth for the core Bluetooth API and javax.obex for the Object Exchange (OBEX) protocol. Any Bluetooth application has these components: stack initialization, device management, device discovery, service discovery, and communication. According to JSR 82, the underlying Bluetooth system must support a Bluetooth Control Center (BCC), a control panel much like the application that allows a user or OEM to define specific values for certain configuration parameters in a stack. In particular, it will be used in a stack initialization.
Prior to starting wireless communication the Bluetooth device should be initialized. This is done in a vendor-dependent way, and exact steps for stack initialization are beyond the scope of the Bluetooth API specification. As shown by Bruce Hopkins, the author of Bluetooth for Java, in his article "Getting Started with Java and Bluetooth" (http://today.java.net/pub/a/today/2004/07/27/bluetooth.html), it is done using several settings in the Atinav Java Bluetooth SDK (see Listing 1). It is important that these calls are not part of JSR 82. Other JSR 82 implementations may incorporate other ways to initialize the stack.
The JSR 82 API introduces two classes that can be used for device management: LocalDevice to request static information about the Bluetooth device, and RemoteDevice to retrieve information about devices in the Bluetooth neighborhood, e.g., a remote device Bluetooth Address. LocalDevice depends on the javax.bluetooth.DeviceClass class to retrieve the device's type and the kinds of services it offers. The RemoteDevice class represents a remote device (a device within a range of reach) and provides methods to retrieve information about the device, including its Bluetooth address and name. Every Bluetooth device has a unique hardware address, like the MAC address for computers. You can set the level of device discovery, enabling other Bluetooth devices to find the current device by calling the setDiscoverable() method in the LocalDevice object (see Listing 2).