java applications for a bluetooth plataform

8/8/2019 Java Applications for a Bluetooth Plataform

1/139

Java Applications for aBluetooth Platform

By Benjamin Williams

2002

School of Information Technology andElectrical Engineering

The University of Queensland


2/139

Benjamin Williams

5 Garson PlaceMC DOWALL, BRISBANE 4053

Ph. (07) 33533607Mobile. 3842662046

[email protected]

To the HeadSchool of Information Technology and Electrical EngineeringThe University of QueenslandSt Lucia, QLD 4072

Dear Professor Kaplan,

In accordance with the requirements of the degree of Bachelor of Engineering in thedivision of Electrical Engineering, I present the following thesis entitledJava applications for a Bluetooth Platform. This work was performed under thesupervision of Dr Adam Postula.

I declare that the work submitted in this thesis is my own, except as acknowledged inthe text and footnotes, and has not been previously submitted for a degree at theUniversity of Queensland or any other institution.

Yours SincerelyBenjamin Williams
mailto:[email protected]:[email protected]


3/139

Acknowledgements

Thank you to Dr Adam Postula, Henry Valk and Paul Logothetis for your assistancewith this project.

Thank you to Mum, Dad, Mark, Michael and Susan for your support through out theyear.


4/139


5/139

required to develop a more optimised Java/Bluetooth execution environment in order

to produce more compelling applications of value to the consumer.


6/139

Table of Contents

Part 1 Introduction and basis for research ............... ................ ................ ................ ....11.1 Overview.............................................................................................................1

1.2 Introduction.........................................................................................................11.2 The Bluetooth Standard ............... ................ ................ .................. ................ ......21.2 Basis for the Project.............................................................................................51.3 Aims of the project ............... .................. ................ ................ ................ ............. 71.4 Plan for delivering the project goals.....................................................................8

1.4.1 Research and analysis ...................................................................................81.4.2 Design ..........................................................................................................91.4.3 Implementation .............................................................................................91.4.4 Evaluation ....................................................................................................9

Part 2 Research and Analysis....................................................................................112.1 Overview...........................................................................................................112.2 Overview of the Bluetooth Specification ................ .................. ................ ......... 11

2.2.1 The Radio ...................................................................................................112.2.2 The Baseband Layer ...................................................................................132.2.3 Link Manager Protocol ...............................................................................142.2.4 Logical Link Control and Adaptation Protocol (L2CAP) .............................142.2.5 Host Controller Interface ............................................................................152.2.6 RFCOMM ...................................................................................................152.2.7 PPP ............................................................................................................152.2.6 OBEX .........................................................................................................162.2.7 Service Discovery Protocol .........................................................................162.2.8 The Bluetooth Profiles ................................................................................162.2.9 Generic Access Profile ................................................................................172.2.10 Service Discovery Profile ..........................................................................182.2.11 Serial Port Profile .....................................................................................182.2.12 Generic Object Exchange Profile ..............................................................18

2.3 Java 2 Micro Edition .............. ................ ................ ................ ................ ........... 182.3.1 Virtual Machine Layer ................................................................................202.3.2 Configuration Layer ...................................................................................202.3.3 Profile Layer ...............................................................................................20

2.4 Bluetooth API....................................................................................................212.5 Criteria for Bluetooth applications.....................................................................22

2.5.1 Strengths of the technology .........................................................................222.5.2 Limitations and restrictions of Bluetooth Technology ..................................22

2.6 Other requirements for the experimental application..........................................242.7 Market for Bluetooth Applications.....................................................................24

2.7.1 Wireless Commerce ....................................................................................252.7.2 Location aware mobile commerce services .................................................262.7.3 Mobile Financial Application .....................................................................262.7.4 Mobile Advertising ......................................................................................272.7.5 Proactive Service Management ...................................................................272.7.6 Product Location and Shopping ..................................................................272.7.7 Information services on public networks .....................................................282.7.8 Other non-commercial applications ............................................................28


7/139

2.7.9 Ad-hoc networking and groupware .............................................................282.8 Non-functional requirements and criteria to evaluate the end product ................ 29

2.8.1 Added convenience .....................................................................................292.8.2 Speed ..........................................................................................................292.8.3 User Interface .............................................................................................292.8.4 Security .......................................................................................................30

2.8.5 Reliability ...................................................................................................302.9 Choice of application scenario ................... ............... ................ ................ ......... 312.9 Critical evaluation of previous work performed on Bluetooth and JavaApplications. .............. ................ ................ ................ .................. ................ ........... 33

Part 3 Design............................................................................................................373.1 Overview...........................................................................................................373.2 System architecture ................ ................ .................. ................ ................ ......... 373.2 System Assumptions ............ .................. ................ ................ ................ ........... 373.3 Mobile Device Architecture...............................................................................393.4 Network Architecture ................ .................. ................ ................ ................ ...... 413.4 Server and Gateway Architecture .................. ................ ................ ................ ....443.5 Mobile device software selection and integration...............................................45

3.5.1 Java Virtual Machine ..................................................................................453.5.2 Bluetooth Stacks .........................................................................................473.5.3 Operating System and JVM .........................................................................48

3.5 Distributed Mobile Services ............... .................. ................ ................ ............. 483.6 Middleware Options ............. .................. ................ ................ ................ ........... 52

3.6.1 COBRA .......................................................................................................523.6.2 Java Remote Method Invocation (RMI) .......................................................523.6.3 Web Services ...............................................................................................533.6.4 Simple Object Access Protocol ....................................................................533.6.5 Web Service Description Language .............................................................543.6.6 Universal Description, Discovery, and Integration (UDDI) ........................543.6.7 Incorporating Web Services into Bluetooth MIDP Applications ..................54

3.7 Client Application Design ............... ................ ................ .................. ................ 553.8 Server Design................ ................ .................. ................ ................ ................ ..593.8 Design for the client Java Bluetooth interface ................ ................ .................. ..603.8 Gateway Design ............... ................ ............... ................ .................. ................ 64

Part 4 Implementation ............... .................. ................ ................ ................ ............. 664.1 Overview...........................................................................................................664.2 Implementation of the test Client MIDP Application and SOAP server........ ...... 664.3 Ipaq Setup .............. ................ ................ .................. ................ ................ ......... 674.4 Implementing the gateway.................................................................................684.5 Providing the Java interface to the Affix Bluetooth Stack ................ .................. 694.6 Implementation and evaluation of the total system.............................................70

Part 5 Evaluation......................................................................................................715.1 Overview...........................................................................................................715.2 Outcomes of the project.....................................................................................715.3 Evaluation of the final system design.................................................................72

5.3.1 Added convenience .....................................................................................725.3.2 Speed ..........................................................................................................725.3.3 User Interface .............................................................................................735.3.4 Security .......................................................................................................735.3.5 Reliability ...................................................................................................73


8/139

5.4 Design Conclusions...........................................................................................735.5 Future Recommendations .............. ................ ................ ................ .................. ..74

Bibliography ................ ................ ................ ................ .................. ................ ............. 76Appendix A MIDP Application Screens ............. .................. ................ ................ ....80Appendix B MIDP Application Classes....................................................................83Appendix C MIDP Application Command Actions ................ ................ .................. 86

Appendix D MIDP Application Source Code ................ ................ ................ ........... 88Appendix E Server Application Source Code .................. ................ ................ ....... 106Appendix F Gateway Source Code.........................................................................109Appendix G Old Java Bluetooth Interface Source Code................... ................ ....... 116Appendix H Revised Java Bluetooth Interface Source Code...................................123


9/139

Table of Figures

Figure 1. The Bluetooth Protocol Stack.......................................................................12Figure 2. A Bluetooth Piconet ............... ................ .................. ................ ................ ....14

Figure 3. Profiles of the Bluetooth Specification .............. ................ .................. ......... 17Figure 4. Java 2 Micro Edition Platform Architecture..................................................19Figure 5. Topology of the network ............... ................ ................ ................ ............... 39Figure 6. Architecture of Software Components on the mobile device.........................40Figure 7. Relationship between interfaces for the Generic Connection Framework...... 43Figure 8. Network stacks for the gateway and mobile device.......................................45Figure 9. Distributed System Layers............................................................................49Figure 10. Using SOAP with TCP/IP/RFCOMM ............... ................ ................... ...... 55Figure 11. Server architecture................. ................ ................ ................ ................ ....59Figure 12. Database Schema ............... ................ ............... ................ ................... ...... 60Figure 13. The Interface for the Bluetooth connection classes .................. ................ ..62Figure 14. RFCOMM Class.................. ................ ................ ................ .................. ....63

Figure 15. The gateway process ............... ................ ................ .................. ................ 63Figure 16. The application running in the emulator......................................................65


10/139

1

Part 1 Introduction and basis for research

1.1 Overview

This section provides an introduction to the basis for the topic and describes the aims

and objectives of the project. A plan for delivering the objectives is documented.

1.2 Introduction

Consumer electronics are continually growing into more sophisticated pieces of

equipment that have greater power in bringing convenience and enjoyment to everyday

life. Many different types of devices from mobile phones to air conditioners now

contain embedded microcontrollers to allow them to process information from there

surroundings. The continuing development in microchip production has seen computer

processing power follow Moores Law and double roughly every 18 months, in addition

further improvements in the miniaturisation of components. Designers have exploited

the trend of embedded processors becoming smaller and more powerful to develop new

lines of products and greater enhance the functionality of existing devices. The

Personal Digital Assistant or PDA is an example of how developments in

microprocessors have impacted on consumer products. The PDA originated as a device

to store phone numbers and addresses, and has evolved into devices such as the Ipaq

which is essentially a handheld computer with the power to do many of the tasks

performed by its desktop counterpart [13].

Along side the growth of computing power, recent times have seen large advances in

the area networking and communications, mainly fuelled by the explosion of the

Internet. These developments are now seeing smaller mobile devices such as mobile

phones and PDAs empowered with the capacity to connect to the Internet and exchange

information. Mobile phones equipped with the Wireless Access Protocol (WAP)

provide their user with the convenience of access to web information such as stock

quotes from almost any location covered by the cellular system. In a society that is

becoming increasing dependent on gathering and exchanging information, it is likely


11/139

2

that there will be a continuing trend towards the development of personal information

devices that have added value to the user because of there ability to access and publish

data across networks.

Furthermore, with the continuing progress in computing and communication it isbelieved that there will be a trend towards what is termed Ubiquitous computing or

Persuasive computing. This describes an environment where almost everything, from

our toasters to our cars, will have tiny embedded processors can communication

seamlessly with one another. Should Moores Law hold for another 15 years as

predicted, processors will become so small and inexpensive, they will be found in

everyday items such as clothes and pencils. These smart devices will take advantage

of improvements in sensor technology to be able to gather information about there

environment and have spontaneous wireless networking capabilities to be able to

exchange this information to other systems. These systems will be able to process

relevant information and change the environment accordingly. This will all happen

unknowingly to the user to create unparalleled convenience [8].

1.2 The Bluetooth Standard

While widespread ubiquitous computing is still a future phenomena, the technology for

various devices to communicate wirelessly exists today in the form of the Bluetooth

specification. The Bluetooth standard is a short range wireless technology named after

the Viking King of Denmark 940-981AD Harald Blattand II, who was named

Bluetooth after the colour of his beard. Harald is credited with unifying the Vikings

of Norway and Denmark; hence his name is associated with a technology that aims to

create a standardised means for various types of devices to communicate over a wireless

connection. [9].

Bluetooth technology originated from Ericsson Mobile Communications, who were

searching for a means of developing a radio interface between mobile phones and

headset accessories. Researchers became aware that they could use the internationally

unlicensed ISM (industrial, scientific and medical) radio band for communicating


12/139

3

between devices. They were able to develop a small embedded radio suitable for use in

small devices.

However, Ericsson saw the greater potential that this new technology offered. Not only

could mobile phones and headsets be wirelessly connected, but printers and PDAs andvirtually any other devices. Thus in 1998 along with Nokia, IBM, Toshiba and Intel,

they formed the Bluetooth Special Interest Group (SIG) to develop a global short range

radio standard. Version 1.0 of the Bluetooth Standard was completed in June 1999 at

almost 1500 pages in length.

The Bluetooth specification was designed to meet the following system requirements:

Low cost Low power Universally adopted Must support a large variety of devices Must support automatic connections without user intervention Support voice and data communications Offer secure connections

The motivations for the development of the Bluetooth standard can be traced to both

immediate and future market needs. With proliferation of various computer devices and

peripherals, there is a short term demand to replace the cumbersome task of setting up

cable connections in order to allow these devices to exchange data. For example,

PDAs and Laptops require cables to connect to a mobile phone that allows dial-up

internet access, while owners of desktop computers often have to put up with an

entanglement of cables for there printer, scanner, mouse, keyboard and other devices.

The Bluetooth specification was developed in order to create a standardised means of utilising short range wireless technology to replace cable connections between varying

types of devices. The specification also seeks to make the connection process

automated, with the standard defining the means to find other nearby devices, search for

services and create the connection with minimal user intervention. This has the

potential to alleviate hassles associated with providing LAN and internet access to


13/139

4

portable computers. Incorporating Bluetooth technology into an existing product is

expected increases its value to the consumer by making in easier to form connections to

other devices [7].

However, the Bluetooth specification is designed to offer the consumer much more thancable replacement. Wireless technology removes many of the barriers imposed by

cables and allows for new types of networking ideas and products that could not be

offered by traditional wired networks. For instance, personal portable computers could

access public networks to take advantage of the services they may offer. A possible

scenario may be a shopping complex where a customer could access maps, directions,

catalogues and other information services from their portable computer. Offering such

access to public networks using personal computers is generally too impractical to be of

much value to the consumer using a wired system.

Because it is designed for creating standardised and automatic connections, Bluetooth

technology is well suited to the purpose of ad-hoc networking. Ad-hoc networking

refers to a network that can be formed automatically at a given time and place. Unlike

cellular systems, there is no need for a base station to co-ordinate the networking

between devices in an ad-hoc system Meetings and conferences are the obvious

situations where this type of networking has advantages. Members of a meeting could

form an ad-hoc network in any random conference room with portable computers and

be able to exchange documents and files to conduct the meeting more effectively. A

copy of the agenda and minute notes could be distributed to all members then and there

[6].

Furthermore, Bluetooth technology could provide a suitable stepping stone towards the

concept of persuasive computing. Bluetooth chips could be embedded in almost any

device, providing the spontaneous networking capabilities required to exchange

information with other entities in the system.

The full potential of Bluetooth however does not rest entirely with the specification.

While a number of profiles based around usage models for the technology are

documented, these profiles generally describe low level applications such as serial cable

emulation and file transfer that provide similar services to traditional wired networks.


14/139

5

Though the specification is quite comprehensive in documenting protocols and profiles

to ensure standardised wireless connectivity, it generally only defines services at the

network, transport and, in some cases, presentation layers (with reference to the OSI

network model). Thus, software developers are required to create distributed

applications that utilise the wireless capabilities of Bluetooth technology in order todeliver services of value to the user.

The Bluetooth standard has been designed to be compatible with existing networking

protocols (in part the Internet Protocol) to allow for existing network applications such

as web browsing to be used over a wireless connection. However, many of these

traditional applications have been developed under the assumptions they would be used

on fixed devices, and do not take advantage of the possibilities offered by mobile

computing. For example, consider the concept of location aware applications on a

mobile device that can access information on wireless services relevant to where the

person with the device is standing. This may the case of a person entering a store or

tourist attraction with a wireless PDA who wishes to look up the location of a particular

item.

Bluetooth technology is emerging with many development kits now available, but user

applications appear to be scarce. Thus, it is the overall essence of this project to

develop an application that realises some of the potential convenience and value

Bluetooth technology can offer.

1.2 Basis for the Project

The origin of this project stems from a discussion with Dr Adam Postula from the

School of ITEE at the University of Queensland and Henry Valk from HCV Wireless

about the viability of developing an application that could exploit Bluetooth technology.

The application would be intended to show case some of the benefits of this emerging

technology.

It was initially suggested that the application be developed as a graphical user interface

for the BlueMod device produced by HCV wireless. The BlueMod is essentially a


15/139

6

Bluetooth enabled device with an embedded processor. The GUI would be designed in

concurrence with the development of an LCD display for the BlueMod. Due to the fact

the LCD screen for the BlueMod would be unavailable for 6 months, it was suggested

that the application be developed using the Java Language. Because of Javas

portability, this would allow for the application to be developed on a desktop PC andported the BlueMod once the LCD screen was complete. It was decided that research

should also be conducted into finding an appropriate situation where a Bluetooth Java

application would provide real value and convenience to the user. It was concluded

from this meeting that the ultimate aim of the research project would be to develop a

Java application that utilised Bluetooth technology in providing a convenient service to

the end user via a graphical interface.

While Java was initially chosen as the application environment for practical purposes,

further research indicated that it was in fact well suited for wireless applications.

Sun Microsystems is marketing Java as excellent platform for developing wireless

applications because of three main advantages [15]

Security Robustness Portability

Security

Because Java applications execute in a virtual machine architecture, they are safe from

causing harm to the host device. At worst, the applications can bring down the virtual

machine. Certain Java configurations use a security model known as the sandbox

model to prevent application from access sensitive resources on the host.

Robustness

Features such garbage collection and the exception mechanisms improve the robustness

of application development. Additionally, the absence of direct memory manipulation

and strong typing generally means Java applications are less likely to fail.


16/139

7

Portability

With wireless devices varying highly in system configurations, portability is an

important advantage. Application need only be written once and can then be

theoretically distributed to any Java enabled device. Portability is more critical in

embedded devices because the unlike desktop system, no one operating environment(Microsoft Windows on Intel processors) dominates the market. The range of

processors and specialised operating systems makes the application environments across

embedded systems much more diverse [6].

These advantages are particularly important in considering the possibility of dynamic

over-the-air deployment of wireless applications. When downloading applications,

users will expect to be able to have confidence that the program will not cause harm or

disruption to their device, thus the security advantages of Java become essential.

Furthermore, due to the multitude of wireless devices, it would be almost impossible to

write a single application that could be downloaded and used by everyone, especially

without the need for additional configuration. Thus it necessary to have an application

environment that is portable across a large variety of devices.

In summary, it is hypothesised that utilising a combination of Bluetooth and Java

technology could allow developers to create universal wireless applications. Bluetooth

technology creates a standardised wireless networking framework for a variety of

different devices. The Java platform provides the portability, security and robustness

required to construct applications for mobile devices. This ultimately leads to more

valuable wireless products and services for the consumer. Thus, it seems worthwhile to

investigate what scenarios a consumer might benefit from this combination of

technologies and to develop an experimental system to evaluate this hypothesis.

1.3 Aims of the project

The three main aims are stated as for the purposes of providing direction to the project

are described as follows.


17/139

8

To analyse the features and limitations of Bluetooth and Java technology and

investigate what scenarios could benefit from a wireless application

implemented using this combination.

To define a specification for an experimental Bluetooth/Java application anddesign a solution to this specification using available technologies. The solution

will be a wireless system that provides a service of value to the end user via a

graphical interface.

Implement the prototype solution and evaluate the value of the Bluetooth/Java

system from the perspective of the user in terms of the added convenience from

traditional methods of using the service.

Initially, a requirement of the experimental application was that it would run on the

BlueMod hardware supplied by HCV Wireless. However, due to problems with the

availability of the devices, a decision was made to use the Compaq Ipaq instead. In any

case, the final implementation of the system will use a mobile information device with

an LCD screen to provide services to the user.

1.4 Plan for delivering the project goals

The project will involve 4 stages: research and analysis, design, implementation and

evaluation.

1.4.1 Research and analysis

During this stage, research will be conducted into the Bluetooth specification and Java

technology with the following objectives:

To obtain an understanding of Bluetooth technology and to identify its strengths

and limitations.

To research Java technology with the view of using it with a Bluetooth device.


18/139

9

To research market opportunities for Bluetooth/Java applications and select an

appropriate application to design and implement.

To develop a specification for the application. To identify criteria used to evaluate the value of the application to the end user. To critically examine previous work conducted on integrating Java and

Bluetooth technologies.

1.4.2 Design

During this stage, a design will be developed for the specification conceived in the

previous stage. In particular, the following outcomes of this stage are:

Identification of architecture for the system required by the application. Assumptions are identified. Alternatives for the system components researched and evaluated. Documentation of a conceptual design for all system components and overall

design for integration of these components. This may include documentation of

design methodologies.

1.4.3 Implementation

During this stage, the actual implementation of the system design will take place.

Problems in implementing the original design will be identified and design

modifications conceived and tested. A working implementation that meets the

specification will hopefully be the outcome of this stage.

1.4.4 Evaluation

In this stage, the finished system will be evaluated for the value brought to the user. In

addition, the design methodologies will be evaluated as to there effectiveness in

delivering the required outcomes. Finally the project will be evaluated as to how well

the goals of the project were achieved.


19/139

10


20/139

11

Part 2 Research and Analysis

2.1 Overview

This section of the project documents the work undertaken in the research and analysis

stage of the project. This includes the following

An overview of Bluetooth technology and its strengths and weaknesses. Research into Java technology with the view of using it with a Bluetooth device. A critical examination previous work conducted on integrating these two

technologies. Research of market opportunities for Bluetooth/Java applications and the

selection of an appropriate application to design and implement.

A specification for the application. Criteria used to evaluate the value of the application to the end user.

2.2 Overview of the Bluetooth Specification

In order to understand the capabilities of Bluetooth technology and how it can be used

for applications, it is necessary to understand how the various layers of the specification

work together to provide wireless connectivity for a variety of purposes. This section

briefly examines the Bluetooth specification [2]. The specification is divided into two

parts, the core and the profile sections. The core section specifies the protocols that

make up the Bluetooth stack. The profile section specifies profiles, which detail how

the various protocol layers should be used to implement a certain usage case. The

Bluetooth protocol stack is shown in figure 1.

2.2.1 The Radio

The Bluetooth radio operates in the unlicensed International Scientific and Medical

band of the frequency spectrum, which extends from 2.40-2.4835 GHz. This band is


21/139

12

available worldwide, apart from a few countries which place restrictions on which parts

of the bands may be used.

The radio uses a frequency hopping spread spectrum system to minimise interference

from other devices that uses this band (such as microwave ovens). The band is divided

into 79 channels spaced at 1MHz and the radio performs frequency hops 1600 times per

second. The radio uses Gaussian Frequency Shift Modulation with a BT product of 0.5.

The Bluetooth specification allows for three classes of radios with different power

outputs as shown in Table 1.

Logical Link Control and Adaptation

Protocol

RFCOMM Service DiscoveryProtocol

OBEX

Link Manager Protocol

Baseband Layer

Host Controller Interface

PPP

Radio

Figure 1. The Bluetooth Protocol Stack


22/139

13

Table 1. Bluetooth Radio Classes

Radio Class Maximum Output power

(mW)

Approximate Range (m)

Class I 100 100

Class II 2.5 10

Class III 1 0.1

2.2.2 The Baseband Layer

The Baseband layer controls access to the physical medium through the Bluetooth radio.

Among the services this layer provides include:

Inquiry procedures for discovering other devices Functionality for devices to synchronise their clocks and establish links on the

correct hopping frequencies.

Error correction Data whitening Flow control Functions for generating encryption keys

A collection of Bluetooth devices sharing a single channel is known as a piconet. In

each piconet, one device acts as the master device, while the others as act as slaves. Up

to seven slaves can be active in a piconet. The Bluetooth standard uses Time Division

Multiplexing for communication across the link between the master and the slaves. The

channel is into time intervals know as slots corresponding to the duration of one

frequency hop. The slots are numbered corresponding to the master devices clock and

the master uses even number slots to transmit while the slaves use odd numbered slots.

The Baseband supports two types of links, Synchronous Connection-Oriented (SCO)

and Asynchronous Connection-Less (ACL). SCO links is a circuit switched type link

between the master and a single slave that uses reserved slots at regular intervals to

generally carry voice information. ACL links do not use reserved slots, but rather are


23/139

14

created by the master on a per slot basis to any of the slaves in the piconet. There are

five logical channels across these links that provide for control information, link

management information, user synchronous data, user asynchronous data and user

isosynchronous data.

2.2.3 Link Manager Protocol

The link manager protocol (LMP) is responsible for utilising the Baseband services to

carry out link setup, configuration and authentication and in addition may manage

optional quality of service and power control modes. The protocol defines protocol data

units (PDU) to carry out particular service operations. These PDUs are sent over the

link management channel.

2.2.4 Logical Link Control and Adaptation Protocol (L2CAP)

The Logical Link Control and Adaptation Protocol provides connection-orientated and

connectionless data services to the upper transport layer of the Bluetooth stack. The

protocol multiplexes upper layer data onto a single ACL connection and between two

devices. Should the device be the master of the piconet, then this data is then directed

Master Slave

Slave

SlaveFigure 2. A Bluetooth Piconet


24/139

15

to the appropriate slave. L2CAP provides segmentation and reassembly of the data to

fit into the required packet sizes of the Baseband. L2CAP is based around the idea of

channels, which represent a flow of information from a particular upper layer. Each end

of L2CAP channel is locally assigned a Channel Identifier (CID). Each layer above

L2CAP is assigned a Protocol Services Multiplexer (PSM) which is assigned to eachchannel to allow for multiplexing.

2.2.5 Host Controller Interface

The lower layers of the Bluetooth stack - the Radio, Baseband and LMP are usually

implemented as a separate hardware module that is added to the host device. Thus, if

the upper layers are implemented in software there needs to be a standard interface

between them and hardware. The Host Controller Interface (HCI) was designed to

allow a universal set of commands to access Bluetooth hardware. The HCI driver is a

software entity that resides on the host to provide access to the hardware via the HCI

over a transport bus. The transport bus can either be RS232, UART or USB. A HCI

controller on the Bluetooth hardware accepts and implements these commands from the

transport bus and forwards messages from the lower layers to the HCI driver.

2.2.6 RFCOMM

The RFCOMM layer, based on the TS 07.10 standard, emulates a RS232 serial

connection over a L2CAP channel. The standard supports multiple serial ports to be

emulated over a single connection.

2.2.7 PPP

The Point-to-Point protocol is used when mapping a Transmission Control

Protocol/Internet Protocol (TCP/IP) over a serial connection. The protocol is used in

the Bluetooth specification to allow TCP/IP connections to be made over a RFCOMM

emulated connection.


25/139

16

2.2.6 OBEX

The Object Exchange standard (OBEX) was originally developed by the Infrared Data

Association but was reused by the Bluetooth specification. It specifies a protocol that

allows users to exchange data objects, and manage folders on remote devices. Objectsmay be in the format of files or the vCard, vCalendar, vMessage and vNotes formats.

2.2.7 Service Discovery Protocol

The Service Discovery Protocol (SDP) is an important feature of the Bluetooth

standard. It allows for a device to query another device in order to discover the services

available over the Bluetooth connection. This is critical for the ad hoc networking and

automatic configuration capabilities of Bluetooth technology.

2.2.8 The Bluetooth Profiles

The Bluetooth Profiles are designed around envisaged usage models for the technology,

such as allowing LAN access and file transfer. The profiles specify how the protocols

of the Bluetooth stack should be used by applications to provide the services of a

particular usage model. This is necessary to minimise the chances of interoperability

problems between different implementations for a particular model. Note that some

authors (eg. [4]) believe the profiles still leave too much open interpretation to provide a

necessary level of interoperability. Nevertheless, the architecture of the Bluetooth

profiles in shown in figure 3. A profile encapsulated within another indicates a

dependency on the encapsulating profile. The main profiles applicable to application

development are discussed further.


26/139

17

2.2.9 Generic Access Profile

Every Bluetooth device must at least support the Generic Access Profile (GAP). The

purpose of the profile is to define procedures so that any Bluetooth device can a least

connect to and discover the capabilities of another remote Bluetooth device, even if

both share no common application. The GAP specifies the following:

User interface requirements regarding Bluetooth parameter representation and

connection procedures.

The three modes of discoverability for devices non-discoverable, limited

discoverable and general discoverable.

Non-connectable and connectable modes.

Service DiscoveryApplication Profile

Cordless TelephonyProfile

Intercom Profile

Serial Port Profile

Dial-up NetworkingProfile

Fax Profile

Headset Profile

LAN Access Profile

Generic Object ExchangeProfile

File transfer Profile

Object Push Profile

Synchronisation Profile

Generic Access Profile

Figure 3. Profiles of the Bluetooth Specification


27/139

18

Three security modes and authentication procedures. The general procedures for discovering the identity, name and basic capabilities

of other Bluetooth devices and making connections.

2.2.10 Service Discovery Profile

The purpose of the Service Discovery Profile is to define procedures for a service

discovery application to locate the services available to other devices. For the purposes

of this profile, a service discovery application is a specific user-initiated application

rather than an automated process. The profile covers searching for services by class and

attribute as well as browsing services.

2.2.11 Serial Port Profile

The serial port profile describes the procedures necessary to emulate a RS232 serial

connection. This is used to facilitate other applications that use serial connections.

These applications may be defined by the developer, or they may be defined by other

profiles such as dial-up networking, faxing and LAN access.

2.2.12 Generic Object Exchange Profile

The Generic Object Exchange Profile (GEOP) profile provides three main features to

the user application.

- Establishing an object exchange session.

- Pushing a data object.

- Pulling a data object.

Other features are defined by the profiles that use (GEOP) including the object push,

file transfer and synchronisation profiles.

2.3 Java 2 Micro Edition

With Bluetooth technology is generally incorporated into embedded devices that lack

the computational power, memory and storage capacity of the average desktop


28/139

19

computer, it is necessary to use a Java platform with smaller performance requirements

than the standard version. In response to the growing embedded device market, Sun

Microsystems have developed the Java 2 Micro Edition (J2ME) platform, a Java

environment aimed at smaller systems with limited resources. Sun claims [15] that

J2ME supports many of the main features of the larger Java version including:

- Portability of code

- A high-level object oriented language

- Safe network delivery

The J2ME has the architecture shown in figure 4.

Embedded Device

Configuration

Host Operating System

Profile

Figure 4. Java 2 Micro Edition Platform Architecture

Virtual Machine

JavaPlatform


29/139

20

2.3.1 Virtual Machine Layer

This Layer represents a virtual machine customised for a particular host operating

system. The virtual machine supports a particular configuration.

2.3.2 Configuration Layer

The configuration layer defines the minimum set of virtual machine features and class

libraries for a particular category of device. Currently there are two configurations for

the Java 2 Micro Edition platform. The Connected, Limited Device Configuration

(CLDC) is targeted at very small resource constrained devices with the following

characteristics:

- memory available to Java between 160kB and 512kB

- 16-bit or 32-bit processor

- battery powered

- sporadic network connectivity

This configuration is designed for the Kilobyte Virtual Machine (KVM), which is

smaller than the virtual machine used for Java 2 Standard Edition and optimised for

embedded systems. The CLDC supports a subset of capabilities of the Java 2 Standard

Edition. Examples of devices that may support this configuration are mobile phones

and pagers. Additionally, J2ME also defines the Connected Device Configuration for

more powerful embedded devices. This configuration is design for devices with over

2MB of memory and has a greater feature set than the CLDC.

2.3.3 Profile Layer

The profile layer is designed to add the additional functionality required on certain

categories or kinds of device. Sun describes this as providing support for vertical

market segments, in their belief that portability is most important across devices with

similar functional purposes. For example, a washing machine program should be

portable across washing machines, but not necessarily mobile phones.


30/139

21

There is currently only one profile available for practical purposes, which is the Mobile

Information Device Profile (MIDP). As the name suggests, this profile is targeted at

mobile information devices, particularly mobile phones, and specifies a Java API for:

Application lifecycle User interface Persistent storage Networking Timers

MIDP applications, known as MIDlets, are designed to be downloaded dynamically to

the mobile device and executed in a safe virtual machine environment. This idea has

already been extended to wireless systems where wireless delivery is already proving

promising with internet enabled cellular phones. Over 23 million J2ME enabled mobile

phones were sold in 2003 [1]. A large proportion of these are expected to have

Bluetooth capabilities. Thus the MIDP could serve well for Bluetooth applications.

The wireless delivery of MIDP applications could also be extended to using Bluetooth

connections rather than the cellular system.

2.4 Bluetooth API

Clearly for a Java application to maintain portability across a range of Bluetooth

devices, there must been some form of standardised API to access the services offered

by the Bluetooth stack. As part of the Java Community Process (JCP) a Java

Specification Request (JSR) was approved in October 2000 to design the architecture

and associated APIs to allow developers to utilise Bluetooth technology in Java

applications. An expert group was formed comprising of 21 members and lead by

Motorola to devise the specification. After significant public review inherent to theJava Community Process, the final specification, JSR-82, was approved nearly one and

a half years later in March 2002 [5].

One of the main barriers to the prevalence of Bluetooth applications is the differences in

the interfaces between propriety Bluetooth stacks. The Bluetooth Java API is intended


31/139


32/139

23

determine if a Bluetooth product is practically viable. Six loosely defined conditions

are suggested that a product or application should adhere to:

Adds usability, convenience and ease-of-use

The whole philosophy behind Bluetooth technology is that it adds value and

convenience to a product. Developers are warned to ensure that there end product will

actually deliver this, and not just be a wireless gimmick.

Unaffected by interference and latency

Because of the nature of wireless communications, Bluetooth is susceptible to

interference from a range of other radiation sources, including microwave ovens,

thunderstorms and other wireless systems such as 802.11b. Hence, any Bluetoothapplication must be able to tolerate occasional loss of connectivity. Obviously, this

makes the technology unsuitable for critical, high integrity systems.

Tolerant of connection time overhead

The process of discovering other devices and forming connections can take a number of

seconds. Applications need to be able to handle this delay.

Works with available bandwidth

Bluetooth connections have a maximum data rate of 723.2 Kbps, and the actual rate is

likely to be less that this. Applications must work sufficiently well within this data rate

limit.

Can meet power requirements

Wired communication cables often also provide power to a device. If a wired device

become wireless, an alternative means of providing power must be found and power

consumption becomes more important. In the case where the device is already battery

operated, using the Bluetooth radio will shorten the battery life, so the application must

usable given the power constraints of the device.


33/139

24

The range of the wireless connection is adequate

Bluetooth is a short range technology, thus an application running on a Bluetooth device

must be operatable within the range of the receiver. The range of a Bluetooth

connection varies depending on the class of radio used and the environmentalconditions but is generally between 10m and 100m.

2.6 Other requirements for the experimental application

As was stated in the basis for this research project, the experimental application was to

be designed to incorporate a graphic user interface for the HCV Wireless BlueMod

device. The BlueMod, along with PDAs and advanced mobile phones are classed by

Sun as mobile information devices. Consequently, the application would be

developed in accordance to the Mobile Information Device Profile and would need

suited to this profile. Thus, in exploring possible applications the search is limited to

those that would involve a mobile information device.

Because of problems with availability of the BlueMod, the Compaq Ipaq 3870 was

chosen as replacement hardware. One of the challenges for Sun in specifying profiles

for the J2ME platform is trading off uniformity against more offering powerful features.

Similarly, application developer must decide whether to take advantage of the more

powerful features in the more advanced profiles, or to design for portability across all

devices. Though the Ipaq is actually capable of running more powerful Java

configurations and profiles, the application will still be designed for the MIDP for

consistency throughout the project

2.7 Market for Bluetooth Applications

Beyond the usage models based on the profiles, suggestions for Bluetooth are numerous

and varied. This section aims to categorise the types of wireless services andapplications that could be served by Bluetooth technology. From these groups, an

experimental application will be selected that is appropriate to develop for the Java

MIDP


34/139

25

2.7.1 Wireless Commerce

Undoubtedly, one of the largest demands for applications will be for wireless

commercial services. There is expected to be a huge market for wireless systems that

provide convenient methods for consumers and organisations to make transactions and

conduct business. There are two common business models for classifying the types of

wireless services. Business-to-consumer (B2C) models represent services offered to the

consumer by business organisations, while business-to-business (B2B) models involve

the services between business entities. B2C is expected to be more prevalent in wireless

systems [12].

Varshney and Vetter [23] describe a number of classes of emerging B2C applications.

These include:

- Mobile Financial Applications

- Mobile Advertising

- Mobile Inventory Management

- Proactive Service Management

- Product Locating and Shopping

- Wireless re-engineering

- Mobile Auctions

- Mobile Entertainment

- Mobile Office

- Mobile Education

- Wireless Data Centre

- Mobile Music

Many of these applications are more suited to cellular networks with a much larger

coverage area than the short-range Bluetooth standard, for example mobile education.

While cellular systems provide a greater coverage range, they currently support lower

bandwidths than Bluetooth technology and require more expensive infrastructure which

is passed on as a cost to the consumer. Thus, some wireless service providers may


35/139

26

compete with cellular systems by providing similar services by Bluetooth access

points in selected highly populated places (such as shopping centres).

2.7.2 Location aware mobile commerce services

The short range of Bluetooth connections is not necessarily a limitation, but could

actually be exploited to provide the user with services relevant to where they are. For

example, a user who enters a store is most likely interested in accessing services

provided by the store, such as locating or purchasing a product. Kannan, Chnag and

Whinston [12] suggest these location aware services could a large impact on marketing,

because services could be provided at the point of need. Thus, the customer is provided

with services most relevant to their personal tastes and characteristics.

The short range and automatic connectivity features of Bluetooth technology would

make it an appropriate choice for location aware services. A Bluetooth equipped

personal device could form a connection when the user comes within proximity of an

access point. The Service discovery profile could then be used by the user to find

services at that location. Even further, the Java 2 Micro Edition platform could be

utilised as a standard and safe execution environment to dynamically deploy

applications at the point of need. The Mobile Information Device Profile could then be

used for the user interface to access the services. It would therefore be beneficial to

incorporate this concept into the experimental application.

In reviewing the classes of applications suggested by Varshney and Vetter [23], some

are more appropriate for a location-aware network than others and are discussed further.

2.7.3 Mobile Financial Application

Varshney and Vetter [23] suggest these applications will be among the most importantfor wireless systems and could involve banking, money-transfer or making payments.

The idea of making wireless payments from within a store has been suggested by many

sources including Millar [9]. This could offer great convenience to the consumer who

could avoid waiting in queues, while the business would hope to achieve greater

revenues from offering the service. Payments to vending machines are another


36/139

27

suggested application [23]. Since the consumer must be in the proximity of the machine

to make a purchase, this situation would be well suited to a location-aware application.

Some of the obvious requirements for mobile financial applications are security and

reliability [23], which are more difficult to implement in wireless systems.

2.7.4 Mobile Advertising

Mobile advertising is well suited to the idea of location-aware applications, because

advertisers could target a particular audience who may be in close proximity of a

business or product. A likely scenario is a shopping complex where the customer could

be providing with information about specials in surrounding shops. A more

controversial approach suggested by Varshney and Vetter [23] involves creating a

collection of information about a person inferred from what places they visit.

Advertisers could then target this person with products that appeal to them. Obviously,

they are numerous privacy issues raised in this approach.

2.7.5 Proactive Service Management

To illustrate this type of application, Varshney and Vetter [23] suggest a situation where

sensors in an automobile collect information about the wear of certain parts and react

via messages over a wireless connection to the owners mobile device. This idea could

be extended to control systems, where information and events could be sent wirelessly

to the user.

2.7.6 Product Location and Shopping

Some researchers advocate complex systems for locating products for the consumer

[12]. Bluetooth technology could be incorporated into this type of application as a

means to access a public wireless service in a shopping centre. The customer could

enter a product name into a mobile information device whilst near a Bluetooth access

point and receive directions to the nearest store stocking that product.


37/139

28

2.7.7 Information services on public networks

With the aid of a mobile information device, consumers could browse or search throughextensive databases for information such as traffic reports, maps, stock quotes, news,

weather, entertainment guides, movie times and much more. Access to these types of

services is already possible through i-mode mobile phones in Japan. With location

based services, information could be filtered such that it is most relevant to where a

person is with their device.

2.7.8 Other non-commercial applications

There are also a number of applications for wireless technology outside commercial

purposes. Bray [3] suggests the medical sector is one area that could potentially benefit

in many ways. Non-critical measurements from sensors and other patient information

from database systems could be made instantly available on a doctors PDA. This could

allow for superior patient record management.

2.7.9 Ad-hoc networking and groupware

One of the strong features of Bluetooth technology is it allows for spontaneous ad-hocnetworks to be formed without existing infrastructure. This type of networking supports

the notion of peer-to-peer networking, where a mobile device acts as both a client and a

server. Kaminsky [6] makes some suggestions for peer-to-peer mobile applications

including

- Chatting and instant messaging between devices

- A whiteboard application where a drawing appears on every users screen and

all users can make changes that become updated on the other users screens.

- Note taking for meetings where the notes are distributed to all other attendees

- Collaborative authoring of documents


38/139

29

2.8 Non-functional requirements and criteria to evaluate the end product

In consistency with the aims governing the project, the completed experimentalapplication should provide a service of value to the consumer. In order to do this, it is

necessary to understand what attributes make a wireless service valuable to a consumer.

The following are suggested as attributes of value:

2.8.1 Added convenience

Probably the biggest reason a consumer would invest in a wireless technology is for

convenience. Using the wireless service should require less resources, time and effort

on the users part to achieve the desired task as compared to the more traditional way.

This could be the case in providing a product locator system, where the user only needs

to enter the name of the product, such as eggs, into a mobile information device

instead of searching through half the supermarket. However, Bray [3] warns that the

convenience of a service can be tarnished by complex connection issues and user

interfaces.

2.8.2 Speed

Closely tied to convenience, a wireless application is obviously more valuable if it is

responsive to the user requests. Applications should be designed to maximise speed

given the processor, memory and bandwidth limitations of the device hardware. The

speed of using the application in comparison to doing the task in the traditional way will

be considered in evaluating the final product.

2.8.3 User Interface

The user interface must be simple and effective to make a wireless application valuable.

Bray [3] suggests this is the biggest challenge in developing a wireless application.

The functional requirements of the project stipulate the user interface must consist of a

touch screen and the graphical components found in the Mobile Information Device

Profile. It will be necessary to work within these limitations to produce an application

that is effective in allowing the user to access the wireless services on offer. Sun


39/139

30

Microsystems publishes the MIDP Whitepaper [21] that describes the differences

between requirements for user interfaces on desktop machines and consumer devices.

The following suggestions are made:

Users of mobile devices expect a user interface far more simplistic than desktopcomputers that requires less technical competence.

The learning curve for the application should be instantaneous without the need

for manuals.

Developers need to take care not to use systems that desktop users that for

granted and mobile device users may not be familiar with.

These suggestions will be considered in designing the graphic user interface for the

application from the MIDP components.

2.8.4 Security

Unlike wired networks which are often hidden behind walls, wireless signals can be

received by anyone within range of the transmitter making them far more susceptible to

unauthorised activities. Wireless applications that involve sensitive information or

access to sensitive resources (such as mobile financial services) must ensure a level of

security that the consumer is comfortable with. The Bluetooth standard specifies means

for providing encryption and authentication, however some researchers have pointed out

weakness in these approaches [22]. The experimental application will endeavour to

provide a suitable level of security which will depend on the type of application chosen.

The value of the application from a security perspective will be evaluated based on

known security weaknesses the measures required to facilitate unauthorised activity.

2.8.5 Reliability

A wireless application is obviously useless if it does not perform the task it is meant to.

The complexity of computer networks makes them inherently susceptible to sporadic

failure. In addition, wireless networks such as Bluetooth may experience connection

failures due to random interference and changes in the surrounding environment. The

MIDP whitepaper [21] suggests that mobile device users are less tolerant of random


40/139

31

software failures than personal computer users. Hence, the appeal an application is

significantly dependent on the reliability of the software and the network system.

2.9 Choice of application scenario

It is decided that because of their revenue earning potential for business, wireless

commerce applications will likely be the most dominate of Bluetooth applications and

this type of application should be selected for experimental development. After

assessing the classes of wireless applications it has been asserted that given the short-

range and automated connectivity features of Bluetooth technology, it would be best

used with a location-aware application. Though peer-to-peer systems might become

prevalent in the future, the first types of applications are likely to be clients on

consumer mobile devices that access business-supplied services on larger servers.Hence the experimental application will necessarily be represented by a client-server

model.

As has been discussed, there are virtually hundreds of scenarios where a Bluetooth

mobile commerce application could be useful. It is simply a creative process to decide

one that is suitable to develop for. One scenario suggested by Millar [9] that could

benefit from a range of mobile commerce applications is a traveller in an airport.

Because airports tend to be busy places, a traveller could find an application that allowsthem to access flight information and make transactions very valuable. Thus, the

experimental application for this project will be based around providing services in an

airport environment.

Again, deciding what services to provide is a creative process for an experimental

application. Normally the software specification would be based on a business model,

however some ideas can be gathered from the travellers information section of the

Brisbane Airport Corporations website (http://www.bne.com.au/trav/index.html ).

Some of the services listed include:

- arrival and departure times

- location of shops and services within the terminal

- weather information

- links to tourist and car hire information
http://www.bne.com.au/trav/index.htmlhttp://www.bne.com.au/trav/index.htmlhttp://www.bne.com.au/trav/index.html


41/139

32

- links to reservation sites

- chatting among travellers

Besides information services, it would be beneficial to incorporate other types of mobile

commerce services, into the application. Thus, the scenario will be extended to includea caf in the airport terminal. Consumers who enter the caf should be able to view and

order items from the menu from a mobile information device. In addition to the

services offered by the caf, it will be assumed that the airport offers a service to check

on the status of a flight

Thus, the specification for the application is summarised as follows:

- A user should be able to view menu items as if they were reading a menu. Thus,

they should be able to browse through a list of names, descriptions and prices for

menu items. The menu is very dynamic, and must be retrieved from the wireless

server.

- A user should be able to create an order of items and submit this order.

- A user should be able to check the status of their flight.

Note originally it was also anticipated that the user could make a payment for their

order. However, research indicated that the security features of the J2ME and Bluetooth

specification are inadequate for such task at present [22].

This application would seem to fit the six criteria defined for Bluetooth applications.

Value is provided to user, because they save time in not having to wait in line or for a

waiter to order. Though undesirable, the application can tolerate the occasional loss of

connectivity due to interference. The power consumption will be device dependent, but

as the service would only be used for a few minutes, the extra power used by the

Bluetooth radio is unlikely to heavily impact on the battery life of the product. Long

connection times are undesirable but tolerable to a certain extent. The data exchangedin the application is difficult to determine at this stage, but is expected to be comparable

to web browsing. The application is expected to be usable with in the data rate

limitation however this will be confirmed during the design stage of the project. Finally,

based the application is location sensitive and range limitation of Bluetooth radios is

acceptable.


42/139

33

2.9 Critical evaluation of previous work performed on Bluetooth and Java

Applications.

Work towards the development of Java based Bluetooth application starts from the

specifications [2] for both technologies. Both the core and profile parts of the Bluetoothspecification are available from the Bluetooth SIG website and combined total over

1500 pages. Other resources, including Miller & Bisdikian [10], Muller [11] and

Kansal [7] provide a helpful companion for information about the specification. The

specification itself is the authority that defines Bluetooth technology and all

development will conform to the specification.

With respect to Java, there are three specifications relevant to this project that will be

followed. The Connection, Limited Device Configuration Specification Version 1.0a.by Sun Microsystems [18] defines the specification for the CLDC while Mobile

Information Device Profile (JSR-37) JCP Specification Java 2 Platform, Micro

Edition, 1.0a [19] specifies the MIDP Profile. Both these documents will be used as the

authority for using and developing for the CLDC and MIDP. Furthermore, the JSR-82

[5] specifies the Bluetooth API for the CLDC. The JSR-82, MIDP and CLDC

specifications are essential for maintaining the portability of Java Bluetooth applications

and will be adhered to throughout the project. The Java Community Process governing

the development of these standards is likely to ensure they serve their purpose well, butthey will still be subjected to evaluation as part of this project.

Unlike most other resources that simply provide and explanation of the Bluetooth

specification, Bray [3] is targeted at providing information for developers planning to

develop Bluetooth applications. It provides a critical examination by experienced

Bluetooth developers of the Bluetooth standard in terms of its technical strengths and

weaknesses. This resource provides criteria for the suitability of Bluetooth applications

which has been adopted for this project. In addition, it provides examples of how to

utilise the various features of the Bluetooth stack with applications.

The commercial potential of integrating Java and Bluetooth technologies is already

being exploited by a number of companies. San-Diego based Zucotto Wireless has

developed a Java based JSR-82 compatible Bluetooth stack that it has incorporated into


43/139

34

its WHITEboard SDK for creating J2ME applications. The Zucotto stack is written

entirely in Java, rather than being an API to native code. This is surprising, given native

code is generally has a faster execution time. However, Zucotto also has been

developing processors that can run Java bytecode, so their strategy would seem to be to

alleviate the relatively slow execution of Java code. Unfortunately, the Zucotto stack istoo expensive to be used in this project [20].

Irish based Rococo is also a heavy proponent of Bluetooth and Java based technology

with CEO Karl McCabe highlighting the portability and mobility aspects of Java being

important to development of Bluetooth applications [24]. Rococo produce

Java/Bluetooth simulators and development kits, but again these are unavailable to the

project. Both these commercial interests show shared ideas regarding the potential for

Java and Bluetooth, but no development towards the project objectives can really be

leveraged. Likewise, these companies do not provide any critical feedback on the

results of their applications development.

One of the few documented cases of research into the development of a Java/Bluetooth

application involves an investigation by the US Army into a replacement for the

Handheld Terminal Unit (HTU) which is a portable device used by soldiers to send

tactical information about the battlefield back to the commanders computer. The army

was considering using portable, platform independent software systems to reduce the

costs of maintaining proprietary software. The HTU was to be replaced by a less

expensive PDA which connected wirelessly to a more powerful transceiver. The results

of the project indicated that Bluetooth was not a viable alternative to use with Java

because basically no implementation of Bluetooth APIs existed. Research conducted

for this project agrees with this conclusion, as implementations of Bluetooth APIs for

Java are scarce and none are freely available [25]. This project intends to extend this

work by implementing certain portions of the JSR-82 API to use for the experimental

application.

Finally, there has been two projects undertaken that research the application of

Bluetooth and Java to distributed applications. The Anhinga Project [6] undertaken at

Rochester Institute of Technology is looking at developing middleware for ad-hoc

networks based on Bluetooth and Java technology. The philosophy behind this project


44/139

35

is that software developed for ad-hoc networks requires a many-to-many

communication paradigm not well supported by existing middleware systems. Thus,

the Anhinga Project aims to produce a middleware system, based on Bluetooth and Java

technology, for supporting groupware applications. A large part of this project

involves implementation of a many-to-many network protocol that works over theBluetooth HCI. The protocol provides an interface to a modified version of a CLDC

virtual machine.

There are a few differences between the aims of the Anhinga Project and this thesis

project. The Anhinga Project focuses on peer-to-peer networking, while the

experimental application developed for this project is necessarily based on a client-

server architecture. Secondly, the Anhinga Project seems to disregard the JSR-82 API

in favour of developing a middleware API to be used by applications. Finally, the

Anhinga Project looks at using Suns JINI as part of there middleware system. This

requires additions to the CLDC specification. Thus the Anhinga project does not

conform well to the JSR-82/MIDP/CLDC standards and appears more directed towards

developing a specific middleware standard. In contrast, this thesis project focused on

delivering an application and system that conforms to the MIDP/CLDC and JSR-82

standards to ensure portability. Despite the differences, both this thesis project and the

Anhinga Project are consistent in there motivations to deliver portable software

environments for short range wireless systems.

The use of JINI for Java and Bluetooth systems is also addressed by Hashman and

Knudsen [4]. This paper, produced by the company PsiNaptic, claims a scaled down

version of JINI has been produced, but it is unclear whether this configuration can work

with the CLDC.

To summarise, this project is based on the work done in producing the Bluetooth,

CLDC, MIDP and JSR-82 specifications. The project takes the next step in addressing

how these technologies can be integrated and will produce an experimental application

as proof of concept. The book Bluetooth application developer's guide : the short

range interconnect solution [5] is one of the few resources available on developing

Bluetooth applications and will be used to assist in the design process. Previous work

towards developing Java and Bluetooth applications is limited, but suggests


45/139

36

implementations of a Bluetooth API are difficult to obtain and the CLDC limits the

capacity for the dynamic downloading of applications.


46/139

37

Part 3 Design

3.1 Overview

This section documents the design process taken in delivering the outcomes of thisproject. This includes the follows steps:

Identification of architecture for the system required by the application is

undertaken.

Assumptions are identified. Alternatives for the system components researched and evaluated. Documentation of a conceptual design for all system components and overall

design for integration of these components. This may include documentation of

design methodologies.

3.2 System architecture

A block diagram of the system proposed in this project is shown in figure 5. In normal

operation, the mobile client discovers the gateway and forms a connection when the

user brings the device into proximity. The user can then discover and browse through

services available from the gateway. Should the user wish to use a service, the mobile

device will automatically download and run any Java MIDP applications needed to use

that service.

3.2 System Assumptions

Before beginning the design process, some assumptions are made to simplify the

considerations that must be made.

The gateway and the server are not necessarily the same device. The services

available at the location of the access point are not necessarily located on the

access point device. Access points are likely to be small devices that connect

wireless devices to a wireless network.


47/139

38

Access to information services from the gateway to the servers will be assumed

to be IP based over an unknown LAN topology. In a real scenario, the

characteristics of the LAN would impact on the performance of the delivery of

the Bluetooth services. However, the experimental system will use a dedicatedpoint to point connection that is faster than the Bluetooth connection, so the

LAN will be assumed to have no bearing on the client applications

performance.

The experimental application will use a single server to model the caf and

airport server to save on resources and because the topology of the network is

assumed to be irrelevant.

As the focus of the project is on the client and wireless networking issues, the

design of applications to utilise and change data on the server will not be

considered. These types of applications are common and no pioneering work is

required is this area.

A single gateway is assumed to provide wireless access for the whole caf.

Depending on the size of the caf and the class of the Bluetooth radios used by

the mobile device and the gateway, this may or may not be a realistic situation.

From the servers perspective, multiple gateways would simply have multiple IP

addresses, so if say a web server was to be used, this would have little impact on

the design. Likewise, the mobile device only would need to locate and connect

to one gateway to access the service. However to keep resource requirements

for the project low and single gateway design will be used.

The initial design will assume only one client will connect to the gateway at any

one time. This is an unrealistic expectation but because of resource limitations it

is infeasible to test multiple clients trying to access the server simultaneously.

The system may theoretically be able to support multiple clients through.

The mobile device will be a PDA capable of running the MIDP.


48/139


49/139

40

requirements. It was also very similar to the BlueMod, the original devices to be used

in the project. It is a very powerful device for a PDA, with 32MB of onboard SDRAM

memory and a 206 MHz Strong Arm processor. This should ensure plenty of flexibility

for development work.

The architecture for the mobile device is shown in figure 6. The components

surrounded by a dashed line will be implemented by third party developers and selected

from alternatives as part of the complete software integration design. The components

surrounded by a bold line will be implemented as part of the research. Starting from the

bottom, the device hardware includes the Ipaq 3870 and the built Bluetooth radio. The

next layer, the operating system, will be dependant the Java Virtual Machines and

Bluetooth stacks available. The options include Microsofts PocketPC 2002 which

comes standard with the Ipaq or a version of Linux. Part of the operating system layer

Device Hardware

Operating System Bluetooth Stack

Java VirtualMachine

CLDC Classes Bluetooth API Classes

Java ApplicationManager / Service

manager

Java nativeBluetooth

library

MIDP Classes

Application

Figure 6. Architecture of Software Components on the mobile device


50/139

41

will include a Bluetooth stack that provides services for the application to access via the

Java Bluetooth API. The Bluetooth stack will be selected on the basis of cost, features

and programmers interface.

The next layer noted is the Java Application Manager / Service manager component.This component is defined in the MIDP specification [19] as an environment in which

the MIDlet is installed, started, stopped, and uninstalled. In this project, the role of this

component is extended to discovering what services are available to the user at a

particular location and to retrieve and run the necessary Java program. This component

would exist as a process in the operating system.

The remaining layers are responsible for providing the actual Java execution

environment. A virtual machine is required that is capable of supporting the CLDC and

MIDP API. In the layers above the virtual machine are the Java Classes required by the

CLDC and MIDP. Additionally, a Bluetooth API will need to be incorporated into the

Java execution environment. The API will include two parts, native methods

incorporated into the virtual machine layer that interface with the Bluetooth Stack and

Java classes to provide the JSR-82 API for the application to use. An alternative would

be to use a Java based Bluetooth stack, such as the as one developed by Zucotto [20],

this is very expensive to obtain and to difficult to implement given resource and time

restraints of this project. The native and Java Bluetooth libraries will therefore need to

be implemented because they are not readily available to developers. Only the parts of

the JSR-82 API required by the application will be developed.

3.4 Network Arc

java applications for a bluetooth plataform

Documents