an examination of mobile devices for spontaneous ... · an examination of mobile devices ... the...

Depth project in the courseTDT4735 Software engineering, Depth studies

An examination of mobile devices for spontaneous collaboration

Lars Kirkhus & Anders R. Sveen

Subject teacher and supervisor: Associate Professor Alf Inge Wang

Norwegian Univerisity of Science and Technology

Department of Computer and Information Science

Fall 2003

Abstract

This project explores mobile technologies for use in spontaneous collaboration. Small commerciallyavailable devices like mobile phones can be a useful tool for initiating contact and exchanging infor-mation.

This article researches available devices and wireless technologies to find a technology platform. Whena platform is found we proceed to do some in depth research on the technologies and some simpletests of their characteristics.

Our testing concentrates around JSR-82, which is the new Bluetooth API for J2ME. This is a fairlynew technology, and we found that at the time of writing no mobile phones were available. Thisled us to propose a solution based on PCs and Bluetooth USB dongles that would let us test thecharacteristics of Bluetooth and JSR-82, but leave the development of a full MIDP 2.0 prototype forlater.

The results in this article describe the responsiveness of Bluetooth as discovery times and transferrates. This will be important in a prototype of an spontaneous collaboration application later on.The results achieved were adequate, but there could arise some problems because of the design ofBluetooth.

3

Preface

This project has been carried out by Lars Kirkhus and Anders Sveen during the fall semester of 2003.The project is related to the course TDT4735, Software Engineering, Depth Study, which is part ofthe Masters degree at the Norwegian University of Science and Technology [27]. It has been assignedby the Software Engineering Group [28] at the Department of Computer and Information Science [26].It accounts for fifty percent of this semesters curriculum.

AcknowledgementsWe would especially like to thank Alf Inge Wang for his guidance in writing this report. It has beenof invaluable help to us to hear his viewpoints and benefit from his experience.

Trondheim 29th of November, 2003

Lars Kirkhus Anders R. Sveen

4

Contents

1 Introduction 101.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.2 Problem definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.3 Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.4 Readers guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1.4.1 The parts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

I Prestudy 14

2 State of the Art 162.1 IPAD/Hummingbird . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.2 Proxy Lady . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.3 Proem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.4 The Thinking Tag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3 Technology study 203.1 Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.1.1 Mobile Phone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.1.2 Personal Digital Assistant (PDA) . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.2 Development Platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.2.1 J2ME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.2.2 Mophun . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.2.3 BREW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.2.4 Symbian . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.2.5 Microsoft Smartphone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.2.6 Palm OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.3 Wireless Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.3.1 Infrared . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.3.2 Wireless LAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.3.3 Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4 Technology evaluation 324.1 Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324.2 Development platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324.3 Wireless technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

5 Indepth technology study 355.1 Java 2 Micro Edition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

5.1.1 J2ME Building Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365.1.2 Configuration and virtual machine . . . . . . . . . . . . . . . . . . . . . . . . . 375.1.3 Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

5

CONTENTS

5.1.4 J2ME and Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385.2 Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

5.2.1 History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395.2.2 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405.2.3 Radio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405.2.4 Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415.2.5 Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425.2.6 Connecting Bluetooth devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425.2.7 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

II Development and Testing 45

6 Planning 476.1 Test and development environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

6.1.1 Compatible implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 486.1.2 Full simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 486.1.3 Partial simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 486.1.4 Partial implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

6.2 Conclusion and solution for development . . . . . . . . . . . . . . . . . . . . . . . . . . 49

7 Requirements specification and Design 507.1 Functional requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

7.1.1 Execution of server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517.1.2 Execution of client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517.1.3 Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

7.2 Non functional requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 527.3 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

7.3.1 Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 527.3.2 Program sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

8 Implementation and testing 558.1 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

8.1.1 Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 568.2 Test execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

8.2.1 The testing environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 588.2.2 Test Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

III Results and Evaluation 60

9 Test Results and Evaluation 629.1 Device discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 629.2 Service discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 669.3 File transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 699.4 Maximum range . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 729.5 Result summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

10 Problems and Solutions 7310.1 Buffer size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7310.2 Bluetooth hardware cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7310.3 Long device discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

6

CONTENTS

IV Conclusion and Further Work 75

11 Conclusion 76

12 Further Work 7712.1 Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7712.2 P2P-networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7712.3 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7812.4 Social networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

V Appendix 80

A Implemented CLDC Classes 82

B Source code 84

C Test Result Tables 99C.1 Device Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100C.2 Service Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101C.3 File transfer rates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

Index 102

Bibliography 105

7

List of Tables

3.1 Attribute table for evaluation of technologies . . . . . . . . . . . . . . . . . . . . . . . 203.2 Attribute table for mobile phone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.3 Attribute table for PDA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.4 Attribute table for J2ME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.5 Attribute table for Mophun . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.6 Attribute table for BREW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.7 Attribute table for Symbian . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.8 Attribute table for SmartPhone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.9 Attribute table for Palm OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.10 Comparison of wireless technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.11 Attribute table for IR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.12 Attribute table for WLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.13 Attribute table for Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.1 Device comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324.2 Development platforms comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334.3 Choice of wireless technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

5.1 Bluetooth device classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415.2 Example Bluetooth service IDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

C.1 Device discovery results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100C.2 Service discovery results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101C.3 File transfer rate results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

8

List of Figures

2.1 The Hummingbird prototype [14] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.2 Proxy Lady, A PDA equipped with a radio transceiver [29] . . . . . . . . . . . . . . . 172.3 Proem wearable computer [9] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.1 Nokia 6600 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.2 Compaq iPAQ HP3630 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

5.1 J2ME Layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365.2 Inherited classes in J2ME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375.3 Example Bluetooth device: Motorola handsfree for mobile phone . . . . . . . . . . . . 395.4 Bluetooth stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405.5 Example of Bluetooth protocol relationships . . . . . . . . . . . . . . . . . . . . . . . . 415.6 Piconet illustrating master and slaves . . . . . . . . . . . . . . . . . . . . . . . . . . . 435.7 Bluetooth scatternet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

7.1 Classes designed for the test suite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 537.2 Sequence of communication between server and client for testing . . . . . . . . . . . . 54

8.1 3Com Wireless Bluetooth USB Adapter . . . . . . . . . . . . . . . . . . . . . . . . . . 59

9.1 Device discovery, 1m . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 639.2 Device discovery, 6m . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 639.3 Device discovery, 10m . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 649.4 Device discovery comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 659.5 Service discovery, 1m . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 669.6 Service discovery, 6m . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 679.7 Service discovery, 10m . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 679.8 Service discovery comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 689.9 File transfer rate, 1m . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 699.10 File transfer rate, 6m . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 709.11 File transfer rate, 10m . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 709.12 File transfer rate comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

Chapter 1

Introduction

Technology that enables collaboration regardless of geographical location is a large research field. Ithas been explored for a long time, but the continuous emergence of new technologies has made it annever ending research field.

The development of the fax-machine has enabled people to share written information faster thanthrough ordinary mail. The development of the web has put vast amounts of searchable informationat the fingertips of common people, and the emergence of mobile technologies is creating an alwaysavailable culture where you can reach anyone, anytime, anywhere.

In this project we wish to explore mobile technology for use in spontaneous collaboration. In thefollowing chapter we will outline our focus and the problems we are facing.

1.1 Motivation

Merriam Webster dictionary1 defines collaboration as:

1 : to work jointly with others or together especially in an intellectual endeavour2 : to cooperate with or willingly assist an enemy of one’s country and especially

an occupying force3 : to cooperate with an agency or instrumentality with which one is not

immediately connected

This report will focus on the first definition of the word collaboration. Where two or more people gettogether to create something by sharing their knowledge and skills.

Spontaneous, informal collaboration happens many times each day. Meeting a colleague in the hallway,talking to a friend at the local grocery store, or chatting with someone on the Internet can all becollaboration. Common for many of the collaboration scenarios in your daily life is that you collaboratewith people that have special expertise you require. They might have in-depth knowledge of an arearelated to your work, or they can help you perform tasks you are not qualified to do.

You may know or not know these people beforehand, but through exchange of information you build acommon ground for collaboration. This exchange of information to initiate or facilitate collaboration

1http://www.m-w.com

10

1.2 Problem definition

can take many forms. It might be exchange of personal details, broadcasts of available work positions,broadcasts of required attributes or a collection process of all information about participants.

Kortuem et al. [9] claims in their article that profile-exchange during chance encounters can facilitatecollaboration. By exchanging profiles between users that are not necessarily face to face, other possibleinteractions are facilitated. If a user receives a profile that seems interesting she might initiate otherforms of contact with that user.

We picture the following scenarios; you are at a convention, an airport or maybe on a busy street-corner. Everyone around you are strangers, but you want to talk to someone with similar interestsas you, or you might need information about a specific subject. How would you go about meetinganother person with the qualifications you seek? Through technology you might get help to initiatefirst contact. Your PDA can be programmed to beep and show a profile when a person working withinthe same field of research is near by, or it might just store the information for future reference as youmeet people on the street.

The search for people with the skills you require might not be just an immediate need. You might needpersons with a specific set of skills for an upcoming project, a couple of months in the future. Youmight spend a couple of weeks searching for the right persons, and maybe visit a couple of conferencesto search for candidates.

Because the search for information might run over a long period of time, it is important that thetechnology utilised will be carried with its owners most of the time. It is also important that thetechnology can search and discover any place where people gather without the need of a centralisedcontrol unit.

When investigating technology for this project we have a set of attributes that we feel are important.The attributes we will emphasise are the following:

Spread: It is important that the technology we look at has a wide spread amongst common peopleor a potential for becoming widespread in the near future.

Transparency: We will be interested in examining technology that is fairly transparent to the user.With transparency we mean that it will be unnecessary for the users to acquire completely newskills to operate the technology. We want them to be able to install the application, get it upand running as fast as possible and also be familiar with the user interface and device.

Mobility: We want the facilitating platform to be mobile and something the users carry with themin most every-day situations. This is to enhance the number of possible user scenarios.

Non-centralised network: We want users that have the same locality to communicate with eachother. It is essential that they do not rely on a central communications infrastructure that mightbe unavailable at several locations.

Our motivation for this project leads us to investigate examine mobile technologies for use in sponta-neous and informal collaboration.

1.2 Problem definition

As we have mentioned in our motivation (Section 1.1), the Proem project by Kortuem et al. [9] showedthat profile-based cooperation can be used to support spontaneous, informal communication betweenmobile users. This was accomplished trough custom built devices that were carried around by theuser as extra gadgets.

11

Introduction

Can small, commercially available, mobile devices be used as tools for supporting spontaneous collabo-ration? Our main focus throughout this report will be to find technologies for this use, and investigateif it is suitable as tools for spontaneous collaboration. We will do an extensive study of the featuresof these technologies, and test their main characteristics by creating a small prototype. By doing thiswe are hoping to gain some real life experience with the technologies, and find the answers that aremissing in the literature.

When researching and testing the technologies we will take a closer look at how it performs in a mobileenvironment. Characteristics like connection time, transfer rates and range will be important to thefinal user experience.

This report will make a good foundation for future work, and hopefully a Master thesis during thespring of 2004. Future work might result in a extensive working prototype of a Proem type system.

1.3 Context

This project is written for the Software Engineering Group at NTNU. They have many projectsand interests, and this report has been written for the MOWAHS [32] project. MOWAHS is shortfor MObile Work Across Heterogeneous Systems and it focuses on collaboration technology for thedistributed workplace.

The MOWAHS goals are as following:

• Helping to understand and to continuously assess and improve work processes in virtual organ-isations.

• Providing a flexible, common work environment to execute and share real work processes andtheir artifacts, applicable on a variety of electronic devices (from big servers to small PDAs).

• Disseminating the results to colleagues, students, companies, and the community at large.

The MOWAHS project has two sub-projects that are both working to fulfil these goals:

• Process support for mobile users using heterogeneous devices.

• Cooperating transactions support, and distributed workspaces.

The area of cooperating transactions is focusing on how to maintain valid transactions over fragilecommunications links. When a user is on the move he may start a transaction which gets broken, orhe might even start a transaction while offline. This must be committed when the user comes backonline, and one must ensure that no information is lost.

Our focus will be within the other area; process support. We will explore technology for supportingmobile collaboration, while leaving the transaction aspects for later exploration.

1.4 Readers guide

In this section we will give a short overview to guide you through the rest of the paper. It might giveyou a better understanding of which parts you consider interesting and important, and let you skimthrough the parts with information not needed or previously known for your reading.

12

1.4 Readers guide

We will also try to divide the readers into two general and sometimes overlapping groups and indicatewhich parts will be relevant for each of these groups.

The non-technical reader This is the reader with some interest in mobile devices and their usage.The reader is interested in what the technology enables us to do, and are looking for the ideas to useit in new ways. Technical details are information rarely looked at.

The technical reader This reader is mostly interested in how things are done. This person mightbe interested in reproducing the same application and results on his own devices and maybe evendevelop it further.

1.4.1 The parts

This report is divided into the following parts and chapters:

Part I Prestudy (Readers: All)

Chapter 2 State of the Art - A short description of work already done and what solutionsexists.

Chapter 3 Technology study - A discussion of available technologies for achieving what we setout to do.

Chapter 4 Technology evaluation - Reflections made upon the previous chapter and weigheddecisions on what technologies to utilise for the remainder of the report.

Chapter 5 Indepth technology study - A detailed study of the chosen technologies.

Part II Development and Testing (Readers: Technical)

Chapter 6 Planning - Description of plans made for implementing our solution.

Chapter 7 Requirements specification and Design - Requirements we are looking to fulfil andhow the implementation will carry them out.

Chapter 8 Implementation and testing - Description of the implementation and testing envi-ronments.

Part III Results and evaluation (Readers: see chapters)

Chapter 9 Test Results and Evaluation - The results from our testing and the conclusions tobe made from it. (Readers: All)

Chapter 10 Problems and Solutions - Problems encountered during our project and possiblesolutions. (Readers: Technical)

Part IV Conclusion and Further Work (Readers: All)

Chapter 11 Conclusion - A summary of our findings.

Chapter 12 Further Work - A description of further work that can be done on challenges foundin this report.

Appendix Contains detailed material that is described in the rest of the document. (Readers:Technical)

13

Part I

Prestudy

14

In this part of our report we will look at the available technologies for promoting collaboration onmobile devices. We will review several development platforms and the available communication tech-nologies.

While there exists many available solutions for spontaneous collaboration today, they usually requireinvestments in special hardware or cumbersome installation processes. This has limited it’s spreadand adaption in daily use. We will first take a look at these existing solutions, before we move on tofind our own solution.

In this project we aim to find a technological solution that are viable in the consumer and busi-ness market without large initial investments. As mobile penetration in Norway is as much as 84,4percent [30, p. 17], we will be especially interested in investigating technologies that can be easilydeployed on most mobile handsets.

We will describe each technology and their characteristics. The work is separated into three categories;mobile devices, development platforms and wireless technologies. The results from the evaluation willfinally enable us to make a choice of technologies for further exploration.

After choosing a technology platform we will conduct an indepth study of the chosen options. Thiswill help us build a foundation for development and testing later on.

15

Chapter 2

State of the Art

There has been done work on Computer Supported Cooperative Work (CSCW) since the early 70’s.There are many fields within CSCW, and much of the early works have focused on collaborative workon Personal Computers trough medias such as groupware, discussion board, shared workspaces andso on. Lately, as mobile devices has become a common appliance, work on collaboration with thesedevices, or similar, has picked up. Many of these experiments include large, custom built devices thatthe users will be wearing instead of carrying. In this chapter we will describe a few projects that tosome extent aim to support CSCW with mobile devices. This is done to get an overview of previouswork done in our research field.

2.1 IPAD/Hummingbird

Figure 2.1: The Hummingbird prototype [14]

In the Hummingbird project [14], Holmquist et al., built a mobile device which supports awareness forusers that are in the physical vicinity of each other. Their device, Inter-Personal Awareness Device,or IPAD, is a small, handheld computer with a radio transmitter and receiver (see Figure 2.1). Itlooks to extend the range of awareness provided by our ordinary senses. It is equipped with a smalldisplay, and buttons necessary for toggling sound and switching the device on and off.

16

2.2 Proxy Lady

The communication strategy of the Hummingbird is to continuously broadcast its identification code.When two devices belonging to the same group are within range of each other they will start to hum,hence the name Hummingbird. The users are thus alerted that someone with a hummingbird is closeto them. The name of the detected Hummingbird is then showed on the display. No other serviceswere offered by the Hummingbird. This device is a highly specialised device that were custom builtand small enough for the users to attach to the body. The Hummingbird has a maximum range of100 meters

After real life experiments they discovered that people did not find the Hummingbird as useful infamiliar settings as in unfamiliar settings. In an office space it is much easier to keep oriented thanin, let’s say, a large concert arena. When in unfamiliar settings, users started looking for each otherwhen notified of user presence by the Hummingbird. The test also revealed that the users experienceda certain feeling of relief when entering unfamiliar settings (such as a convention), and noticing thatsomeone known to them were present.

As the device doesn’t provide any guarantees of others presence, it cannot be used as a reliablepresence information device. For instance, if a Hummingbird is switched off or the battery has runout of power, it would appear as it is not nearby, even though it might be. The user has no way ofknowing this. But this is not the focus of the Hummingbird either. It is merely meant as a catalystfor initiating communication. The developers of the Hummingbird believe that informal face-to-facecommunication is still a very important aspect of collaboration. Their idea is that through increasedpresence awareness, people will engage in more face-to-face communication.

2.2 Proxy Lady

Figure 2.2: Proxy Lady, A PDA equipped with a radio transceiver [29]

Proxy Lady [29], Dahlberg et al., is a mobile system for enabling informal, opportunistic, face-to-facecommunication, running on a PDA equipped with a radio transceiver (see Figure 2.2). The ProxyLady project has particular opportunistic interaction. Opportunistic interaction is anticipated byone party, but it only occurs when the parties happen to meet each other. This could for examplebe when two work colleagues meeting in the hallway and one of them has a question for the other.According to research done during the project, opportunistic communication is an important type ofcommunication that has not been supported previously.

17

State of the Art

Proxy Lady works by having the users select different people as “candidates for interaction”. Thesecandidates are specified by associating different people with an “information item”. This item can bean email or a specific task. Whenever a candidate is within range, Proxy Lady will notify the userand thereby making informal communication possible.

A field study of Proxy Lady was conducted with three different user groups. All users recognisedthat the task domain was important. Most users were positive towards the system and thought itwould help them doing their work more effectively. Some concerns where raised about this being “yetanother interrupting device” and the ability for privacy. On the other hand the device was seen as a“soft” disruption compared to e.g. mobile phone, and the device also supported an “invisible” modefor users that did not want to be seen by the others.

2.3 Proem

Figure 2.3: Proem wearable computer [9]

Proem [9] is a wearable system for profile-based cooperation that enables users to publish and exchangepersonal profile information during physical encounters. Th idea behind this is to help informalcommunications for people that have never met before and do not know each other. Proem is basedon four fundamental concepts:

User Profile: a collection of personal data stored on a mobile device that describes the user

Encounter: a situation of physical proximity of two or more individuals

Profile Exchange: the transmission of personal data between two or more mobile devices duringan encounter

Rules of Encounter: predefined behaviours that are triggered as side effect of a profile exchange

A profile is a description of an individual. This can include their taste in music, what school theyattended, what kind of research field that they are interested in or how old they are. All this informa-tion is set up with the intention to share it with other people. This profile is then stored on a Proemdevice. This device is capable of wireless transmission and is small enough to be carried around.

18

2.4 The Thinking Tag

During the Proem project they built a prototype with parts from a laptop computer (Figure 2.3),but it could also be implemented in a device like a mobile phone or PDA with support for wirelesstransmission.

When two Proem devices comes within range of each other they will exchange their profile. On eachdevice you have a set of rules that the device will check each incoming profile against. If one or moreof these rules is matched against the profile, the device will notify the user.

2.4 The Thinking Tag

Massachusetts Institute of Technology [22] has had a research project called Thinking Tags [23]. Thisproject aimed at developing name tags that where more than just regular name tags. We will explainwhat they do through an example. During a convention to celebrate MIT Media Lab’s tenth birthdaythey had an experiment with these tags. All visitors were given a name tag. The attendants answeredfive questions with three alternatives each and programmed the answers into the tags. The questionswere both about technological and personal issues. Examples are “How would you like to spend your15 minutes of fame?”, “ what is your biggest fear about the future of the Internet?”. This informationwas then used when two persons met each other. The answers were exchanged and light diodes onthe tags showed green for a question they agreed on, and red for questions they disagreed on.

These tags serve as a mean to support social processes, both in formal and informal contexts. Thedesigners argue that personalised tags are focusing on a new aspect of computational badges. Othercomputational badges are generally used to interface humans to machines, such as positioning systemsinside buildings, which aim for things like automatic call forwarding and door opening. Thinking Tag,however, is a digital assistant for face-to-face information presentation of the other party. Hence, itaims more for CSCW than common computational badges.

The developers claim the Thinking Tag is useful both for new encounters and familiar people. Theybelieve it could serve as an icebreaker between strangers, and a source of entertainment for alreadyacquainted people.

The difference between useful, usability and used was something the developers strongly considered.To reach the goal for the Thinking Tag to actually being used, it had to meet several non-functionalrequirements. To avoid “installation” becoming to big an effort, they gathered it had to be easilyprogrammed with name and the multiple choice answers. It also had to be relatively light, as uncom-fortable tags would not be worn, and it had to be attached in a way that would not damage delicateclothing. The first problem was solved by ”dunking” the tags into buckets that corresponded to theselected multiple-choice answers. It was predicted that not only was this solution easy and swift, butit would make people stand around the buckets discussing the different questions. Hence, the pro-gramming part of the process would be a social event itself. The second problem, about weight andsize, was solved by using medium sized watch batteries and as light electronic equipment as possible.However, it was still noticeably heavier than traditional name tags, so they chose to equip the tagswith a rubber cord, making it possible to wear the tags around the neck.

19

Chapter 3

Technology study

In this part we will describe the relevant technologies. Each technology will be described in brief, andrated according to some attributes we find important for this project. This will in the end supportour choice for technology and set the direction for the rest of the project.

When describing the technologies we will be looking for certain attributes as we drafted in the moti-vation for our project (see 1.1):

Spread: It is important that the technology we look at has a wide spread amongst common peopleor a potential for becoming widespread in the near future.

Transparency: We will be interested in examining technology that is fairly transparent to the user.With transparency we mean that it will be unnecessary for the users to acquire completely newskills to operate the technology. We want them to be able to install the application, get it upand running as fast as possible and also be familiar with the user interface and device.

Mobility: We want the facilitating platform to be mobile and something the users carry with themin most every-day situations. This is to enhance the number of possible user scenarios.

Non-centralised network: We want users that have the same locality to communicate with eachother. It is essential that they do not rely on a central communications infrastructure that mightbe unavailable at several locations.

The following table, Table 3.1 will be used for grading the technologies according to the informationfound during our research. We have determined the weight on each attribute based on what we findmost important for our project.

Criteria Weight Grade CommentsSpread 4Transparency 3Mobility 5Non-centralised 4

Table 3.1: Attribute table for evaluation of technologies

The table has two numerical values weight and grade. Weight is set according to how important thecriteria is considered for our further development. It is a numerical value between 0 and 5.

20

3.1 Devices

0: No relevance

1: Lowest importance

2: Low importance

3: Medium importance

4: High importance

5: Highest importance

Grade is the specific grade for the given technology, that tells us how well it meets our criteria. It isa numerical value between 0 and 5:

0: Not suited

1: Lowest

2: Low

3: Medium

4: High

5: Very high

3.1 Devices

As stated in Section 1.1 we wish to look at technology that can be used by large numbers of participantswithout investments in new hardware and extensive training in how to use them. In this chapter wewill look at some relevant hardware devices for supporting spontaneous collaboration.

3.1.1 Mobile Phone

Figure 3.1: Nokia 6600

21

Technology study

The mobile phone, as seen in Figure 3.1, enables it’s users to receive phone calls and be availableanywhere. This is the phones main purpose, but over time a multitude of extra services have beenadded. These include text messaging, contact management and calendars. But the main “killer app”and the reason people buy mobile phones is till voice-calling.

Mobile penetration in Norway is above 80 percent [30], and recent news articles has reported thatevery adult person in Norway owns a mobile phone. For many it is an essential utility throughouttheir day, and they carry it around with them all the time.

A traditional mobile phone is centred around voice and text message services, and the user has hadlittle or no options for extending its applications. It has been impossible for others than the handsetmanufacturer of the phone to install or upgrade software, but recent development has indicated thatthe manufacturers welcome third party software vendors to produce software for their models. Thisenables the user to download programs to their mobiles without the interaction of the manufacturers.

Characteristics of a mobile phone is:

• Small display (typically max 200x200 pixels)

• Cumbersome input-options

• Limited memory (less than 1MB)

• Small size. Phones are often made to fit in the pocket.

• ”Always on”. The phones are connected to the network most of the time.

In 2002, 11 percent of the handsets shipped supported flavours of Java. This is predicted to increasesteadily and reach 74 percent by 2007 [36]. Not included in these numbers are other platforms thatenable third party applications, which have some market share today. These numbers suggests that inthe next few years, most, if not all handsets, will have capabilities that enables the user to downloadand run third party software.

Table 3.2 shows the mobile phone characteristics.

Criteria Weight Grade CommentsSpread 4 5 High, world wide penetrationTransparency 3 4 Most features are well known to

the users and easy to useMobility 5 5 Low weight and low power con-

sumptionNon-centralised 4 1 Most handsets are geared towards

using the operators network.

Table 3.2: Attribute table for mobile phone

3.1.2 Personal Digital Assistant (PDA)

Definition of PDA given according to Hyperdictionary 1:

1http://www.hyperdictionary.com

22

3.1 Devices

Figure 3.2: Compaq iPAQ HP3630

(PDA) A small hand-held computer typically providing calendar, contacts,and note-taking applications but may include other applications, forexample a web browser and media player. Small keyboards and pen-basedinput systems are most commonly used for user input.

Lately there has been a fine line between many mobile phones and PDAs. Figure 3.2 is an example ofone of best selling PDAs, the Compaq iPAQ. We generally draw the line if the device has telephonecapabilities or not. By having such a rough separation you classify some devices like the Palm TungstenW 2 as mobile phones. The Tungsten W has more in common with most PDAs than mobile phones,but this is one of few exceptions.

Main features describing many PDA devices is:

• Large screen compared with other mobile devices (Typically somewhere around 320x320)

• Expandable memory (additional memory cards can usually be added)

• Limited processing capacity (somewhere below 300MHz)

• Open for 3rd party development

Because the PDA doesn’t have one “killer app”, such as voice calls for mobile phones, the spread islimited. PDAs are often used by companies as personal information managers (calendar, contacts etc)or for specific tasks, such as registering inventory in a warehouse.

The PDA is closer to the PC than mobiles in features, and some programs that run on a PC can easilybe ported to a PDA. Because it’s open to more third party development than a traditional mobilephone, it is also easier to install and upgrade software to the newest version. Most mobile phones onthe other hand is locked in terms of what kind of applications and upgrades can be installed.

Table 3.3 shows the PDA characteristics.

2http://www.palmone.com/us/products/handhelds/tungsten-w

23

Technology study

Criteria Weight Grade CommentsSpread 4 3 Mostly used by a “special interest

group”Transparency 3 3 Many features, some might be

complicatedMobility 5 4 Light and low power consumptionNon-centralised 4 4 Stand-alone and not dependent on

any central network

Table 3.3: Attribute table for PDA

3.2 Development Platforms

In this section we will look at different development platforms for mobile devices. These platformsdifferer in both programming languages and target devices. Our goal is to find the platform that ismost suited for this project.

3.2.1 J2ME

Java 2 Micro Edition[37] (J2ME) is a Java platform developed by Sun Microsystems[21] in 1999. Themain target for J2ME is to meet the market of consumer and embedded products. This includesdevices such as mobile phones, personal digital assistants (PDA), pagers and set-top boxes. At thetime of writing, the full list of devices 3 that comes with J2ME counts 124 different devices.

J2ME is built to be modular. This is achieved by building 3 layers on top of the host operationsystem of the device. These layers are the Java Virtual Machine which is the runtime environmentthat enables the device to run Java applications. Next is the Configuration. The configuration definesthe minimum set of Java features and classes that needs to be available for this configuration. Thelast layer it the Profile. This layer defines the minimum Application Programming Interface (API)available on a particular family of devices. To clarify this you can think of the profile as somethingthat makes use of a subset of the classes within a configuration. That way a profile might work onseveral configuration as long as the classes the profile needs is present.

For deploying applications, J2ME utilises a concept called over-the-air user-initiated provisioning[8],OAP. This feature allows for downloading applications over a wireless network on demand, therebyeasing the deployment process for both developers and end users.

Main features for J2ME platform is:

• Built for hardware limited devices

• Easy deployment with over-the-air provisioning

• Highly customisable trough the modular structure

• Sandbox security. The applications can not interfere with other applications or part of theoperating system.

Table 3.4 shows the J2ME characteristics.

3http://wireless.java.sun.com/device/

24

http://wireless.java.sun.com/device/


Criteria Weight Grade CommentsSpread 4 3 Increasing marked shareTransparency 3 4 Little configuration neededMobility 5 5 Designed for small devicesNon-centralised 4 4 Easy deployment with OAP

Table 3.4: Attribute table for J2ME

3.2.2 Mophun

Mophun[24] is a games platform created by Synergenix[40] for mobile devices. It is implemented asa separate runtime environment and executes in a secure sandbox on the mobile device. Synergenixis implementing the runtime on several different platforms, and both Sony Ericsson and Nokia hasannounced support for their handsets.

Because Mophun is a platform aimed at games development it is geared towards performance andgetting the most out of the already limited mobile devices. It is small in size and support C, C++and assembler for creating games.

Key aspects of the Mophun platform is [41]:

• Specially designed for games development

• Small footprint (10k)

• Available from several mobile device manufacturers

• Central certification and signing of mobile games before they can be deployed to mobile terminals

• Open and flexible licensing schemes

Because of the central signing of applications by Mophun, all applications are tested and verified beforedeployment. This can lead to higher quality, but may also make the entire marketplace dependantupon Synergenix.

Table 3.5 shows the Mophun characteristics.

Criteria Weight Grade CommentsSpread 4 1 Limited, becoming available on a

few devicesTransparency 3 4 Integrated and easy to useMobility 5 5 Designed for small devicesNon-centralised 4 3 Applications have to be signed by

Mophun

Table 3.5: Attribute table for Mophun

3.2.3 BREW

BREW 4 is short for Binary Runtime Environment for Wireless and is developed by Qualcomm 5. It isa general purpose platform for mobile devices, and an complete end-to-end solution. It provides mobile

4http://www.qualcomm.com/brew5http://www.qualcomm.com

25

Technology study

carriers a way to distribute applications securely, as well as mobile users an easy way to downloadapplications.

It is by many considered the main competitor for J2ME (see Section 3.2.1), and provides many featuressimilar to it. BREW is based on C/C++, and should therefore enable existing C/C++ programmersto get started easily.

Key aspects of the BREW platform is:

• Small footprint

• Secure distribution

• Enables creation of virtual machines etc. IBM has an available J2ME runtime for BREW [33].

• A complete revenue scheme.

BREW is only available for CDMA based wireless devices that runs on the Qualcomm processor [43].Since very few operators in Europe use CDMA, there are also very little spread of BREW enabledhandsets.

Table 3.6 shows the BREW characteristics.

Criteria Weight Grade CommentsSpread 4 1 Small market share outside North

America and some regions in AsiaTransparency 3 4 Integrated and easy to useMobility 4 5 Designed for small devicesNon-centralised 4 3 Deployed applications needs to be

signed by Qualcomm

Table 3.6: Attribute table for BREW

3.2.4 Symbian

Symbian6 is a operating system designed especially for mobile devices. Common for all these devicesis that they have a wireless network connection, but not necessarily connected at all times.

Symbian is owned by several of the largest mobile phone manufacturerers, Ericsson, Nokia, Panasonic,Samsung, Siemens and Sony Ericsson. By cooperating to build a common base platform with advancedfeatures they can concentrate on developing the top levels that differentiate them.

Key aspects of the Symbian platform[39]:

• Especially made for mobile devices, ranging from normal mobile phones, to PDAs with integratedphone capabilities.

• Targets consumer mass-market

• Made for open third-party development

• Created to run on low resource devices.6http://www.symbian.com

26


• High reliability with advanced features.

• Widely deployed

• Owned by Symbian, and thus dependent on their existence and goals.

Symbian is rapidly becoming the OS of choice for many handset- manufacturers. By developing forSymbian you get access to many users, but it locks you out from the manufacturers that does not useSymbian. If you want to create applications for all manufacturers you will have to code for separateAPIs and maybe even different programming languages.

Table 3.7 shows the Symbian characteristics.

Criteria Weight Grade CommentsSpread 4 3 Available on several high-end de-

vicesTransparency 3 4 Common and known to many

users through its spread.Mobility 5 5 Designed for small devicesNon-centralised 4 3 Many features base on the tele-

phone network

Table 3.7: Attribute table for Symbian

3.2.5 Microsoft Smartphone

Smartphone [20] is based on Microsoft’s [17] operating system Windows CE [19] and is their solutionfor mobile phones. There is also a Pocket PC [16] version available for PDAs, but we will focus onthe Smartphone in this section.

Microsoft has created an operating system for mobile phones that, at least for now, remains in theadvanced segment of mobile phones. It has easy integration with the Windows operating system, anda look and feel that should be familiar to most existing Windows users.

The platform supports C/C++ and the .NET framework [15] (The .NET framework supports amultitude of programming languages). It should be easy to get started with for most programmersused to C/C++ coding. Third party software can be deployed, but current models require theapplications to be signed by Microsoft to be installed.

Key aspects of the Microsoft Smartphone platform is:

• Familiar environment for existing Windows users

• Flexibility for development of third party development through the .NET framework

• The system comes with some important applications pre installed. (calendar, mail etc.)

• Extensive multimedia capabilities and compatibility with Windows Media files

There is currently only two devices running on the SmartPhone platform [18] and only one of themis available in Europe. This is Microsoft’s first attempt at the mobile phone market, and many havedoubts about if they will succeed in taking a significant share. This makes the Smartphone too muchof an uncertain choice in mobile phone platforms.

Table 3.8 shows the SmartPhone characteristics.

27

Technology study

Criteria Weight Grade CommentsSpread 4 1 Only two devices availableTransparency 3 4 Easy to use operating systemMobility 5 4 Only in high end larger devicesNon-centralised 4 3 Relies on centralised Microsoft

technologies like Passport

Table 3.8: Attribute table for SmartPhone

3.2.6 Palm OS

Palm OS is created by Palmsource [13] which is a part of Palm Incorporated [12]. It was initiallycreated for Palm PDAs, but has later expanded to other handheld devices and advanced mobilephones, and also PDAs from other makers.

It is a lightweight system originally designed for PDAs. The devices it runs on is typically smallerand has slower hardware than Pocket PC [16] systems. Traditionally there has also been no supportfor multimedia.

Development for Palm OS is usually done with a C++ compiler and should thus be pretty familiarfor most developers. You can also get Java runtime implementations for cross- platform developmentof applications.

Key aspects of the Palm OS is:

• Simple user interface.

• Operates efficiently on low resource devices.

• Large base of third party applications.

Some critics says Palm OS is too simple and will be replaced by Microsoft’s Pocket PC operatingsystem. Palm though has a large installment base and has sold 30 million devices worldwide 7. Witha good range of available applications Palm isn’t likely to vanish over the night.

Table 3.9 shows the Palm OS characteristics.

Criteria Weight Grade CommentsSpread 4 2 Available mostly on PDAs.Transparency 3 3 Known to mostly PDA users.Mobility 5 3 An extra device that the user

might leave behind.Non-centralised 4 2 Usually doesn’t have wireless com-

munication, and needs wires toconnect either to a PC or to a mo-bile phone.

Table 3.9: Attribute table for Palm OS

7http://www.palmsource.com/press/2003/092203_30million.html

28

http://www.palmsource.com/press/2003/092203_30million.html

3.3 Wireless Technologies


Wireless communication between small, portable devices is a fairly new technology and is either inthe form for light beams or radio signals with large differences in both bandwidth and range. Infraredtechnology is the common way to conduct short range wireless communications and makes use of light.Bluetooth and WLAN on the other hand uses radio signals.

In Table 3.10 we give a short comparison of the technologies we are going to evaluate. In the followingsections we will explore them in greater depth.

IR WLAN BluetoothConnection type Infrared, narrow beam,

line of sightSpread spectrum,spherical

Spread spectrum,spherical

Spectrum Optical 850-900 nm RF 2.4 GHz (5 GHz for802.11a)

RF 2.4 GHz

Range 1m 100m 10-100mMaximum bandwidth 4 Mbps 54 Mbps 1.1 MbpsPower consumption low, 40-500 mW high, 100 mW low to medium, 10 - 100

mWTransmission circum-ference

30 ◦ cone Omni directional Omni directional

Supported devices 2 Connects through anaccess point

8 active and 255 passive

Addressing 32-bit physical ID 48-bit MAC 48-bit MAC

Table 3.10: Comparison of wireless technologies

3.3.1 Infrared

In 1993 the Infrared Data Association[3], IrDA, was formed to develop a standard for wireless datatransmissions using infrared devices. Today the list of members8 includes almost 100 different com-panies within the hardware and software community.

IrDA devices communicate by using infrared light-emitting diodes, LEDs, and photo diodes. Twodevices needs to be pointed directly at each other and be no more than 1 meter apart for full trans-mission effect. The LEDs will then be used to send data and the photo diode at the opposite side willreceive the light emitted and interpret the data. At optimal conditions an infrared connection willsupply a bandwidth of 4 Mbps.

Table 3.11 shows the IR characteristics.

Criteria Weight Grade CommentsSpread 4 4 Integrated into many mobile de-

vicesTransparency 3 4 Little or no setup needed to useMobility 5 4 Small hardware size and low power

consumptionNon-centralised 4 0 Point-to-point, only two devices

can be connected simultaneously

Table 3.11: Attribute table for IR8http://www.irda.org/members/members.asp

29

http://www.irda.org/members/members.asp

Technology study

3.3.2 Wireless LAN

Wireless Local Area Network, or WLAN, is a set of standards developed by the organisation Instituteof Electrical and Electronics Engineers, IEEE[10]. In essence a WLAN is any wireless medium that isable to connect users to a local area network, but the most widespread standard is IEEE 802.11[11]that the IEEE released in 1997. 802.11 today includes three standards, 802.11a, 802.11b and 802.11g,each with a difference in bandwidth and frequency. They also have varying security mechanisms.

802.11a operates in the 5.4 GHz band and a bandwidth of up to 54 Mbps- 802.11b makes use of the2.4 GHz band and has 11 Mbps as maximum bandwidth. Due to the difference in frequency, 802.11aand 802.11b are not compatible with each other. 802.11g on the other hand operates on the samefrequency as 802.11b and is therefore compatible.

WLAN is mainly intended for medium and large devices such as desktop and laptop computers. Thisis partly because WLAN has a relatively large power consumption when transmitting. There alsoexists some PDAs with WLAN support. Examples are the Compaq iPAQ and the Palm C.

Table 3.12 shows the WLAN characteristics.

Criteria Weight Grade CommentsSpread 4 2 Used on a few specialised devicesTransparency 3 3 Some configuration neededMobility 5 3 Small hardware size, but high

power consumptionNon-centralised 4 3 Support for ad-hoc networks,

but no built-in support for de-vice/service discovery

Table 3.12: Attribute table for WLAN

3.3.3 Bluetooth

Bluetooth, originally named after the Danish king Harald Blatand, is a wireless technology introducedby Ericsson [2] in 1994. Today the Bluetooth standards is governed by the Bluetooth Special InterestGroup [1]. This group consists of major companies like Ericsson, Nokia, Microsoft, Intel and hundredsof associated members, which are all responsible for development and promotion of Bluetooth.

Technically Bluetooth makes use of radio waves in the range 2.4 - 2.483 GHz for transmitting data.It is designed to replace traditional serial cables between electrical equipment. Two devices is notdependent on any third party unit to be able to interconnect. To find other devices a Bluetooth unitis able to do a device-discovery which will find any device within range. Each device can offer one ormore services. When a device has discovered other units it can do a service discovery to find possibleservices it can utilise. Both device- and service-discovery is defined in the Bluetooth standard, therebyall (standardised) Bluetooth devices will be made to support these protocols.

Bluetooth devices can be made to support point-to-point and/or multi point connections. For example,a mobile phone hands-free set has no need to see other devices than the mobile phone to which itis connected. While a mobile phone on the other hand might want to connect to both the hands-free set and a laptop computer. A device that supports multi point is able to communicate with 7active devices, and be connected to 255 inactive devices. When devices are inactive they maintain aconnection but does not communicate.

One of the main selling points for the Bluetooth technology is that it is standardised, power con-

30


sumption is low and that the chips are relatively inexpensive. Compared to technologies like WLANwhich costs a lot more, Bluetooth is cheap to implement. These margins are extremely important tomobile device manufacturers that produces thousands of devices every week. According to numbersfrom ZelosGroup [44] 90 percent of PDAs, 80 percent of laptop computers and 75 percent of mobilephone will be shipped with Bluetooth in 2006.

Bluetooth hardware devices are divided into three power classes which determines the device range.

• Class 1: 100 m maximum range



Most portable devices belongs in class 3, while most class 1 devices are stationary due to the powerconsumption for the class 1 hardware.

Bluetooth is a good cable-replacement that is implemented in many mobile devices. It has been abuzzword for a while now, but we are beginning to see widespread use in everything from handsfreesets to synchronisation between devices. We are even seeing the use of Bluetooth for connecting gamesin the Nokia N-GAGE 9.

Table 3.13 shows the Bluetooth characteristics.

Criteria Weight Grade CommentsSpread 4 3 Usually integrated on high-end de-

vicesTransparency 3 3 Some configuration neededMobility 5 4 Small hardware size and low power

consumptionNon-centralised 4 5 Supports ad-hoc networks, built-in

support for device/service discov-ery

Table 3.13: Attribute table for Bluetooth

9http://www.n-gage.com/

31

Chapter 4

Technology evaluation

In the previous chapter we took a look at the possible technologies for our project and their char-acteristics. The purpose of our research is to select a suitable platform for exploring mobile devicesand spontaneous collaboration. In the following chapter we will do just that; based on the motivationgiven for this project (see Section 1.1), evaluate and select a technology platform.

The tables in this section are based on the evaluation of each attribute for the technologies in theprevious chapter (Chapter 5). These numbers are added up to form a basis for our evaluation.

4.1 Devices

In the range of commercially available mobile devices there aren’t really many categories to selectfrom. We have compared mobile phones and PDAs with respect to the attributes we require. Deviceslike laptops and tablet PC’s are of course not an option since most people rarely use devices like that.

Device Spread Transparency Mobility Non-centralised

Total Score

Mobile phone 20 12 25 4 61PDA 12 9 20 16 57

Table 4.1: Device comparison

As we can see in Table 4.1 mobile phones comes out a little bit ahead of the PDA. This is mainlybecause of the large spread of mobile phones. Strictly technologically speaking PDAs are usuallysuperior to mobile phones, but some of the top range phones is starting to rival PDAs.

4.2 Development platform

When considering mobile devices you are bound by the devices limited resources. Running somethingthat comes close to standard PC desktop operating systems is not an option. We were surprised tosee how many options there was for developing applications for mobile devices, and how few thereare for PDAs. This is probably because of the maturity of the PDA-market. The market for PDAsoftware has had time to standardise around a few technologies, while the mobile phone market are

32

4.3 Wireless technology

in it’s early years with myriads of products. The market for mobile phones will probably mature inthe same way during the next couple of years.


Total Score

J2ME 12 12 25 16 65Mophun 4 12 25 12 53Brew 4 12 25 12 53Symbian 12 12 25 12 61Smartphone 4 12 20 12 48Palm OS 8 9 15 8 40

Table 4.2: Development platforms comparison

As we see In Table 4.2 J2ME comes out as the winner slightly ahead of Symbian. Again the spreadof these platforms are important. Symbian is used by many mobile phone manufacturers as theiroperating system, and J2ME is used by even more as an application platform. Luckily it seems theindustry is consolidating it’s focus around one common platform, J2ME.

4.3 Wireless technology

There aren’t really many wireless non-centralised technologies around that are standardised and avail-able to the public. Most devices has used cables previously, whether it was for synchronisation orfor network access. Interoperability is growing as a concern for many users and they are looking fordevices with standardised wireless interfaces.


Total Score

IR 16 12 20 0 48WLAN 8 9 15 12 44Bluetooth 12 9 20 20 61

Table 4.3: Choice of wireless technologies

As seen in Table 4.3, Bluetooth comes out as the winner. It’s spread is increasing rapidly, and it isusually integrated with the host system in an uncomplicated way. Much like IR actually, but IR lacksmuch in multiple-connections and range.

4.4 Conclusion

When judging the different technologies with the attributes we have drafted we get three winners.For our project the most suitable combination of mobile device, development platform and wirelesstechnology is:

• Mobile Phone

• J2ME

33

Technology evaluation

• Bluetooth

The only really well known and widely used technology of these are mobile phones. It is a very broaddefinition of a technology, and J2ME and Bluetooth will usually be viewed as something included inmobile phones. That does not change the fact that for every time the user hears a new name of atechnology and is told to use it, it requires him to conceptualise it in his head. Our hope is that inthe near future even J2ME (or Java as marketing calls it) and Bluetooth will be concepts familiar tothe common user, and will be no barrier to start using an application.

As mobile phones is a device that is usually carried around with it’s owner all the time, we view thisas a great tool for supporting spontaneous collaboration. It is not “yet another gadget” you need toremember, and the spread of mobile phones with J2ME and Bluetooth will expand in the future. Themain barrier will then be a small software-download, which we hope most people will be used to.

In the following sections we will examine these technologies in greater depth.

34

Chapter 5

Indepth technology study

In the previous chapter we researched some technologies for developing our application. This researchwas only meant to be a overview of the available options, and there are of course many more detailssurrounding these technologies.

After choosing the technologies we wish to use for this project, we will now take a closer look at thetechnical details to impact our project. The general evaluation performed earlier should cover mostaspects concerned with our evaluation attributes (see 1.1), but to continue we need to figure out theinner workings.

We will first take a look at J2ME and then a closer look at Bluetooth.

5.1 Java 2 Micro Edition

As stated earlier in this report [3.2.1], Java 2 Micro Edition is a Java platform developed by SunMicrosystems. At a high level, J2ME is currently targeting two broad categories of products:

• Shared, fixed, connected information devices. Typical exampled of such devices are TV set-top boxes, Internet-enabled screen phones, high-end communicators and automobile entertain-ment/navigation systems. These devices have a wide range of user interface capabilities, memorybudget in the range of 2 to 16 megabytes and persistent, high-bandwidth network connections.

• Personal, mobile, connected information devices. Mobile phones, pagers and personal organ-isers are examples of devices in this category. These devices have very simple user interfaces(compared to desktop computer systems), minimum memory budgets, ranging from about 128kilobytes up to 64 (add new number here before delivery) megabytes, and low bandwidth, un-stable network connections.

The line between these two categories is fuzzy and becomes more so each day. In practice, the linebetween the two categories is defined more by the memory budget, bandwidth, battery and powerconsumption and physical screen size of the device, rather than by its specific functionality or type ofconnectivity.

In this report we will focus mostly on the latter category. Included here you find mobile phones andPDAs.

35


5.1.1 J2ME Building Blocks

J2ME is divided into three layers

Configuration: set of Java classes available for a given device group

Profile: a subset of Java classes that can be found in the given configuration

Virtual machine: Implementation of a configuration for a device

The idea behind this is that J2ME will be running many different categories of devices. For example,consider the following types of consumer devices:

• mobile phones

• washing machines

• video recorder

It seems clear that each of these represent different categories of devices. Implementing a Java frame-work that will support all of these devices and still be useful would be next to impossible. This iswhere the configuration comes in. A configuration defines the Java language, virtual machine fea-tures and minimum class libraries that a device manufacturer can expect to be available on a devicesbelonging to the same group. These devices share the same or similar requirements, memory and pro-cessing capabilities. On top of the configuration you will find the profile. The main goal of a profileis to guarantee interoperability within a certain device family or domain by defining a standard Javaplatform for the market. Profiles typically include class libraries that are far more domain-specificthan the class libraries included in a configuration.

To understand in further detail you can think of the configuration as a horizontal section that definesa set of classes. A profile on the other hand is a vertical section which will use a subset of the classesdefined in the configuration. The virtual machine is at the bottom and represents an implementationof the classes in the configuration. See Figure 5.1 for illustration.

Figure 5.1: J2ME Layers

36

5.1 Java 2 Micro Edition

5.1.2 Configuration and virtual machine

Figure 5.2: Inherited classes in J2ME

A configuration defines a Java platform for a “horizontal” category, or grouping, of devices withsimilar requirements on total memory budget and other hardware capabilities. More specifically, aconfiguration:

• specifies the Java virtual machine

• specifies the Java programming language features supported

• specifies the basic Java libraries and APIs supported

As we mentioned in the introduction for this section, J2ME is targeting two consumer categories;shared, fixed, connected information devices and personal, mobile, connected information devices.For this reason we have two configurations specified for J2ME today, Connected Limited DeviceConfiguration, or CLDC, and Connected Device Configuration, CDC. This is the typical char-acteristics of devices which can use CDC or CLDC:

CDC:

• 512 kilobytes (minimum) memory for running Java• 256 kilobytes (minimum) for runtime memory allocation• Network connectivity, possibly persistent and high bandwidth

CLDC:

• 128 kilobytes memory for running Java• 32 kilobytes memory for runtime memory allocation• Restricted user interface• Low power, typically battery powered• Network connectivity, typically wireless, with low bandwidth and intermittent access

As this list shows, CLDC is intended for more limited devices, such as mobile phones and PDAs.CLDC is by far the most used configuration. At the time of writing there are no CDC devices listedin the J2ME device list from Sun 1. It is also the configuration that is most important for our project.

1http://wireless.java.sun.com/device/index.html

37

http://wireless.java.sun.com/device/index.html


As shown in Figure 5.2, the majority of functionality in CDC and CLDC has been inherited fromJ2SE. Each class inherited from J2SE must be precisely the same or a subset of the correspondingclass in Java 2 Standard Edition. In addition, CLDC and CDC introduce a number of features notdrawn from the J2SE, designed specifically to fit the needs of devices with limited recourses. SeeAppendix A for a complete list of classes included in CLDC.

When you have defined a configuration you need a Java virtual machine that implements the propertiesfor that configuration. The virtual machine implementation of CLDC is called KVM, kilo VirtualMachine. It was named so because its memory budget is measured in kilobytes. KVM is suitable for16/32-bit RISC/CISC microprocessors with a total memory budget of no more than a few hundredkilobytes. The minimum total memory budget required by a KVM implementation is about 160kB, including the virtual machine, the minimum Java class libraries defined by CLDC and some heapspace for running Java applications. In the upcoming version 1.1 of CLDC there is implemented a newvirtual machine, CLDC HotSpot [38]. The CLDC HotSpot implementation is a virtual machine thatis highly optimised and provides superior performance compared to KVM. In addition to complyingto the CLDC specification, the CLDC HotSpot implementation includes patented features that propelfaster application execution as well as more efficient resource management. Like KVM, CLDC HotSpotis targeted at small devices.

5.1.3 Profiles

The topmost layer in J2ME is called Profiles and is placed on top of the configuration. In J2ME, anapplication is written “for” a particular profile, and a profile is “based upon” or “extends” a particularconfiguration. Thus, all of the features of a configuration are automatically included in the profileand may be used by applications written for that profile.

At the implementation level, a profile is defined simply as a collection of Java APIs and class librariesthat reside in top of a specified configuration and that provide the additional domain-specific capa-bilities for devices in a specific market segment. All the APIs offered by a profile is an extension ofthe configuration classes.

Today there is only one profile for CLDC, Mobile Information Device Profile, or MIDP. MIDP providesthe core application functionality required by mobile applications. Included here are specialised classesfor the user interface, network connectivity, local data storage, and application life cycle management.

5.1.4 J2ME and Bluetooth

Bluetooth with Java is accomplished with the API Java Specification Requests-82 [31], or JSR-82.JSR-82 is the first open, non-proprietary standard for developing Bluetooth applications using Java.It is not a default part of J2ME, but an optional API for J2ME devices. The Java APIs for Bluetoothtarget devices with the following characteristics:

• 512K minimum of total memory available (ROM and RAM) (application memory requirementsare additional)

• Bluetooth wireless network connection

• Compliant implementation of the J2ME CLDC

The JSR-82 API is intended to provide the following capabilities:

• Register services

38

5.2 Bluetooth

• Discover devices and services

• Establish RFCOMM, L2CAP, and OBject EXchange protocol (OBEX) connections betweendevices

• Using those connections, send and receive data (voice communication not supported)

• Manage and control the communication connections

• Provide security for these activities

5.2 Bluetooth

We have found Bluetooth to be the most suitable technology for our project, and we will thereforetake a closer look at the technology; its benefits and limitations in the following sections.

Figure 5.3: Example Bluetooth device: Motorola handsfree for mobile phone

Bluetooth is designed as a short range cable replacement. Key features are robustness, low complexity,low power, and low cost [6]. Traditionally there has been an extra set of cables if you need to connectyour mobile phone to your computer, use a handsfreeset, or transfer images from your digital camera(see Figure 5.3 for example headset). Often this would be special cables that is hard to find in stores,and of course something you left at home just when you needed it. Bluetooth simplifies this by lettingyou connect your devices even if your cellphone is in your bag, and your laptop is on the table.

5.2.1 History

Bluetooth research was started in 1994 by Ericsson. After doing the initial development, Ericssonbrought in several other actors in the technology market to develop the standard further. IBM, Intel,Nokia and Toshiba joined to form the Bluetooth SIG, which is short for Special Interest Group.Bluetooth SIG is the central licensing authority for Bluetooth and handles all the specifications,trademarks and licensing. Several other companies have been affiliated through the years, and theSIG now count over 2000 members [1].

The name Bluetooth is taken from Harold Bluetooth, the Danish viking king that christened theDanes, and conquered Norway to unite it with Denmark. It has been stated that just like Harold

39


Bluetooth united the two countries, Bluetooth technology wish to unite the worlds of telecom andcomputers.

In 1998 the first Bluetooth standard was released. The first releases of the standard had some in-consistencies across different vendors, and was plagued by interoperability issues [4]. The actors hasremained committed to creating a new wireless standard, and the problems has been corrected inlater releases. We are now seeing wide deployment of the technology, especially in mobile phones. 75percent of mobile phones are predicted to implement Bluetooth technology within 2006 [44].

5.2.2 Architecture

The Bluetooth architecture is divided into two parts: the Bluetooth controller and the Bluetooth host.These inter operate to create a complete stack for Bluetooth devices. See Figure 5.4 for illustration.

Applications

Cont rol

RFCOMM SDP

RF

Baseband

Audio

Data

L2CAP

Link manager

HCI

Controller

Host

Figure 5.4: Bluetooth stack

The Bluetooth controller is the actual Bluetooth device. This could be a USB-dongle, PCMCIAcard for a laptop or the Bluetooth chip in mobile phones.

The Bluetooth host is usually implemented in software and integrated with the host operatingsystem. This is where most Bluetooth protocols is implemented.

The controller and the host communicates through the Host Controller Interface (HCI) to make acomplete Bluetooth stack. This separation applies to most devices, but not all. Headsets, for example,does not use HCI to communicate and the whole stack is integrated and implemented in hardware.

5.2.3 Radio

Bluetooth is a radio based technology. This means that it transmits and receives radio-waves on adesignated radio frequency range. Bluetooth operates in the 2.4GHz band, which is the same band ascordless phones and wireless LAN technologies. The band is 83.5MHz wide in most countries, whichleaves room for 79 separate channels. Bluetooth utilises these channels by frequency hopping. Thismeans that connected devices follow the same frequency-hopping sequence, while other connecteddevices in the same area follows another sequence.

40

5.2 Bluetooth

Since Bluetooth is a radio technology it has a limited range. The range depends on its class as definedby the Bluetooth specification [6].

Class RangeClass 1 Maximum range of 100 metersClass 2 Maximum range of 20 metersClass 3 Maximum range of 10 meters

Table 5.1: Bluetooth device classes

As the range of the device increases, so does the power consumption of the Bluetooth controller.Most mobile devices are class 3 because of their limited power supply, while most class 1 devices arestationary devices (Bluetooth Network Access Points etc.) connected to a permanent power supply.

5.2.4 Protocols

Just above the RF, baseband and link manager in the Bluetooth stack (see Figure 5.4), you find thefirst software protocols of Bluetooth. The L2CAP (logical link control and adaption protocol) is abasic protocol that utilises the underlying controller protocols. When programming Bluetooth devicesmost programmers will be programming with the L2CAP protocol or another protocol above thatutilises L2CAP.

The L2CAP protocol is a packet oriented protocol. It has a maximum packet length of 65,536 bytes,while the underlying baseband protocol has a maximum length of 339 bytes. By abstraction this limitis hidden for the user when utilising the L2CAP protocol.

Bluetooth Radio

Baseband

BNEP SDP TCS binary

OBEX

RFCOMM

L2CAP

HCI

Figure 5.5: Example of Bluetooth protocol relationships

Bluetooth specifies many protocols. Example protocols would be RFCOMM and Bluetooth NetworkEncapsulation Protocol (BNEP). These protocols are all hierarchical and one protocol relies on theunderlying protocols. This means you can not have a device that implements one protocol if it does notalso implement the underlying protocols it requires. See Figure 5.5 for an example of this relationship.

What differentiates Bluetooth from many other specifications is that it defines protocols from thehardware up to the application protocols. This means that the specification comes ready for utilisationby devices like handsfree headsets. In comparison; the 802.11b WLAN standard does not defineapplication protocols, but just the hardware layers. On top of that you would normally run TCP/IP,

41


and then the application protocols you would like. This might be FTP for file transfers or SMTP formail.

5.2.5 Profiles

The Bluetooth specification also defines several profiles. A profile specifies the underlying protocolsto use, the parameters of these protocols and the way the applications communicate. Examples ofprofiles would be Audio/Video Remote Control Profile and Cordless Telephony Profile. If two deviceswants to communicate they must implement the same profiles. The profile definition might includepacket sizes, master/slave-relationships and content of the transmissions.

Because the most common uses of Bluetooth technology is defined in the Bluetooth specification,different vendors know how to communicate without having to test their devices together. This isone of the advantages, and something that makes Bluetooth technology stand out from many othertechnologies.

5.2.6 Connecting Bluetooth devices

To communicate between Bluetooth devices you must initiate a connection. If you know the Bluetoothaddress of the device and service you want to connect to, you can issue a connection request. Thedevices will connect if the other device is within range, and it’s security settings allow it. This ofcourse implies that the device you connect to is able to provide the services you seek.

Inquiry

If you do not know the address of the device you wish to connect to, you will have to do an inquiry.An inquiry is when a Bluetooth device broadcasts a signal to all devices asking for their presence. Thedevices responds with it’s own address, if it is available for inquiry. An inquiry should return most,but not all Bluetooth devices that are available for connection and within range. If the inquiry lastsfor 8-10 seconds, it is guaranteed to have discovered 95 percent [7] of the devices within range. Whenyou know which devices is in range you must check to see if they offer the services you are seeking.

Service discovery

When you know which Bluetooth devices are in the area you need to check if they can offer the specificservices you require. If you’re looking to connect your mobile phone with a hands-free set, it will nothelp you much if the only service the devices at your location is providing is printing.

In the Bluetooth specification [6] there are several predefined services. This can be both profiles andprotocols. They are identified by a unique ID which you supply as the parameters for your servicediscovery, see examples in Table 5.2. The Bluetooth devices will then respond if they implement therequired services.

The Bluetooth specification defines many common services that manufacturers of devices should striveto implement. You can however create your own IDs for your own special applications. You are thenlikely to require some low level protocols as L2CAP in addition to your own protocol. When youcheck a Bluetooth device for services you will then specify that you require both these protocols.

42

5.2 Bluetooth

ID Protocol/Profile0x0100 L2CAP0x1116 Network Access Point0x1105 OBEX Object Push Profile

Table 5.2: Example Bluetooth service IDs

Connection

After you have found the required services you can connect to the Bluetooth device to use the service.As Bluetooth was designed as a cable replacement it is possible to connect two devices. But thedesigners of Bluetooth has also included the possibility to connect more devices than just two. Thereare limitations to this, but these are issues we will discuss shortly.

Some definitions:

Master: The Bluetooth device that other devices synchronise their clocks by to figure out the fre-quency hopping sequence. The master is also the device that all the slaves will connect to.

Piconet: Consists of up to 8 connected and active Bluetooth devices that communicate. It maycontain up to 255 inactive devices that does not communicate but remain connected and syn-chronised, in case of future communications. There is only one master in a piconet, all otherdevices are slaves.

Scatternet: A number of interconnected piconets that creates a larger net.

Figure 5.6: Piconet illustrating master and slaves

When two devices connect they are assigned a role. Either master or slave. Up to 8 active devicescan be connected in a piconet. See Figure 5.6 for an example.

When a piconet is created, the frequency hopping sequence is established from the master devicesclock. After this all devices in a piconet will have the same hopping sequence, and thus be able tocommunicate. There is one frequency for each timeslot, and each timeslot lasts for 625 microseconds.The hopping occurs at about 1600 hops per second.

By utilising frequency-hopping Bluetooth avoids problems with background noise from microwave

43


ovens etc. There might be noise to damage the transmission on one frequency, but the likelihood forthe noise being present on all other channels is low.

As mentioned, a piconet consists of maximum 8 active devices. Usually this will be sufficient, butsometimes there will be more devices that wish to interact. By joining several piconets into onescatternet the range of Bluetooth devices can be extended by forming a large net.

Piconet #1

Piconet #2

Master Slave Slave/Master

Figure 5.7: Bluetooth scatternet

A scatternet, as seen in Figure 5.2.6, is formed either when there are too many devices that wishto connect, or when some devices are out of range of the master, but within range of one of theslaves. There is only one master within a piconet, and all other devices is slaves. This is still true forscatternet scenarios, but if a device participates in two piconets it can be both a slave and a master.It then plays the role of a slave in one net, and the master in another net. This is what happens whena scatternet is formed: one of the slaves in the first piconet is also assigned the role as the master ofthe second piconet, this device is then the link between the two piconets.

5.2.7 Security

Bluetooth has basic security like authentication and encryption. None of these will be important toour project. But it has some other security mechanisms that interests us.

PIN code: A four digit pin code can be specified that other devices will have to know to connect tothis device.

User connection acknowledge: The user has to confirm all connections made to this device.

Both these mechanisms must be disabled for a spontaneous exchange to work like intended. It can beargued that this will be desirable from the users point of view, but it will probably make the processof exchanging profiles too cumbersome. It will also hinder the exchange of profiles with people youhaven’t met face to face. It is unlikely that users will acknowledge connections from people they don’tknow.

44

Part II

Development and Testing

45

In the previous part of the report we set out to find technologies and hardware for spontaneouscollaboration. We ended up on a choice of development platform, wireless technology and devices toutilise. In this part of the report we will describe a requirement specification, design, carry out asimple implementation and explore the deeper technical details like APIs, response times, availableresources etc.

46

Chapter 6

Planning

In this chapter we will do some initial planning for our development. This includes choosing a devel-opment environment and looking at the positive and negative sides of our options.

When we started this project we were quite aware that the technologies we were going to investigatewould be new and not well tested. This is especially true for the combination of Java and Bluetooth,and working with ”cutting edge” technology like this isn’t always easy. Problems you often encounterare:

• APIs that are specified but not fully implemented

• Bugs in the software

• Little or no documentation

• Little or no support

With all this in mind we set out to find a development environment that would let us test the featuresthat interests us.

6.1 Test and development environment

The MIDP 2.0 and JSR-82 standard are fairly new (final specification released Nov 2002), and thenumber of devices that support these standards is limited. Sun maintains a list of devices thatsupport the different specifications at http://wireless.java.sun.com/device/. In this list there were atthe beginning of our project only one device that supported MIDP 2.0 and JSR-82; the Nokia 6600.But this was not released to the market yet, and we were unable to retrieve a version of it. Now, atthe time of writing there are 4 phones announced with MIDP 2.0 support, but only two of these areavailable in consumer stores.

Due to the fact that we had to start our research early in the project, we had to research other optionsfor developing our application. These are the options we explored:

Compatible implementationBy obtaining a MIDP 2.0 compatible JVM with Bluetooth support for PDAs we could do implemen-tation as close to our goal as possible.

47

http://wireless.java.sun.com/device/

Planning

Full simulationSoftware simulation of both the MIDP 2.0 phone and Bluetooth stack.

Partial simulationSoftware simulation of the MIDP 2.0 phone and integration with a real Bluetooth stack and use aUSB Bluetooth device on a computer.

Partial implementationConcentrate only on some parts of the complete solution and leave the other parts for later imple-mentation. This is a sort of a last resort solution if we can not find something that ties it all together.

This next section will describe these options and our findings while exploring them.

6.1.1 Compatible implementation

Our advisor had already several iPAQ and Palm devices available so we started out looking for J2MEcompatible JVMs for these. During our research we found several vendors, and even though someof them had MIDP 2.0 support, none of them had JSR-82 support. Some claimed to have JSR-82support scheduled for later, but this would be too late for us.

6.1.2 Full simulation

With the full simulation we were looking to create a complete environment, that simulated the phoneand Bluetooth stack without any need for investments in hardware.

In our search for a solution we came up with several products. Some of these were complete simulationenvironments for both phone and Bluetooth stack, while others were combinations of products to forma complete solution.

The first product we encountered was the Wireless Toolkit from Sun 1. It is a simulator for MIDP 2.0,but at the time did not have the JSR-82 support that we required. This could be coupled with theRococosoft Impronto Bluetooth simulator [34] to form a complete solution. This simulator simulatesthe Bluetooth part of the MIDP 2.0 specification. However, this simulator is an expensive commercialproduct, that we could not afford for this project and was therefore not chosen.

Later we found the Nokia Developer’s Suite for J2ME [25] with support for mobile phone and Bluetoothsimulation. Unfortunately the L2CAP implementation in this Software Development Kit (SDK) wasincomplete, which made it impossible to transfer data between two simulated phones. Some researchshowed that other developers were having the same problems and we therefore cancelled more testingwith this option. However, later in our project Nokia released a new version that resolved some ofthe shortcomings we found. Unfortunately this was too late for us.

6.1.3 Partial simulation

After some research we found the Rococo Impronto Developer Kit for Linux [34]. It is a free imple-mentation of the JSR-82 Bluetooth API for Linux. Our initial idea was to couple this implementationwith the Sun Wireless Toolkit for both JSR-82 and MIDP 2.0 support. This turned out to be impos-sible due to limitations in the WTK from Sun. The WTKs security policy would not allow importingthe JSR-82 implementation.

1http://java.sun.com/products/j2mewtoolkit/index.html

48

6.2 Conclusion and solution for development

6.1.4 Partial implementation

When we realized that it would be difficult to do a MIDP 2.0 and JSR-82 implementation or simu-lation, we decided to focus on the technology we knew least about, and that represented the largestuncertainty factor. We would concentrate out research around JSR-82, and combine it with J2SE. Bydoing this we could still test JSR-82 and examine it’s capabilities, while still creating code that withsome small modifications is applicable to mobile phones at a later stage.

We decided to use the free implementation of JSR-82 for Linux that is developed by Rococo, theImpronto Developer Kit for Linux [34]. Together with hardware like a Bluetooth USB dongle andJ2SE we finally had a solution that enabled us to test Bluetooth in a real-life setting.

This solution also gives some real life experience compared to the options where we only simulateBluetooth. By using devices that utilise real radio waves you can test aspects like speed and times,which would be strictly hypothetical if a simulation environment were used.

6.2 Conclusion and solution for development

After doing research on possible development solutions, we were left with the conclusion that there wasno available hardware that supported MIDP 2.0 and Bluetooth. Software options had to be exploredand we took a closer look at all the options mentioned above.

The only workable solution we could find was a solution (the partial implementation with Bluetooth)where we are unable to test the other aspects of MIDP 2.0 development than the Bluetooth APIs.This was due to limitations in funding and incomplete releases from several vendors, but still enablesus to gain insight into the workings of Bluetooth.

The following chapters in this report will utilise the Rococo software suite to test and explore Blue-tooth.

49

Chapter 7

Requirements specification andDesign

As stated in our motivation (Section 1.1) we are interested in creating a system that would facilitatespontaneous collaboration between users that do not necessarily know each other. Unfortunately, aswe described in the last chapter ( Chapter 6), we have been unable to find a complete developmentplatform with the technologies we selected in our prestudy.

We choose to focus on the fundamentals of Bluetooth for which we have found a development solution.We wish to gain a deeper understanding of it’s inner workings and test how responsive it is.

In this chapter we will outline a requirements specification for a Bluetooth test suite. We will describetechnological requirements, functional and non functional requirements and also a design for our suite.

In this chapter the following terminology will be used:

Device: A Bluetooth enabled device that is either a server or a client

The server: A device which will accept OBEX connections and file transfers

The client: A device that searches for, connects and transfers files to a server.

Device discovery: The process of finding all devices within range (also known as inquiry, see 5.2.6).

Service discovery: The process of finding all services on one known device

Transfer rate: The time is takes to transfer a file of arbitrary size from the client to the server

Range: The distance between the server and the client

7.1 Functional requirements

Our test suite must fulfil the following functional requirements:

50

7.1 Functional requirements

7.1.1 Execution of server

The server will be responsible for accepting connections from a client and complying to the OBEXprotocol.

FR1.1: Register a service

FR1.2: Be available for discovery

FR1.3: Accept connection to the service

FR1.4: Comply to the OBEX protocol

FR1.5: Allow uploading a file from the client

7.1.2 Execution of client

The client will search out a suitable server, connect and upload a file to test the Bluetooth functionality.

FR2.1: Do discovery other Bluetooth devices

FR2.2: Search for services on the the devices it finds

FR2.3: Connect to the server

FR2.4: Transmit a file to the server

FR2.5: Execute multiple times to support test batches

7.1.3 Logging

To let us evaluate the test runs we need some concrete numbers. It is important that the test suiterecords this information during each run to give us precise numbers that we can use for analysis lateron.

NF3.1: The server must record information to file

NF3.1.1: The server must record number of connects

NF3.1.2: The server must record file transfer rates

NF3.2: The client must record information to file

NF3.2.1: The client must record total execution time

NF3.2.2: The client must record individual device discovery time stamps

NF3.2.3: The client must record individual service discovery time stamps

NF3.2.4: The client must record file transfer rates

NF3.3: All logged content must be separated by a ; to enable analysis with tools.

51

Requirements specification and Design

7.2 Non functional requirements

Out test suite must fulfil the following non-functional requirements.

NF1: Utilise a Bluetooth device for connection and transfers

NF2: All use of Bluetooth device must happen through the JSR-82 API

NF3: Run on a J2SE virtual machine

NF4: Run on a Gnu/Linux operating system

In addition to these it might be relevant to specify response times and battery consumption for acomplete application. These are however values that are unknown to us, and we wish to take a closerlook at these through our use of the test suite.

7.3 Design

Our implementation will test some of the very basic concepts of Bluetooth, paying attention to theBluetooth APIs. A plain text interface will suffice and there is no need for user interaction. The testswill consist of some very basic sequential operations, and will not need to be separated into differentclasses. Maintainability is not a concern.

7.3.1 Classes

Figure 7.1 is a class diagram for implementing our test suite. These has been conceived by experi-menting with the JSR-82 APIs.

As you can see in Figure 7.1, the two main classes are the TestClient and TestServer classes. Theyare instantiated by the TestSuite class which is really just an empty class whose sole responsibility isto create and start either the sever or the client, depending on the start argument from the user.

The Configuration and Logging classes are utility classes that are created to reuse common function-ality. The Config class takes care of parsing and storing the test-parameters for the current execution,and the Logging class takes care of the logging. In our case it just makes sure all log entries arewritten to file with “;” separating each column to ease importing into Microsoft Excel.

If you take a closer look at the TestClient class you will see that it implements methods like deviceDiscovered()and inquiryCompleted(). These are methods specified by the javax.bluetooth.DiscoveryListenerinterface, and specifies an listener that is required by the JSR-82 API (documentation available withthe Nokia SDK [25]) to do Bluetooth discovery.

When you start a device search or a service-search from the client, you are required to supply a classthat implements the DiscoveryListener interface and thus is able to handle the events from a deviceand service search.

A closer look at the TestServer class reveals that this class is extending javax.obex.ServerRequestHandlerand implementing methods needed to accept connections and file transfers. Examples are onConnect()and onPut(). These methods are already present in the ServerRequestHandler class, but they arejust simple default implementations that does nothing else than return a OBEX HTTP NOT IMPLEMENTEDresponse code.

52

7.3 Design

Config

TestClient

<<create>> TestClient(config: Config)

runClient() : void

initLocalDevice() : void

startDiscovery() : void

deviceDiscovered() : void

startServiceDiscovery() : void

servicesDiscovered(transaction: int,services: ServiceRecord[]) : void

connect() : void

printServiceInfo() : void

sendFile() : void

serviceSearchCompleted(transID: int,responseCode: int) : void

inquiryCompleted(discoveryType: int) : void

TestServer

<<create>> TestServer(config: Config)

initLocalDevice() : void

initServer() : void

openOBEX() : void

openL2CAP() : void

onConnect() : int

onDisconnect() : void

onAuthenticationFailure(arg0: byte[]) : void

onDelete() : int

onGet() : int

onPut() : int

onSetPath(arg2: boolean,arg3: boolean) : int

TestSuite

Logging

Figure 7.1: Classes designed for the test suite

As you have seen, TestClient implements an interface and TestServer extends a server class. Theinterface implemented by the client are related to the basic discovery protocols of Bluetooth, andpretty much needed for any Bluetooth and JSR-82 application. The class extended by the server isrelated to our use of the high level OBEX protocol, and only used because we have decided to useOBEX.

7.3.2 Program sequence

When utilising the test suite we will perform a sequence that includes discovery for both devices andservices, connection and transferring of a file between client and server. See Figure 7.2 for the fullsequence.

In Figure 7.2 you can see that there are two types of arrows. The ”half” arrows symbolises anasynchronous call that doesn’t block the caller. Full arrows are normal synchronous calls that blockthe caller.

The first thing that happens is that the server must ”register” its service with the Bluetooth API. Bydoing this it says it wishes to offer a service, and that it will handle incoming connection requests.After assigning a unique ID to the service everything is now ready for the client to connect.

The client issues a device discovery. This is a non-blocking call, and the client can continue with othertasks until an event of device discovery is received. This is symbolised with the response from theserver.

When a device is discovered, the client can search services on this device. The client issues a search

53

Requirements specification and Design

TestClient TestSever

Register service

Discovery

Discovery response

Service discovery

Service records

Connect request

Put file

Disconnect

Figure 7.2: Sequence of communication between server and client for testing

specifying the services of interest with a non-blocking request, and the server responds with a non-blocking reply. When the client receives the response an event is generated.

Until this point the server and the client has not shared a common connection or connection state.After the client receives confirmation that the server is able to supply the requested services, the clientcan use the know information to connect. To create a connection a synchronous call is executed andthe client will wait till the connection is initiated or the connection attempt fails.

When a connection is achieved the client can send the file over the connection, and in the end closethe connection when the transfer is completed. By performing this test-sequence several times we willbe able to get numbers for the real life performance of Bluetooth devices.

54

Chapter 8

Implementation and testing

As we stated in the planning chapter (Chapter 6) we wish to implement a “half way” solution wherewe use a JSR-82 implementation from Rococo together with J2SE.

We have created a requirements specification and a general design solution (Section 7.3.2), that makesout the foundation for our implementation.

In our design we lay out a test sequence to be performed, in order to fulfil all the requirements. Bylogging time taken for the different steps in the test sequence we will acquire data that can be usedfor our analysis of Bluetooth performance.

8.1 Implementation

For the implementation of our test suite we use the following software environment:

• Java 2 Standard Edition (J2SE) as main programming environment

• Rococo Impronto Developers Kit for Linux as the JSR-82 implementation and API

These two software solutions each contain it’s own separate API. The extensive API from J2SE shouldbe familiar to most programmers. In addition the Rococo Impronto Developers Kit supplies the APIsnecessary for programming Bluetooth devices. It supplies the javax.bluetooth and javax.obexpackages.

By utilising these two APIs we have been able to create simple programs for testing Bluetooth func-tionality. The following classes has been implemented (see Section 7.1 for the classdiagram) :

TestSuite: Main runtime which is responsible for starting the client and server.

TestServer: Server class that creates a service and accepts OBEX-connections.

TestClient: Client that will scan for a server device and will be able to connect to the server andtransfer a given file.

Logging: Class responsible for writing the log-files.

Config: Configuration class that was responsible for setting various configuration variables.

55


Some of these are utility classes while the TestClient and TestServer classes provide the main executionpaths for the test.

8.1.1 Execution

When executed, the server and client can behave differently each time. The Config class makes sureall parameters are available at runtime. This was implemented to enable us to test different aspectswithout running thorough the full test-sequence every time. In the end though, the results we acquiredwere compiled with a full run. For a full description of the test sequence see Section 7.3.2.

The server was built to create a special service and accept OBEX connections. This is a fairly simpleimplementation and doesn’t require much code. The largest part of the code for implementing theserver is handling file-transfers.

On the other end is the client, that has most responsibilities in our testing. The clients behaviourdepends on configuration variables that we have defined, and can be altered each time the client starts.

search.service: boolean that decides if the client should search for services on devices it found.

search.testconnect: boolean that decides if the client should connect to services found.

search.testtransfer: boolean that decides if the client should test file transfer.

file: indication of which file that should be sent.

iteration: how many iterations of the specified test-steps the client should execute.

sleeptime: number of milliseconds the client should sleep between each iteration.

The data from which we will draw our conclusion is collected during each iteration of the client. Mostof the data recorded on the server are for verification and comparison between server and client. Onthe client side of the test the following data is recorded:

• Total runtime

• Total time spent on device discovery

• Total time spent on service discovery

• Number of devices found

• Number of devices connected to the server

• Total time and byte rate during file transfers

All of this data is written to log files. The elements in this log files are separated by “;” to make iteasy to import into Microsoft Excel.

1069261690093;device_discovered;000BAC202CB0;102851069261690221;devicediscovery_time;;104141069261691436;service_found;btgoep://000BAC202CB0:2-authenticate=false-

encrypt=false-master=false;12151069261691744;connection;client_1;1069261692082;filesend_time;client_test.bin;112

56

8.1 Implementation

1069261692138;filesend_rate;client_test.bin;64.01069261692139;filesend_size;client_test.bin;71681069261692343;servicesearch_time;;2122

The following are “screen shots” from the execution of one of the tests:

Server side:

[kirkhus@beastie2:~/projectcode/JSR82code] ant runBuildfile: build.xml

run:[java] ----SERVER----[java] [STARTUP] Trying to start server[java] [STATUS] Listening for OBEX connection on server

000BAC203277 (beastie2-0)[java] [STATUS] Client #1 connected...[java] [STATUS] Listening for OBEX connection on server

000BAC203277 (beastie2-0)[java] [STATUS] onConnect[java] [STATUS] onPut[java] [INFO] Getting file: britty.jpg. Length: 7168[java] [INFO] File transferred[java] [STATUS] onDisconnect[java] [STATUS] Client #2 connected...[java] [STATUS] Listening for OBEX connection on server

000BAC203277 (beastie2-0)[java] [STATUS] onConnect[java] [STATUS] onPut[java] [INFO] Getting file: britty.jpg. Length: 7168[java] [INFO] File transferred[java] [STATUS] onDisconnect

Client side:

[kirkhus@debian:~/code] ant run -Dtype=clientBuildfile: build.xml

run:[java] ---Client---[java] [INFO] Starting device discovery #1[java] [INFO] Sleeping 40000 milliseconds.[java] [EVENT] Device discovered: 000BAC203277 (beastie2-0)[java] [STATUS] Starting service search on device 000BAC203277[java] [EVENT] Done searching for devices[java] [INFO] Service discovered on 000BAC203277:[java] [INFO] URL: btgoep://000BAC203277:2;authenticate=false;

encrypt=false;master=false[java] [INFO] Connecting to 000BAC203277[java] [STATUS] Connected to OBEX server[java] [INFO] Sending: /home/kirkhus/code/files/britty.jpg to the

57


server[java] [STATUS] Put response code: 162[java] [INFO] Disconnected from: 000BAC203277[java] [EVENT] Done searching for services on device 000BAC203277[java] [STATUS] Waking waiting thread for service discovery[java] [INFO] Starting device discovery #2[java] [INFO] Sleeping 40000 milliseconds.[java] [EVENT] Device discovered: 000BAC203277 (beastie2-0)[java] [STATUS] Starting service search on device 000BAC203277[java] [EVENT] Done searching for devices[java] [INFO] Service discovered on 000BAC203277:[java] [INFO] URL: btgoep://000BAC203277:2;authenticate=false;

encrypt=false;master=false[java] [INFO] Connecting to 000BAC203277[java] [STATUS] Connected to OBEX server[java] [INFO] Sending: /home/kirkhus/code/files/britty.jpg to the

server[java] [STATUS] Put response code: 162[java] [INFO] Disconnected from: 000BAC203277[java] [EVENT] Done searching for services on device 000BAC203277

These screen-dumps will look cryptic to most readers, and are really not meant to be read. They arestatus messages to enable us to debug and verify operation of the server and client. The real resultsof these test runs are the log files that will be processed in Microsoft Excel. The processed numberscan be found in Chapter 9.

Because we have utilised JSR-82 code for interfacing the Bluetooth hardware, much of this code canbe transferred to mobile phones later on. We have however used standard J2SE code in some placesand will have to find better ways to do this when implementing a real application on a real device.

See Appendix B for the complete source code.

8.2 Test execution

Since we have not developed a full application we will not be testing various user scenarios as a usualtest process would imply. We will instead concentrate on testing Bluetooth and try to find out ifBluetooth is suited for developing an application with support for add-hoc networks and spontaneouscollaboration trough profile exchange. As we stated in our non-functional requirements (Section 7.2),we wish to test the following:

• Range

• Discovery time

• Transfer rates

• Maximum range

8.2.1 The testing environment

The testing was performed with the following hardware environment:

58

8.2 Test execution

Figure 8.1: 3Com Wireless Bluetooth USB Adapter

• 1 desktop computer with Debian GNU/Linux installed as operating system

• 1 laptop computer with Debian GNU/Linux

• 2 3Com Wireless Bluetooth USB Adapter as the Bluetooth device to link the computers, seeFigure 8.1. These have range of 10 meters according to the manufacturer.

The physical environment for testing was in the hallways and computer labs at the university resem-bling a real life scenario with obstacles such as people and walls.

8.2.2 Test Process

The testing was performed during a period of two days. The tests was executed 30 iterations andperformed at three different ranges: 1 meter which will be optimal conditions, 6 meters for expectedreal life range and at 10 meter which was close to the maximum range of the test devices.

When testing the maximum range we did two tests, one with direct line-of-sight between the devices,and one with multiple obstacles in between the devices.

When testing the transfer rate, we used a jpg file with size 7 kB. We think that this size will berepresentative for the maximum amount of data that will transfered in an typical application like theProem profile exchange system.

All time units are measured in milliseconds, transfer rate in kilo Bytes per second and range in meter.

59

Part III

Results and Evaluation

60

In this part of the project we will evaluate the results we acquired with our test suite that we presentedin the previous chapter. We intend to see behind the results to find out what we have done right andwhat we might have done wrong. We will also show if Bluetooth is a suitable solution for our originalgoal of a profile exchange device.

61

Chapter 9

Test Results and Evaluation

In this chapter we will present the test results from our research on Bluetooth. For a description ofthe full test procedure see Section 8.2.2.

We have tested the following aspects:

• Device discovery

• Service discovery

• File transfer

• Maximum range

Device and service discovery are the crucial steps that needs to be completed if the devices are toconnect at all. They are also the two operations that takes the longest time. As mentioned in theprevious chapter, we will be utilising 3COM Bluetooth devices with a range of 10 meter. This is aradius, and thus this is the range in any direction. It means that when two devices moves past eachother there will be a window of 20 meter where they are in range.

After connecting we will wish to test the transfer-rates when transferring files. A profile exchangeprofile is not likely to transmit large amounts of data, but the tests are carried out with a 7KB filewhich is about the size of a small image. This will likely be in the higher estimates of how much anapplication will transfer.

In this chapter the test data has been compiled into graphical charts. For the full test output seeAppendix C.

9.1 Device discovery

All figures in this section is displayed with milliseconds on the Y-axis and run number on the X-axis.Please note that the scales has been adjusted so that the Y-axis does not start at zero, but close tothe lowest value. This enables us to see differences in times easier, but it also creates the impressionthat the difference is larger than actually the case is.

Figure ?? shows the device discovery times at the range of 1 meter. The time is fairly consistentand the average time is 10253.6 milliseconds. There are two runs that stand out, run 1 and run 14.

62


But compared to the average time they are only 19 and 9 milliseconds slower. These are not seriousdeviations when it comes to the end user experience.

Figure 9.1: Device discovery, 1m

Figure 9.2 shows the device discovery times at the range of 6 meters. Like at the 1 meter range, theresults does not vary much. Again we have some runs that stands out, but compared to the averageof 10253.7 milliseconds the difference is even smaller than at the 1 meter range.


63


Figure 9.3 shows the final discovery times at the range of 10 meters. Again we see that the times areconsistent, and that the few deviations that occur are very small compared to the average of 10253.2milliseconds.


Figure 9.4 compares the different ranges in respect to their discovery times. As we can see it isnearly identical for the different ranges. It is also common that the first run takes slightly more time.The reason for this is unknown, but one might speculate that the Bluetooth hardware takes time toinitialise the first time.

64


Figure 9.4: Device discovery comparison

We were at first a bit puzzled as to why device discovery times were constant and didn’t change withthe distance. After some research we found the answer in a paper by R Woodings, D Joos, T Cliftonand C Knutson [35]. It is because of the way Bluetooth was designed. It will always take 10240milliseconds to complete a device discovery. When doing discovery the Bluetooth device listens forresponses on 32 channels, but only 16 at a time. The device scans through these 16 channels and thattakes 10 milliseconds. To make sure you receive all the responses this must be repeated 256 times. Inaddition the Bluetooth specification ?? requires three switches of channel sets to listen to, meaningyou have to listen to each channel set twice.10 milliseconds x 256 times x 2 iterations x 2 frequency sets = 10240 milliseconds.

This was an effect we were not aware of until we performed the actual testing and saw the devicediscovery time was very consistent. This implies that Bluetooth devices might not be suitable forenvironments with much movement. At normal walking speed a person will have no problems covering10 meters in 15 seconds or less. If both users are walking in opposite directions the window will beeven smaller and you might end up with a situation where they will not find each other.

The conclusion for device discovery is that a average of 10253 milliseconds is acceptable, but couldcause problems if the subjects are moving too fast.

65


9.2 Service discovery

Service discovery is only possible after the device has been found, and will be the last step before aconnection can be made. In Figure 9.5 the test at 1 meter is visualised. In contrast with the devicediscovery where the differences between the tests were only a few milliseconds, we now see that thedeviations ranges from 10 to 300 milliseconds. It is important to note though, that 300 millisecondsis not a long time for a user to experience. The average service discovery time at 1 meter is 2117.3milliseconds.

Figure 9.5: Service discovery, 1m

Figure 9.6 shows the testing done at 6 meters. There is little difference between the two tests done sofar and the average at 6 meters, 2116.9 milliseconds, is even lower than the one at 1 meter.

66

9.2 Service discovery


When we study the test for 10 meters we notice 4 runs that took much longer than the results wegot from 1 and 6 meter. The spike at run 8 is over 16 seconds. The reason for this is unknown, butwe would speculate that the Bluetooth device lost the connection during this discovery and had toperform a new device discovery. Due to the 4 spikes we have in this set, we get an average of 3317.3milliseconds. Without these spikes the average would be 2584.8 milliseconds and close to the 1 and 6meters tests.


Figure 9.8 compares all three tests and confirms that the 1 meter and 6 meters tests are almost

67


identical and the 10 meter test takes a little bit longer for discovery than the other two tests. Theservice discovery seems to be a bit more dependent on the distance, but the times take increasessurprisingly little with the distance.

Figure 9.8: Service discovery comparison

The service discovery results shows us that it takes about two seconds regardless of distance. This isa small time-penalty compared to the device discovery, but adds to the delays the user experiences.12 seconds for device and service discovery is a serious problem in many situations as Woodings et al.points out in their article [35].

68

9.3 File transfer

9.3 File transfer

When testing the file transfer rates we made use of a binary file with the size 7 kilo Bytes. This sizewill probably be representative for the amount of data in an profile exchange application.

Figure 9.9 shows the transfer rates when testing at 1 meter. If we ignore the two spikes the test resultsis very consistent and all being around 22 kBps (kilo Bytes per second). The first spike however isvery abnormal. The theoretical bandwidth for Bluetooth is 1.1 mega bits per second and in the caseof run 22 the rate is as high as 1.6 mega bits per second. Run 22 is therefore a failed transmission.We have not been able to locate the cause of this but it is most likely an implementation issue. Thesecond spike at 77 kBps however is theoretically possible, but also in this case the transmission failed.The average transfer rate at 1 meter is 21 kBps when the two spikes are ignored.

Figure 9.9: File transfer rate, 1m

At 6 meters (Figure 9.10), we see that there are less spikes. The rate ranges from 19 up to 26 kBpsand the average rate is also here 21 kBps. At run 9 we have a failed transmission. The reason for thiswas probably that the devices were unable to connect after the service discovery. This might occurbecause of radio interference.

69



In the 10 meters test, see Figure 9.11 we see a huge difference from the other two. We have twofailed transmissions at run 8 and 18, and the rate range is from 4 to 38 kBps while the average is aslow as 12.3 kBps. The most probable cause for the rate being lower in this test is that the numberdisturbances in the radio link have increase and the devices had to do more error correction.


Figure 9.12 compares all file transfers and we see clearly that the test at 1 meter and 6 meters arevery identical, except for the spikes, and the 10 meters test are considerably slower.

70

9.3 File transfer

Figure 9.12: File transfer rate comparison

The final conclusion for the file transfer rate is that the experienced bandwidth are highly acceptablefor small files. We have seen a few cases where the file transfer has failed. This means that anapplication that needs to transfer files must be able to verify that the transfer succeeded and resenddata if it fails.

71


9.4 Maximum range

The maximum range test was done to confirm or reject the given range of 10 meter on the USBBluetooth devices. Since these are relatively large dongles that plug into the steady power outlet ofa USB socket on a PC, it is not reasonable to believe that the ranges we found here would will berepresentative for real life devices such as a mobile phone. Mobile phones are much smaller, and aremuch more conservative about their power.

As earlier mentioned, the test was performed with two kinds of conditions, line-of-sight and obstructed.The line-of-sight test gave us a result of about 26 meters which is far above the range of 10 metersthe manufacturers stated.

9.5 Result summary

To sum up the test evaluation we will use the example of two people using a Bluetooth device totransfer profile. We have three cases with different range, 1 meter, 6 meters and 10 meters. When theusers are positioned 1 meter from each other they will in average need a total of 12370.92 milliseconds,or 12.37 seconds, to complete a device discovery, service discovery and file transfer. This is also thecase when the users are at 6 meters. At 10 meters they will need 13130.11 milliseconds, or 13.13seconds to complete. In average these numbers sum up to 12624 milliseconds, 12.62 seconds. As wehave mentioned before there is a window of 20 meters where two user will be in range. Some simpletest of walking speed showed that at normal speed you would cover this distance in about 14 seconds.As you can see, in a real life test there will not be much time to spare if a full profile transactiontakes 12.62 seconds, and that does not include any errors in which case it will take even longer. Alsonot included are any additional processing time needed to parse the exchanged profiles. To see ifBluetooth still is suitable we need to conduct a test with real mobile devices.

72

Chapter 10

Problems and Solutions

During our testing and implementation we came across some problems. The problems span from Javarelated problems with the JSR-82 API to design choices in the Bluetooth specification.

10.1 Buffer size

One of the first problems we encountered was with the file transfer. On the server-side we have abuffer which is responsible for buffering the data which comes from the client.

int read = 0;byte[] buffer = new byte[1024];

while ((read = netStream.read(buffer)) != -1) {fileStream.write(buffer);

}

For optimum performance this buffer should probably be in the area of 4000 bytes. This is to minimisethe number of loops needed to transfer all the bytes of the file. However, we experienced that if wecreated a too large buffer we got the following exceptionjavax.bluetooth.BluetoothConnectionException: no resources exception. The symptomsonly occurred after a number of file transfers and this could indicate that the JSR-82 implementationwe used have some problems with transferring large amounts of data.

We never found a solution to this problem, but some experimenting with the buffer size we found thata buffer size of 1024 Bytes enabled us to do the tests that we wanted.

A side effect of use a smaller buffer was the transfer rate decreased since the while-loop have to iteratemore times. However, The performance loss was minimum compared with larger buffer sizes.

10.2 Bluetooth hardware cache

When a device is discovered during a device discovery session the address of this device is stored inthe hardware cache of the Bluetooth unit. On the devices we have used this cache lives for about 30

73

Problems and Solutions

seconds and any device discovery done the cache time will only return the content of this cache. Anew unit will not be found until after the cache expires.

We have tried to see if it is possible to flush this cache with the JSR-82 API, but with no luck. Theexplanation of this lies in the fact that JSR-82 is designed to be on top of a Bluetooth control center.JSR-82 itself is not responsible for the hardware and configuration of the hardware must be done inthe device’ own control center. E.g. on a Compaq IPAQ you have an application called BluetoothManager where options like this could have been set.

10.3 Long device discovery

As we have seen in Section 9.1 the device discovery, when not using the cache, takes at least 10.24seconds. Unfortunately this is a behaviour that is “by design” in the Bluetooth specification and notsomething we can change. On November fifth, 2003 the Bluetooth SIG announced version 1.2 of theBluetooth specification [5]. One of the new features listed for version 1.2 is faster inquiry responsewhich decrease the time needed for device discovery.

74

Part IV

Conclusion and Further Work

75

Chapter 11

Conclusion

In this research project we have examined technologies for facilitating spontaneous collaborationthrough mobile devices. We started out by comparing several different alternatives, and ended upchoosing a platform for the remainder of the project. The chosen technologies were Mobile phones,Java 2 Micro Edition and Bluetooth.

We originally wanted to create a small prototype application for testing the chosen technologies,but due to lack of support in mobile devices we had to settle for a partial solution. In this partialsolution we concentrated on JSR-82 and Bluetooth, while leaving the full MIDP 2.0 prototype forlater exploration.

The Proem [9] project has been our inspiration when wanting to create this prototype. As earliermentioned the Proem system exchanges user profiles to facilitate collaboration. The Bluetooth tech-nology we tested in this project will be an important aspect for such and application, and our researchhas concentrated around what information can be exchanged between two mobile devices.

After researching the technologies and developing a test suite for JSR-82 and Bluetooth we ran aseries of tests. The results for these tests gave us pointers to how well suited Bluetooth-technologywould be for such an application.

The results achieved in the tests suggests that Bluetooth will be within acceptable time frames for anapplication for profile exchange. It is however just inside the time frames, and rapid movement andother disturbances that delay the connection or transfer of information, will cause the devices to getout of range before the transaction can complete. This will probably be the exception, and not therule, and missing a connection in this kind of application need not be critical.

Our research showed that Bluetooth, even though it now has been around for some years, still haveweaknesses (as described in Section 9.1). These weaknesses affect the time it takes to establish aconnection, and will be important in highly mobile environments. The next version of Bluetoothannounced will take care of some of these problems.

Our experience with Java and Bluetooth has both it’s positive and negative sides. We are optimistic asto the suitability of Bluetooth for spontaneous collaboration. Java has a large developers base and wethink that we will in the near future see a wide range of applications utilising J2ME and Bluetooth.

76

Chapter 12

Further Work

This section will describe some of the areas we see as possible future work within collaboration onmobile devices. There are still many exiting topics to explore, and we hope to be able to work withsome of them during our Master thesis.

12.1 Application

While we started out hoping we could implement a prototype- application for mobile devices, severalfactors concerning technology rendered us unable to do this.

New devices are soon coming out that supports the MIDP 2.0 standard and JSR-82. Developing andtesting a real life prototype of an application much like the Proem [9] profile exchange application willbe possible.

This will enable us to see the real performance and usage impacts when utilising J2ME devices likethis. The numbers compiled in this report can give some indicators to whether such applications canbe created, and what response times the users can anticipate. But it is also important to see how theusers respond to the technology, and this will only show when deploying real life prototypes.

12.2 P2P-networks

The current investigation has been carried out with the assumption that the devices will connect asthey pass by each other, and thus retrieve the information needed. This will suffice when the user ismoving down the street of a large city, or down through a large convention with many people in asmall confined space. By moving around the device will connect to many other devices, and the userwill gather a relatively large amount of information.

Now, if this is a restaurant and the crowd stays in the same place most of the time, the devices farthestacross the room will not be able to connect to each other. It should be possible to connect to thedevice way across the room through the device in the middle of the room acting as a middleman.

Bluetooth supports such networks called scatternets, but this also requires routing algorithms and

77

Further Work

software for P2P-networks. The JXTA 1 project has an available version for J2ME called JXME 2,but this requires a centralised solution for routing.

Future work might explore creating a decentralised version of JXTA for J2ME. Since JXTA is a wellknown implementation of P2P in Java, a J2ME implementation would also ensure integration betweenmobile devices and larger computers running the full version of Java.

12.3 Security

Security is always important when giving away your personal information. We have taken little carefor this throughout this report. It will be an important thing to figure out when all the technical issuesare resolved, just how much information the users are willing to share, and under which mechanisms.

It is very important to find the balance between open and closed exchange. With too many restrictionswe might not achieve the effect of people meeting strangers because they share the same interests.With too few restrictions the information about a user might be misused.

12.4 Social networks

It might not just be important to register all the people you meet throughout a day, but also tap intotheir network of associates too. Websites like Friendster 3, and Tribe 4 are already registering usersand constructing social networks. This could easily be coupled with a mobile agent that expands yournetwork during daily encounters and synchronises with sites like these to tap into the already storednetwork.

In their article about social nets [42], M. Terry, E. Mynatt, K. Ryall and D. Leigh also explores theidea of registering physical closeness as two persons sharing the same interest. You could envision thiscoupled with sites like Friendster and Tribe to add special weighting to the relationships with peopleyou spend physical time with.

1http://www.jxta.org2http://jxme.jxta.org3http://www.friendster.com4http://tribe.net

78

Part V

Appendix

80

Appendix A

Implemented CLDC Classes

The following classes have been inherited directly from Java 2 Standard Edition. Each class is a subsetof the corresponding class in J2SE. The methods and field of these classes are a subset of the completeclasses as defined in the larger Java editions. Only thos methods and filds that are appropriate for”connected, limited devices” are specified by CLDC.

System Classes

From java.lang:

• Object, Class, Runtime, System, Thread, Runnable, String, StringBuffer, Throwable

Data Type Classes

From java.lang:

• Boolean, Byte, Short, Integer, Long, Character

Collection Classes

From java.util:

• Vector, Stack, Hashtable, Enumeration

I/O Classes

From java.io:

• InputStream, OutputStream, ByteArrayInputStream, ByteArrayOutputStream, DataIn-put, DataOutput, DataInputStream, DataOutputStream, Reader, Writer, InputStream-Reader, OutputStreamWriter, PrintStream

Calendar and Time Classes

From java.util:

• Calendar, Data, TimeZone

Additional Util Classes

• java.util.Random, java.lang.Math

Exception Classes

From java.lang:

82

• Exception, ClassNotFoundException, IllegalAccessException, InstantiationException,InterruptedException, RuntimeException, ArithmeticException, ArrayStoreException,ClassCastException, IllegalArgumentException, IllegalThreadStateException, Num-berFormatException, IllegalMonitorStateException, IndexOutOfBoundsException, Ar-rayIndexOutOfBoundsException, StringIndexOutOfBoundsException, NegativeArray-SizeException, NullPointerException, SecurityException

From java.util:

• EmptyStackException, NoSuchElementException

From java.io:

• EOFException, IOException, InterruptedException, UnsupportedEncodingException,UTFDataFormatException

Error Classes

From java.lang:

• Error, VirtualMachineError, OutOfMemoryError

Limitations

• CLDC includes limited support for the translation of Unicode characters to and from a sequenceof :bytes using Readers and Writers.

• CLDC does not support class java.util.Properties, which is part of J2SE. However,a limited set of properties beginning wiih the keyword ”microedition” can be accessed bycalling the method System.getProperty(String key).

83

Appendix B

Source code

This is the source for the main classes TestServer and TestClient.

TestServer.java

package no.ntnu.idi.mowahs.jsr82.prototype;

import java.io.File;import java.io.FileOutputStream;import java.io.IOException;import java.io.InputStream;

import javax.bluetooth.BluetoothStateException;import javax.bluetooth.DiscoveryAgent;import javax.bluetooth.L2CAPConnection;import javax.bluetooth.L2CAPConnectionNotifier;import javax.bluetooth.LocalDevice;import javax.microedition.io.Connection;import javax.microedition.io.Connector;import javax.obex.HeaderSet;import javax.obex.Operation;import javax.obex.ResponseCodes;import javax.obex.ServerRequestHandler;import javax.obex.SessionNotifier;

import no.ntnu.idi.mowahs.util.ConnectionUtil;import no.ntnu.idi.mowahs.util.Logging;

public class TestServerextends ServerRequestHandler {

static private int connectionNumber = 0;private boolean execute = true;private LocalDevice localDevice;private String serviceURL =

"btgoep://localhost:"+ "68EE141812D211D78EED00B0D03D76EC"+ ";name=MOWAHSProfileServer";

84

private Logging log;private Config config;

/*** constructor for this class** @param config* Configuration parameters*/

public TestServer(Config config) {

this.config = config;

System.out.println("----SERVER----");

System.out.println("[STARTUP] Trying to start server");

log = config.getLogger();initServer();

}

/*** Starts local device**/

public void initLocalDevice() {try {

localDevice = LocalDevice.getLocalDevice();localDevice.setDiscoverable(DiscoveryAgent.GIAC);

} catch (BluetoothStateException e) {System.out.println(

"[ERROR] Could not initialize local bluetooth device: " + e);System.exit(1);

}}

/*** Method that runs the server**/

public void initServer() {

//Create the connection to represent the serviceConnection conn = null;try {

conn = Connector.open(serviceURL);} catch (IOException e) {

System.out.println("[ERROR] Could not create listener for url "

+ serviceURL+ ": "+ e);

85

Source code

System.exit(1);}

while(true) {initLocalDevice();// If this is an L2CAPConnectionif (conn instanceof L2CAPConnectionNotifier) {

openL2CAP(conn);} else if (conn instanceof SessionNotifier) {

openOBEX(conn);}

}

}

/*** Method resposible for opening an OBEX connection** @param conn* The incomming connection*/

private void openOBEX(Connection conn) {SessionNotifier session = (SessionNotifier) conn;try {

System.out.println("[STATUS] Listening for OBEX connection on server "

+ localDevice.getBluetoothAddress()+ " ("+ localDevice.getFriendlyName()+ ")");

session.acceptAndOpen(this);connectionNumber++;log.logInfo("connection", "server_" + connectionNumber, null);System.out.println(

"[STATUS] Client #" + connectionNumber + " connected...");} catch (IOException e) {

System.err.println(e);}

}

/*** Method resposible for opening an L2CAP connection** @param conn* The incomming connection*/

private void openL2CAP(Connection conn) {L2CAPConnectionNotifier connListener =

(L2CAPConnectionNotifier) conn;L2CAPConnection openConn = null;try {

System.out.println(

86

"[STATUS] Listening for L2CAP connection on server "+ localDevice.getBluetoothAddress()+ " ("+ localDevice.getFriendlyName()+ ")");

openConn = connListener.acceptAndOpen();System.out.println("[STATUS] Connection accepted, starting transfer");openConn.send("HELLO from server\n".getBytes());openConn.send("BYE from server\n".getBytes());System.out.println("[STATUS] Transfer complete close connection");

} catch (IOException e) {System.err.println(e);

}}

/*** Method executed when a client connects** @param arg0* contains the headers sent by the client** @param arg1* the headers that should be sent in the reply**/

public int onConnect(HeaderSet arg0, HeaderSet arg1) {System.out.println("[STATUS] onConnect");return super.onConnect(arg0, arg1);

}

/*** Mehtod executed when a client disconnects** @param arg0* contains the headers sent by the client* @param arg1* the headers that should be sent in the reply**/

public void onDisconnect(HeaderSet arg0, HeaderSet arg1) {System.out.println("[STATUS] onDisconnect");super.onDisconnect(arg0, arg1);

}

/*** Method that is executed when a client uploads a file** @ param op* ontains the headers sent by the client*/

public int onPut(Operation op) {

87

Source code

System.out.println("[STATUS] onPut");FileOutputStream fileStream = null;InputStream netStream = null;try {

HeaderSet headers = op.getReceivedHeaders();netStream = op.openInputStream();

String fileName = (String) headers.getHeader(HeaderSet.NAME);int fileLength = Integer.parseInt(((Long) headers.getHeader(HeaderSet.LENGTH)).toString());

File outFile = new File("upload/" + fileName);fileStream = new FileOutputStream(outFile);

System.out.println("[INFO] Getting file: " + fileName + ". Length: " + fileLength);

int read = 0;byte[] buffer = new byte[config.getBuffersize()];

log.storeTime("filesend_start_" + op);while ((read = netStream.read(buffer)) != -1) {

fileStream.write(buffer);}fileStream.flush();long time = log.logDiff("filesend_start_" + op, "filesend_end_" + op, "filesend_time", "server_" + fileName);double rate = (fileLength / time);log.logMeasure("filesend_rate", "server_" + fileName, rate);log.logMeasure("filesend_size", "server_" + fileName, fileLength);

System.out.println("[INFO] File transferred");} catch (IOException e) {

e.printStackTrace();} finally {

ConnectionUtil.close(fileStream);ConnectionUtil.close(netStream);

}return ResponseCodes.OBEX_HTTP_ACCEPTED;

}}

TestClient.java

package no.ntnu.idi.mowahs.jsr82.prototype;

import java.io.DataOutputStream;import java.io.File;import java.io.FileInputStream;import java.io.IOException;import java.io.InputStream;

import java.util.Hashtable;

88

import javax.bluetooth.BluetoothStateException;import javax.bluetooth.DeviceClass;import javax.bluetooth.DiscoveryAgent;import javax.bluetooth.DiscoveryListener;import javax.bluetooth.LocalDevice;import javax.bluetooth.RemoteDevice;import javax.bluetooth.ServiceRecord;import javax.bluetooth.UUID;

import javax.microedition.io.Connection;import javax.microedition.io.Connector;

import javax.obex.ClientSession;import javax.obex.HeaderSet;import javax.obex.Operation;

import no.ntnu.idi.mowahs.util.UUIDValues;import no.ntnu.idi.mowahs.util.Logging;import no.ntnu.idi.mowahs.util.ConnectionUtil;

/*** @author kirkhus**/public class TestClient implements DiscoveryListener, UUIDValues {

/** Logging util */private Logging log;

/** Runtime parameters and config */private Config config;

/*** Max number of service searches for this devices. Is retrieved from* LocalDevice*/

int maxSearches = 0;/** Current number of service searches */int numSearches = 0;/** Lock object for wait on deviceSearch */private Object deviceSearchActive = new Object();/** Counter to identify the devicesearch currently running */private static int deviceSearchNumber = 0;/** Lock object for wait on service search */private Object serviceSearchActive = new Object();/** Lock object for waiting for filetransef */private Object fileTransferActive = new Object();/** Lets us know if a filetransfer is active */private boolean transferring = false;/** Keeps the active serviceSearchTransactions */private Hashtable serviceSearchTransactions = new Hashtable();

/** The discoveryagent to use */

89

Source code

private DiscoveryAgent agent;/** The local device representing the Bluetooth device */private LocalDevice localDevice;

private int connectionNumber;

/*** Constructor for this class** @param config* The configuration variables*/

public TestClient(Config config) {System.out.println("---Client---");

this.config = config;log = config.getLogger();

log.logMeasure("program_iterations", null, config.getIterations());

initLocalDevice();

runClient();

}

/*** Method that is responsible for running the client**/

private void runClient() {

log.storeTime("program_runtime_start");agent = localDevice.getDiscoveryAgent();/* for-loop that runs the discovery */for (int i = 0; i < config.getIterations(); i++) {

if (this.transferring) {System.out.println(

"[INFO] Transferring active, waiting before devicediscovery");synchronized (fileTransferActive) {

try {fileTransferActive.wait();

} catch (InterruptedException e) {//Don’t care

}}

}

deviceSearchNumber++;startDiscovery();

90

try {System.out.println(

"[INFO] Sleeping "+ config.getSleeptime()+ " milliseconds.");

Thread.sleep(config.getSleeptime());} catch (InterruptedException e1) {

// Don’t care}

}

long runtime = log.diffTime("program_runtime_start");long realtime =

runtime - config.getIterations() * config.getSleeptime();log.storeTime("program_runtime_end");log.logDiff(

"program_runtime_start","program_runtime_end","program_time",null);

}

/*** Mehtod that inits the local device (surprise surprise)**/

private void initLocalDevice() {try {

localDevice = LocalDevice.getLocalDevice();maxSearches =

Integer.parseInt(LocalDevice.getProperty("bluetooth.sd.trans.max"));


"[ERROR] Could not open local bluetooth device. Exiting...");System.exit(1);

}}

/*** Starts device discovery Whenever a device is found, deviceDiscovered()* in the supplied interface (in this case, this class) will be called**/

private void startDiscovery() {System.out.println("[INFO] Starting device discovery #" + deviceSearchNumber);try {

log.storeTime("devicediscovery_" + deviceSearchNumber + "_start");agent.startInquiry(DiscoveryAgent.GIAC, this);


"[ERROR] Could not initiate device search: " + e);e.printStackTrace();

91

Source code

System.exit(1);}

log.storeTime("devicediscovery_" + deviceSearchNumber + "_start");}

/*** Called when a device is found** @param device* the RemoteDevice that was found* @param code* DeviceClass for that device**/

public void deviceDiscovered(RemoteDevice device, DeviceClass code) {

log.logDiff("devicediscovery_" + deviceSearchNumber + "_start","devicediscovery_" + deviceSearchNumber + "_end","devicediscovery_time",null);

log.logInfo("device_discovered", device.getBluetoothAddress(),"devicediscovery_" + deviceSearchNumber + "_start");

try {System.out.println(

"[EVENT] Device discovered: "+ device.getBluetoothAddress()+ " ("+ device.getFriendlyName(true)+ ")");

} catch (IOException e) {//Don’t care just print linefeedSystem.out.println("[ERROR] Error getting friendly name");System.out.println(

System.currentTimeMillis()+ "[EVENT] Device discovered: "+ device.getBluetoothAddress());

}

// run service discovery if specifiedif (config.isTestServiceSearch()) {

startServiceDiscovery(device);}

}

/*** Menthod that start searching for services on the give device** @param device* The RemoteDevice that we shall start searching for devices on*/

private void startServiceDiscovery(RemoteDevice device) {

92

if (numSearches == maxSearches) {System.out.println(

"[WARNING] Too many service searches. Waiting for release of one.");synchronized (serviceSearchActive) {

try {serviceSearchActive.wait();

} catch (InterruptedException e1) {// Don’t care

}}

}

System.out.println("[STATUS] Starting service search on device "

+ device.getBluetoothAddress());int[] args = null;UUID[] services = new UUID[1];services[0] = profileServer;DiscoveryAgent agent = localDevice.getDiscoveryAgent();try {

int transaction =agent.searchServices(args, services, device, this);

log.storeTime("servicesearch_" + transaction + "_start");serviceSearchTransactions.put(new Integer(transaction), device);numSearches++;


"[ERROR] Unable to start service search for device: "+ device.getBluetoothAddress()+ " "+ e);

}}

/**** Method that is called when a service discovery is completed and one or more services* were found*** @param transaction* this transactions number* @param services* array with services found**/

public void servicesDiscovered(int transaction, ServiceRecord[] services) {

for (int ctr = 0; ctr < services.length; ctr++) {ServiceRecord currentRecord = services[ctr];log.logInfo(

"service_found",

93

Source code

currentRecord.getConnectionURL(ServiceRecord.NOAUTHENTICATE_NOENCRYPT,false).replaceAll(";", "-"),

"servicesearch_" + transaction + "_start");

printServiceInfo(currentRecord);

if (config.isTestConnect()) {connect(currentRecord);

}}

}

/*** Method that will connect to a service on a remote device*** @param currentRecord* The service we want to connect to*/

private void connect(ServiceRecord currentRecord) {Connection conn = null;try {

System.out.println("[INFO] Connecting to "

+ currentRecord.getHostDevice().getBluetoothAddress());conn =

Connector.open(currentRecord.getConnectionURL(

ServiceRecord.NOAUTHENTICATE_NOENCRYPT,false));

if (conn instanceof ClientSession) {System.out.println("[STATUS] Connected to OBEX server");ClientSession session = (ClientSession) conn;connectionNumber++;log.logInfo(

"connection","client_" + connectionNumber,null);

if (config.isTestTransfer()) {sendFile(session);

}//stay connected if specifiedif (config.isPersistent()) {

boolean connect = true;long persistentTime = config.getPersistentTime() +

System.currentTimeMillis();while (connect) {

if (System.currentTimeMillis() >= persistentTime) {connect = false;

}}

94

}

session.disconnect(null);System.out.println(

"[INFO] Disconnected from: "+ currentRecord.getHostDevice().getBluetoothAddress());

} else {System.out.println(

"[WARNING] Not a recognised connection: "+ currentRecord.getConnectionURL(

ServiceRecord.NOAUTHENTICATE_NOENCRYPT,false));

}} catch (IOException e) {

System.out.println("[ERROR] Failed opening a connection to: "

+ currentRecord.getHostDevice().getBluetoothAddress());e.printStackTrace();

} catch (IllegalArgumentException e) {System.out.println(

"[ERROR] Illegal argument when connecting to: "+ currentRecord.getHostDevice().getBluetoothAddress());

e.printStackTrace();} finally {

ConnectionUtil.close(conn);}

}

/*** Method that prints extra information about a service** @param currentRecord* The current service*/

private void printServiceInfo(ServiceRecord currentRecord) {System.out.println(

"[INFO] Service discovered on "+ currentRecord.getHostDevice().getBluetoothAddress()+ ": ");

System.out.println("[INFO] URL: "

+ currentRecord.getConnectionURL(ServiceRecord.NOAUTHENTICATE_NOENCRYPT,false));

//print server attribs if specifiedif (config.isPrintServiceAttributes()) {

int[] attributeIDs = currentRecord.getAttributeIDs();for (int ctr2 = 0; ctr2 < attributeIDs.length; ctr2++) {

System.out.println(

95

Source code

"[INFO] Attribute "+ attributeIDs[ctr2]+ " is "+ currentRecord.getAttributeValue(attributeIDs[ctr2]));

}}

}

/*** Send the profile of this user over OBEX** @param session* The session to send over* @throws IOException* Could not write to stream or read profile from file*/

private void sendFile(ClientSession session) {HeaderSet connectHeader = null;DataOutputStream netStream = null;InputStream fileReadStream = null;Operation op = null;try {

transferring = true;File trans = config.getFile();System.out.println(

"[INFO] Sending: " + trans.getAbsolutePath() + " to the server");fileReadStream = new FileInputStream(trans);if (fileReadStream != null) {

connectHeader = session.connect(connectHeader);HeaderSet getHeader = session.createHeaderSet();getHeader.setHeader(HeaderSet.NAME, config.getFile().getName());getHeader.setHeader(

HeaderSet.LENGTH,new Long(config.getFile().length()));

op = session.put(getHeader);

String filename = config.getFile().getName();

byte[] buffer = new byte[config.getBuffersize()];int read;

FileInputStream fileStream =new FileInputStream(config.getFile());

netStream = op.openDataOutputStream();

log.storeTime("filesend_start_" + session.getConnectionID());while ((read = fileStream.read(buffer)) != -1) {

netStream.write(buffer);}netStream.flush();long time =

log.logDiff("filesend_start_" + session.getConnectionID(),

96

"filesend_end_" + session.getConnectionID(),"filesend_time","client_" + filename);

if (time == 0)time = -1;

double rate = (config.getFile().length() / time);log.logMeasure("filesend_rate", "client_" + filename, rate);log.logMeasure(

"filesend_size","client_" + filename,config.getFile().length());

} else {System.out.println(

"[WARNING] fileReadStream: " + fileReadStream);}System.out.println(

"[STATUS] Put response code: " + op.getResponseCode());} catch (IOException e) {

e.printStackTrace();} catch (ArithmeticException e) {

System.out.println("[ERROR] Caught an AritmeticException, time was ZERO!");} finally {

//ConnectionUtil.close(netStream);ConnectionUtil.close(fileReadStream);transferring = false;synchronized (fileTransferActive) {

fileTransferActive.notify();}

}}

public void serviceSearchCompleted(int transID, int responseCode) {

log.logDiff("servicesearch_" + transID + "_start","servicesearch_" + transID + "_end","servicesearch_time",null);

RemoteDevice removed =(RemoteDevice) serviceSearchTransactions.remove(

new Integer(transID));System.out.println(

"[EVENT] Done searching for services on device "+ removed.getBluetoothAddress());

numSearches--;synchronized (serviceSearchActive) {

System.out.println("[STATUS] Waking waiting thread for service discovery");

serviceSearchActive.notify();

97

Source code

}

}

/*** Method executed when device discovery is finished** @param int discoveryType* the type of request that was completed**/

public void inquiryCompleted(int discoveryType) {System.out.println("[EVENT] Done searching for devices");

}}

98

Appendix C

Test Result Tables

The following are the output from our logfile for device and service discovery and file transfer. Alltimes are in milliseconds and rate in kilo Bytes per second.

99

Test Result Tables

C.1 Device Discovery

Output from the device discovery tests. All times are in milliseconds.

Run number 1 meter 6 meter 10 meter1 10272 10263 102632 10252 10254 102523 10253 10262 102524 10253 10252 102535 10252 10254 102536 10252 10253 102527 10253 10252 102538 10253 10253 102529 10252 10253 1025310 10253 10253 1025211 10253 10252 1025312 10253 10254 1025313 10254 10253 1025214 10262 10252 1025215 10253 10254 1025316 10253 10253 1025317 10252 10253 1025318 10253 10254 1025219 10253 10253 1025320 10252 10252 1025321 10252 10252 1025422 10253 10252 1025223 10254 10254 1025424 10251 10253 1025325 10253 10253 1025326 10253 10252 1025427 10253 10253 1025328 10252 10253 1025329 10253 10256 1025330 10253 10255 10255Average time 10253,6 10253,7 10253,2

Table C.1: Device discovery results

100

C.2 Service Discovery

C.2 Service Discovery

Output from the service discovery tests. All times are in milliseconds.

Run number 1 meter 6 meter 10 meter1 1993 2375 33512 2172 2249 23263 2118 1951 52614 2211 2265 50445 2208 2033 59046 2198 1881 32147 2273 2169 35068 2230 2135 161049 2189 1877 315910 2218 2206 238411 1728 1947 248612 2156 2137 264113 2197 2154 257614 2242 2214 268415 2202 2196 282716 1947 1880 285317 2208 2164 262918 2183 2181 220319 1962 1914 264420 2167 2155 258821 2148 1994 281422 1844 2265 247423 2150 2152 228624 2150 2210 217625 2035 2100 218826 2204 2159 226827 2176 2197 215428 2145 1958 236129 1701 2186 244630 2165 2203 1967Average time 2117,3 2116,9 3317,3

Table C.2: Service discovery results

101

Test Result Tables

C.3 File transfer rates

Output from the file transfer tests. All numbers are in KB/s.

Run number 1 meter 6 meter 10 meter1 16 19 62 22 21 163 22 21 94 22 21 85 22 22 66 16 21 67 18 21 48 20 23 09 22 0 510 19 22 1511 18 21 812 22 21 1013 21 23 914 19 21 1115 21 22 716 23 21 917 22 22 1118 22 22 019 20 22 1120 23 25 1121 23 22 922 204 20 1323 23 23 1824 23 22 2225 22 22 2026 20 26 1827 23 22 3828 23 22 1529 77 20 1230 21 21 17Average rate 28,9 21,0 11,5

Table C.3: File transfer rate results

102

Index

.NET, 27

Bluetooth, 30, 40controller, 40deviceclass, 41host, 40inquiry, 42JSR-82, 38, 47L2CAP, 41master, 43piconet, 43profile, 42protocols, 41radio, 40range, 31, 41scatternet, 43, 44, 77security, 44service discovery, 42Special Interest Group, 30, 39stack, 40

BREW, 25

CDMA, 26

Infrared, 29

J2ME, 24, 35Configuration, 24, 36JSR-82, 38, 47KVM, 24Over-the-air provisioning, 24Profile, 24, 38

MOWAHS, 12goals, 12projects, 12

Palm OS, 28Proem, 11

Qualcomm, 25

Smartphone, 27Symbian, 26

Wireless Local Area Network, 30

103

Bibliography

[1] Bluetooth Special Interest Group. http://www.bluetooth.org (Accessed: 2.9.2003). 3.3.3,5.2.1

[2] Ericsson. http://www.ericsson.com (Accessed: 3.9.2003). 3.3.3

[3] IrDA - Infrared Data Association. http://www.irda.org (Accessed: 23.9.2003). 3.3.1

[4] Vincent Alzieu. Bluetooth: A rundown. Tom’s Hardware, 2003. 5.2.1

[5] Bluetooth SIG. Bluetooth Specification v 1.2. https://www.bluetooth.org/spec/ (Accessed:3.10.2003). 10.3

[6] Bluetooth SIG. Specification of the Bluetooth System. http://www.bluetooth.com/pdf/Bluetooth_11_Specifications_Book.pdf (Accessed: 3.9.2003), 2001. 5.2, 5.2.3, 5.2.6

[7] Timothy J. Thompson C Bala Kumar, Paul J. Kline. Bluetooth Application Programming withthe Java APIs. Morgan Kaufman, first edition, 2003. 5.2.6

[8] C. Enrique Ortiz. Introduction to OTA Application Provisioning. http://wireless.java.sun.com/midp/articles/ota/ (Accessed: 8.10.2003). 3.2.1

[9] G. Kortuem and Z. Segall and Th.G. Cowan Thompson. Close Encounters: Supporting Mo-bile Collaboration Through Interchange of User Profiles. Lecture Notes in Computer Science,1707:171–??, 1999. (document), 1.1, 1.2, 2.3, 11, 12.1

[10] IEEE. Institute of Electrical and Electronics Engineers webpage. http://www.ieee.org (Ac-cessed: 10.10.2003). 3.3.2

[11] IEEE. IEEE Std 802.11-1997 - Information Technology- telecommunications And Informationexchange Between Systems-Local And Metropolitan Area Networks-specific Requirements-part11: Wireless Lan Medium Access Control (MAC) And Physical Layer (PHY) Specifications. 1997.3.3.2

[12] Palm Inc. Palm website. http://www.palm.com/ (Accessed: 29.9.2003). 3.2.6

[13] Palmsource Inc. Palmos website. http://www.palmsource.com/ (Accessed: 21.10.2003). 3.2.6

[14] L. Holmquist and J. Falk and J. Wigstrm. Supporting Group Collaboration with Inter-Personal Awareness Devices. citeseer.nj.nec.com/holmquist99supporting.html (Accessed:2.9.2003), 1999. (document), 2.1

[15] Microsoft. Microsoft .NET webpage. http://www.microsoft.com/net/ (Accessed: 1.10.2003).3.2.5

[16] Microsoft. Microsoft Pocket PC. http://www.microsoft.com/windowsmobile/products/pocketpc/default.mspx (Accessed: 14.10.2003). 3.2.5, 3.2.6

104

http://www.bluetooth.org

http://www.ericsson.com

http://www.irda.org

https://www.bluetooth.org/spec/

http://www.bluetooth.com/pdf/Bluetooth_11_Specifications_Book.pdf

http://www.bluetooth.com/pdf/Bluetooth_11_Specifications_Book.pdf

http://wireless.java.sun.com/midp/articles/ota/

http://wireless.java.sun.com/midp/articles/ota/

http://www.ieee.org

http://www.palm.com/

http://www.palmsource.com/

citeseer.nj.nec.com/holmquist99supporting.html

http://www.microsoft.com/net/

http://www.microsoft.com/windowsmobile/products/pocketpc/default.mspx

http://www.microsoft.com/windowsmobile/products/pocketpc/default.mspx

BIBLIOGRAPHY

[17] Microsoft. Microsoft webpage. http://www.microsoft.com (Accessed: 1.10.2003). 3.2.5

[18] Microsoft. Smartphone available devices webpage. http://www.microsoft.com/windowsmobile/buyersguide/compare/emea/smartphone.mspx (Accessed: 11.10.2003).3.2.5

[19] Microsoft. Windows CE webpage. http://www.microsoft.com/windows/embedded/ce.net/default.asp (Accessed: 11.10.2003). 3.2.5

[20] Microsoft Corporation. Smartphone webpage. http://www.microsoft.com/windowsmobile/products/smartphone/default.mspx (Accessed: 11.10.2003). 3.2.5

[21] Sun Microsystems. Sun Microsystems website. http://www.sun.com/ (Accessed: 3.9.2003).3.2.1

[22] MIT. Massachusetts Institute of Technology. http://www.mit.edu (Accessed: 1.10.2003). 2.4

[23] MIT Media Lab. Thinkning Tags. http://lcs.www.media.mit.edu/groups/el/projects/tag/(Accessed: 1.10.2003). 2.4

[24] Mophun. Mophun website. http://www.mophun.com (Accessed: 13.9.2003). 3.2.2

[25] Nokia. Series 60 MIDP SDK 1.2.1. http://www.forum.nokia.com/main/0,6566,034-3,00.html (Accessed: 19.9.2003). 6.1.2, 7.3.1

[26] NTNU. Department of Computer and Information Science webpage. http://www.idi.ntnu.no.(document)

[27] NTNU. Norwegian University of Science and Technology homepage. http://www.ntnu.no (Ac-cessed: 7.10.2003). (document)

[28] NTNU. The Software Engineering Group webpage. http://www.idi.ntnu.no/grupper/su/(Accessed: 7.10.2003). (document)

[29] P. Dahlberg and F. Ljungberg and J. Sannenblad. Proxy Lady: Mobile Support for Opportunis-tic Communication. citeseer.nj.nec.com/dahlberg99proxy.html (Accessed: 7.9.2003), 1999.(document), 2.2

[30] Post og Teletilsynet. Telemarkedet 2002. http://www.npt.no/pt_internet/venstremeny/publikasjoner/telestatistikk/statistikk2002/norsk/telestatistikk2002.pdf (Ac-cessed: 7.9.2003), 2003. I, 3.1.1

[31] Java Community Process. Java APIs for Bluetooth. http://www.jcp.org/en/jsr/detail?id=82 (Accessed: 26.08.2003), 2003. 5.1.4

[32] MOWAHS Project. MOWAHS homepage. http://www.mowahs.com (Accessed: 27.8.2003). 1.3

[33] Qualcomm. Brew and J2ME - A complete wireless solution for operators commited to Java. http://www.qualcomm.com/brew/images/about/pdf/brew_j2me.pdf (Accessed: 19.10.2003). 3.2.3

[34] Rococo Software. Imprinto simulator and Impronto Developers Kit for Linux . http://www.rococosoft.com/products/evaluate.html (Accessed: 25.10.2003). 6.1.2, 6.1.3, 6.1.4

[35] Ryan Woodings, Derek Joos, Trevor Clifton, Charles D. Knutson. Rapid heterogeneousconnection establishment: Accelerating bluetooth inquiry using irda. http://faculty.cs.byu.edu/~knutson/publications/IrDA_Assisted_BT_Discovery.pdf (Accessed: 15.11.2003),2002. 9.1, 9.2

[36] Seamus McAteer. Java Will Be the Dominant Handset Platform. 2002. 3.1.1

105

http://www.microsoft.com

http://www.microsoft.com/windowsmobile/buyersguide/compare/emea/smartphone.mspx

http://www.microsoft.com/windowsmobile/buyersguide/compare/emea/smartphone.mspx

http://www.microsoft.com/windows/embedded/ce.net/default.asp

http://www.microsoft.com/windows/embedded/ce.net/default.asp

http://www.microsoft.com/windowsmobile/products/smartphone/default.mspx

http://www.microsoft.com/windowsmobile/products/smartphone/default.mspx

http://www.sun.com/

http://www.mit.edu

http://lcs.www.media.mit.edu/groups/el/projects/tag/

http://www.mophun.com

http://www.forum.nokia.com/main/0,6566,034-3,00.html

http://www.forum.nokia.com/main/0,6566,034-3,00.html

http://www.idi.ntnu.no

http://www.ntnu.no

http://www.idi.ntnu.no/grupper/su/

citeseer.nj.nec.com/dahlberg99proxy.html

http://www.npt.no/pt_internet/venstremeny/publikasjoner/telestatistikk/statistikk2002/norsk/telestatistikk2002.pdf

http://www.npt.no/pt_internet/venstremeny/publikasjoner/telestatistikk/statistikk2002/norsk/telestatistikk2002.pdf

http://www.jcp.org/en/jsr/detail?id=82

http://www.jcp.org/en/jsr/detail?id=82

http://www.mowahs.com

http://www.qualcomm.com/brew/images/about/pdf/brew_j2me.pdf

http://www.qualcomm.com/brew/images/about/pdf/brew_j2me.pdf

http://www.rococosoft.com/products/evaluate.html

http://www.rococosoft.com/products/evaluate.html

http://faculty.cs.byu.edu/~knutson/publications/IrDA_Assisted_BT_Discovery.pdf

http://faculty.cs.byu.edu/~knutson/publications/IrDA_Assisted_BT_Discovery.pdf

BIBLIOGRAPHY

[37] Sun Microsystems. Java 2 Micro Edition. http://java.sun.com/j2me/ (Accessed: 2.9.2003).3.2.1

[38] Sun Microsystems. The CLDC HotSpot Implementation Virtual Machine. http://java.sun.com/products/cldc/wp/CLDC_HI_WhitePaper.pdf (Accessed: 26.9.2003). 5.1.2

[39] Symbian Technology. Why is a different Operating System needed? http://www.symbian.com/technology/why-diff-os.html (Accessed: 25.9.2003), 2002. 3.2.4

[40] Synergenix. Synergenix website. http://www.synergenix.se (Accessed: 13.9.2003). 3.2.2

[41] Synergenix. Mophun whitepaper. http://www.mophun.com/files/mophun_information_package.zip (Accessed: 13.9.2003), 2003. 3.2.2

[42] M. Terry, E. Mynatt, K. Ryall, and D. Leigh. Social net: Using patterns of physical proximity overtime to infer shared interests. http://citeseer.nj.nec.com/terry02social.html (Accessed:10.11.2003), 2002. 12.4

[43] ZDNet Insight. J2ME or BREW for wireless development? http://insight.zdnet.co.uk/hardware/mobile/0,39020442,2119365,00.htm (Accessed: 1.10.2003), 2002. 3.2.3

[44] ZelosGroup. Measuring the Market Impact of Bluetooth. http://www.bluetoothsig.com/emailfiles/Zelos.pdf (Accessed: 18.10.2003), 2002. 3.3.3, 5.2.1

106

http://java.sun.com/j2me/

http://java.sun.com/products/cldc/wp/CLDC_HI_WhitePaper.pdf

http://java.sun.com/products/cldc/wp/CLDC_HI_WhitePaper.pdf

http://www.symbian.com/technology/why-diff-os.html

http://www.symbian.com/technology/why-diff-os.html

http://www.synergenix.se

http://www.mophun.com/files/mophun_information_package.zip

http://www.mophun.com/files/mophun_information_package.zip

http://citeseer.nj.nec.com/terry02social.html

http://insight.zdnet.co.uk/hardware/mobile/0,39020442,2119365,00.htm

http://insight.zdnet.co.uk/hardware/mobile/0,39020442,2119365,00.htm

http://www.bluetoothsig.com/emailfiles/Zelos.pdf

http://www.bluetoothsig.com/emailfiles/Zelos.pdf

an examination of mobile devices for spontaneous ... · an examination of mobile devices ... the...

Documents