Klings.NoWires.J2ME()

Home

J2ME CDC CLDC MIDP 1.0 MIDP 2.0 MIDlets JABWT

Bluetooth

BTBrowser BTBenchmark KlingsLib

Code Structure Inquiry Service
search RFCOMM Pitfalls Service record usage Service record manipulation

Devices Developers

Tools Rococo IDEs WTK NDS Antenna

How-To Bluez OBEX Eclipse NetBeans JBuilder WAP

About me

Java APIs for Bluetooth Wireless Technology (JABWT)

The JABWT was defined by a Java Community Process expert group JSR-82 consisting of a number of industrial partners. See links for details.

The JABWT specification defines an optional J2ME package for Bluetooth wireless technology.

High-level Architecture View

           
MIDP Applications OEM-Specific
Applications		 Native
Applications
    OEM-Specific
Classes		  
  MIDP + JABWT    
CLDC  
Native System Software + Bluetooth Stack
MID

What is it?

The JABWT operates on top of the CLDC and is intended to extend the capabilities of profiles like the MIDP. JABWT use the Generic Connection Framework (GCF) defined in the CLDC specification for Bluetooth communication.

What does it provide?

JABWT consists of two packages.

javax.bluetooth The core Bluetooth API.
javax.obex The Object Exchange (OBEX) API.

These packages are separate optional packages so the CLDC implementation may include either of the packages or both of them.

The javax.bluetooth package provides an API for discovering devices and the services they provide. In addition it provides functionality for setting up services of your own and customization of local service records. Setting up L2CAP and RFCOMM connections is available through an extension to the Generic Connection Framework (GCF) from the CLDC.

The javax.obex provides an API for the OBject EXchange (OBEX) protocol. This package is not implemented on the Nokia 6600 smartphone. It is not tied to the Bluetooth API alone but is intended to be of more general use. I will not describe this API further in my thesis.

Security

The JABWT does not define any security models itself. It depends on the security models available through the Bluetooth stack. However, it does define how the JABWT should interact with the lower layers in the Bluetooth stack responsible for security features. The device must have a Bluetooth Control Center (BCC) to which JABWT applications can direct their security requests. The features of the BCC will be outlined below.

BCC

The JABWT depends on a BCC implemented on the device. The BCC is the central authority for local Bluetooth device settings. It controls base security settings and provides lists of devices both known and trusted by the local device. The BCC is responsible for pairing devices and providing authorization for connection request. All of these functions must be included in the BCC.

The BCC may have other capabilities like setting the Bluetooth friendly-name of the device, setting timeouts for the baseband layer, determining how connectable and discoverable modes are set, resetting the local device or enumerating services on the local device. This BCC functionality is implementation dependent and may vary between OEMs an their devices. Some implementations may provide a GUI to the BCC while others provide hard-coded defaults in the BCC. For example, a headset will provide only defaults in the BCC since it does not have an input device or screen. When sending request to the BCC one should always check if the request was fulfilled by the BCC. One is not guaranteed that the BCC can fulfill the request at the given time.

This page was last updated 14. Jul. 2006

Comments and feedback are highly appreciated.

You can reach me at: klings (at) nowires (dot) org