Bluetooth Based Location Estimation for Mobile ... 1 Introduction Wireless communication technologies have undergone remarkable advances over the last decade. This re ected directly

Department of Electrical and Computer Engineering

Faculty of Engineering and Architecture

American University of Beirut

Bluetooth Based Location Estimation

for Mobile Applications

Final Year Project

Spring 2005-2006

Advisor: Dr. Zaher Dawy

Group: Hussein Fadlallah, ID 200300508Reda Haidar, ID 200300525Samer Khattab, ID 200300529

Submitted on: 23.05.2006

Acknowledgements

We would like to thank Dr. Zaher Dawy for the proposal of the idea, supportingus with previous FYP reports, aiding us with useful resources in preparing thereport, and giving us his time to make sure that we are on the right track.

Moreover, we would like to thank Dr. Albert Huang of MIT for giving us apush start in the programming part of the project. We would also like to thankDr. Cristiano di Flora and Dr. Massimo Ficco of University of Napoli for theirfeedback on the Java programming of Bluetooth.

Last but not least, we would like to thank Ericsson Lebanon Communications forsponsoring our project.

Contents

1 Introduction 2

1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2 Problem De�nition and Objectives . . . . . . . . . . . . . . . . . 4

1.3 Document Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Theoretical Background 6

2.1 Localization Systems . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.1.1 Satellite Systems . . . . . . . . . . . . . . . . . . . . . . . 7

2.1.2 Cellular Networks . . . . . . . . . . . . . . . . . . . . . . . 7

2.1.3 Wireless LAN . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.1.4 Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.1.5 Sensor Networks . . . . . . . . . . . . . . . . . . . . . . . 15

2.2 Location Based Services . . . . . . . . . . . . . . . . . . . . . . . 16

2.2.1 Positioning . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.2.2 Tracking . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.2.3 Invoicing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.2.4 Reminding . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.2.5 Pro�ling . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.3 Localization Methods . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.3.1 Time of Arrival . . . . . . . . . . . . . . . . . . . . . . . . 19

2.3.2 Time Di�erence of Arrival . . . . . . . . . . . . . . . . . . 20

2.3.3 Angle of Arrival . . . . . . . . . . . . . . . . . . . . . . . . 20

2.3.4 Received Power . . . . . . . . . . . . . . . . . . . . . . . . 21

2.3.5 Cell Identity . . . . . . . . . . . . . . . . . . . . . . . . . . 21

ii CONTENTS

2.4 Power Based Location Estimation . . . . . . . . . . . . . . . . . . 21

2.4.1 Model Based . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.4.2 Database Based . . . . . . . . . . . . . . . . . . . . . . . . 23

2.5 Accuracy Enhancement Algorithms . . . . . . . . . . . . . . . . . 23

2.5.1 Bayesian Filter . . . . . . . . . . . . . . . . . . . . . . . . 24

2.5.2 Kalman Filter . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.6 Previous Implementations . . . . . . . . . . . . . . . . . . . . . . 26

2.6.1 Global Positioning System . . . . . . . . . . . . . . . . . . 26

2.6.2 RADAR . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.6.3 DOLPHIN . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

2.6.4 eXspot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

2.7 Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

2.7.1 Source of Inquiry: Mobile vs Access Point . . . . . . . . . 29

2.7.2 Location Estimation Assessment . . . . . . . . . . . . . . . 30

2.7.3 Localization Algorithm Improvement . . . . . . . . . . . . 31

3 System Design 32

3.1 Design Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.2 Experimental Analysis . . . . . . . . . . . . . . . . . . . . . . . . 32

3.2.1 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.2.2 Environment Setup . . . . . . . . . . . . . . . . . . . . . . 33

3.2.3 Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.2.4 Analysis and Results . . . . . . . . . . . . . . . . . . . . . 35

3.3 Mobile Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.3.1 Programming Environment . . . . . . . . . . . . . . . . . 37

3.3.2 RSSI Acquisition Layer . . . . . . . . . . . . . . . . . . . . 39

3.3.3 Communications Layer . . . . . . . . . . . . . . . . . . . . 40

3.3.4 Presentation Layer . . . . . . . . . . . . . . . . . . . . . . 40

3.4 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3.4.1 Operating System . . . . . . . . . . . . . . . . . . . . . . . 41

3.4.2 Location Estimation Layer . . . . . . . . . . . . . . . . . . 41

3.4.3 Algorithm Enhancement . . . . . . . . . . . . . . . . . . . 42

3.4.4 Services Layer . . . . . . . . . . . . . . . . . . . . . . . . . 43

CONTENTS iii

3.4.5 Database Structure . . . . . . . . . . . . . . . . . . . . . . 43

3.5 Access Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

3.6 Design Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4 Implementation 47

4.1 Communication Protocol . . . . . . . . . . . . . . . . . . . . . . . 47

4.1.1 Link Type . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.1.2 Client Programming Environment . . . . . . . . . . . . . . 48

4.1.3 Connection Layer . . . . . . . . . . . . . . . . . . . . . . . 49

4.1.4 Server Programming Environment . . . . . . . . . . . . . . 50

4.2 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

4.2.1 Database . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

4.2.2 Application . . . . . . . . . . . . . . . . . . . . . . . . . . 53

4.3 Mobile Application . . . . . . . . . . . . . . . . . . . . . . . . . . 54

4.3.1 Application Hierarchy . . . . . . . . . . . . . . . . . . . . 55

4.3.2 Map Positioning . . . . . . . . . . . . . . . . . . . . . . . . 55

4.3.3 Location-based O�ers . . . . . . . . . . . . . . . . . . . . . 57

4.3.4 Location-based Search . . . . . . . . . . . . . . . . . . . . 57

4.3.5 Threading Issues . . . . . . . . . . . . . . . . . . . . . . . 58

5 Accomplishments 61

5.1 Meeting with Ericsson . . . . . . . . . . . . . . . . . . . . . . . . 61

5.2 Literature Survey . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

5.3 Experimentation . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

5.4 System Design and Plan . . . . . . . . . . . . . . . . . . . . . . . 62

5.5 Timeline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

5.6 Budget Estimation . . . . . . . . . . . . . . . . . . . . . . . . . . 63

5.6.1 Funding . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

6 Testing and Analysis 65

6.1 RSSI Accuracy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

6.2 Hardware Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

6.3 Zone Area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

CONTENTS 1

6.4 Bluetooth Module Sluggishness . . . . . . . . . . . . . . . . . . . 66

6.5 Scalability Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

6.6 Further Enhancements . . . . . . . . . . . . . . . . . . . . . . . . 68

7 Conclusion 70

7.1 Wrap-up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

7.2 ABET Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

Bibliography 72

Chapter 1

Introduction

Wireless communication technologies have undergone remarkable advances overthe last decade. This re ected directly on the market of mobile devices. Frommobile phones to laptops to personal digital assistants, these devices have beengetting more reliable, more robust, more compact and cheaper each year. Thusthey became more and more attractive and widespread among the public. Fur-thermore, these devices are being equipped with hardware and accessories thatwould increase their functionality. One of the rapidly growing wireless technolo-gies that are being incorporated with mobile devices is the Bluetooth technology.This technology, through its attractive properties, enables the exploitation ofcertain services that would not have been available for a mobile device user oth-erwise. Moreover, location based services, in the �eld of communications, aregaining great interest on the research and development level. The interest theseservices have gained is due to the numerous applications they can accommodatefor.

For example, experts at exhibitions are often faced with the problem of �ndingthe location of participating companies they are interested in. Consumers atshopping malls often have di�culty while looking for speci�c products they wishto buy, especially during their �rst visits. Students at their �rst day of universityhave di�culty in �nding the location of lecture halls and classes. Commercialbusinesses often need to �nd their interested audience to send them ads andpublications. People currently rely on manually searching through printed mapsor asking around to �nd the location of their destination. This way of searchingis time consuming and ine�cient especially when they are tight on time.

This project tackles the problem of location estimation and provides locationbased services to mobile devices to make these services within the reach of thepublic.

1.1. Motivation 3

1.1 Motivation

As he was preparing to depart to AUB for an important midterm, Houssam wasgetting a bit nervous. There were only 45 minutes till the beginning of his exam,and he was still at home. As he turned on his car, the car ashed a warning thatthere was a major car accident on the Salim Slem Tunnel which is on his dailyroute to the university. The accident resulted in a major tra�c jam over there.Luckily, the car was equipped with an embedded computing system that wasprovided with real-time tra�c instances. It also incorporated a map of Lebanon,and the capability of locating the current location of the car. Houssam decidedto take a detour and used the computer to determine an alternative route withthe least tra�c.

Houssam arrived to AUB and headed down to the Bechtel building. There wereonly 10 minutes until the exam starts. As he entered from the periphery gate, hesensed that he had forgotten something important but he could not rememberwhat. As he was about to let go of the whole thing and head down to Wing D, hetook a glance at his mobile phone. It was indicating that he should get semi-logpapers for his midterm. He had set his mobile phone, the night before, to remindhim about the semi-log papers when he passes by the AUB Bookstore.

Houssam got the semi-log papers, rushed down to Wing D, and arrived just ontime. The instructor had just �nished his announcements and was distributingthe exam question papers. Relieved that he got right on time, Houssam tooka seat and began the exam. It was going pretty well with him. Suddenly, theinstructor stood next to him and asked him to put his mobile phone on thedesk. The instructor wanted to make sure that every mobile phone was turnedo� like he said in the announcements. Unfortunately, Houssam did not hear theannouncements so he did not turn his mobile phone o�. Fortunately, the mobilephone has already switched o� automatically. Houssam had set his mobile phoneat the beginning of the semester to automatically switch o� when he enters WingD and to change to the vibrating mode when he enters a class room.

After he aced the test and after leaving Wing D, his mobile phone turned backon. Then, Houssam headed to the computer lab to continue working on his FYPreport.

The morale of this story is not Houssam, his test, or his capability of workingon an FYP report just after he had undergone a head-splitting midterm. Themorale resides in the many real-life problems that can be solved by automationand its integration with location awareness.

4 1. Introduction

1.2 Problem De�nition and Objectives

Many applications nowadays require location based services to ful�ll their in-tended functionality. There already exist localization techniques, such as GPS,that function in outdoor schemes. Yet, these techniques are not suitable for in-door scenarios where the line of sight component of the wireless signal is blocked.We propose to design a system that tackles this problem and provides the indoorlocation based services.

Moreover, since the user's location is not �xed, wired technologies can not beutilized, therefore wireless technologies should be exploited. Among these tech-nologies, Bluetooth appears to be the best candidate because it operates at lowerpower and cost and provides better accuracy. Through location awareness ca-pability, the proposed system provides the user with a service relative to hislocation.

We propose to exploit the available advances of Bluetooth technology to designa solution to the aforementioned problem. The proposed solution targets mobiledevices, that are within the reach of most people, such as mobile phones, personaldigital assistance (PDAs), laptops, tablet PCs.

These devices are presented in a general overview of the intended system inFigure 1.1.

1.3 Document Overview

Chapter 2 describes the theoretical background that covers localization systemsin general, location based services, localization methods, various power basedlocation estimation techniques, accuracy enhancement algorithms, previous im-plementations, and concludes with our recommendations and a general model ofthe system we intend to build.

Chapter 3 describes the design of the system in detail. It covers the mobile device,the server, and the access points. The chapter elaborates on the programmingenvironment that is used on the mobile device and the server, the communicationslayer that represents the connection between the mobile device and the server,the services layer that provides the user with the location based service, and thepresentation layer that presents this information in an organized way.

Chapter 4 covers the accomplishments that we have achieved throughout the ninemonths period of the project. It deals with hardware and software issues of thelocalization method and the application we decided to utilize the localization in.

Chapter 5 talks about the non-implementation speci�c accomplishments of ourproject. It gives a brie�ng about our meetings with Ericsson, the literature survey

1.3. Document Overview 5

Switch

DatabaseServer Bluetooth Access Point

User with Mobile

Bluetooth Access PointBluetooth Access Point

User with Tablet PCUser with Laptop

User with PDA

Figure 1.1: General System Overview

we have conducted, experimentation, and system design and plan. Also, it givesan idea about the work plan that we followed in the spring semester, and thebudget estimation for the components we used.

Chapter 6 gives a detailed demonstration of all the problems, shortcomings andour future remarks about our project. After all, our idea is new. The Bluetoothprotocol, when it was �rst written down, was never intended for localizationissues. This is why our new idea su�ers from some points that are discussed inthis chapter along with our solutions to them. Also, some future suggestions tofurther enhance the localization and the application are dealt with in this chapter.

Chapter 7 concludes this report by tying up loose ends. It shows our contributionin meeting the objectives that we have set in this introduction. It also serves asa summary of the whole document.

Chapter 2

Theoretical Background

This chapter presents a survey of all the technical information that are relevantto the project. This information is crucial in the design and implementationdecisions to be made. Furthermore, this chapter provides an insight to the readerto be able to understand the rationale behind the system design decisions in theupcoming chapters.

Speci�cally, this chapter presents an overview of the communication systems andstandards that are relevant to the topic of localization. Moreover, it talks aboutlocation based services. Furthermore, it discusses the localization methods thatare implemented and presents two models that can be followed in the powerstrength-based localization. It also discusses algorithms that can be applied inorder to improve the accuracy of location estimation. Then, it presents threelocalization systems that have been already implemented. It presents the tech-niques and design decisions they have followed. Finally, it assesses the presenteddesign problems and localization techniques.

2.1 Localization Systems

Various localization systems have already been implemented in the past. Someof these systems, that function in outdoor environments, are based on long rangecommunications and include satellite, cellular, and sensor systems. Other sys-tems, that function in indoor environments, are based on shorter range commu-nications and include WLAN and Bluetooth. These systems are �rst discussedin general, and then they are discussed in the context of location estimation.

2.1. Localization Systems 7

2.1.1 Satellite Systems

The satellite is an earth-orbiting device used for receiving and transmitting sig-nals. Each satellite has a number of transponders which receive the signal andbounce it back to earth, where it is received by any of the dish shaped earthstations, then transmitted via cable, phone lines, or microwave to its �nal re-ceiver. Hundreds of satellites are in Earth's orbit today. The applications theyserve include TV broadcasting, Internet links, atmospheric monitoring, telephonesystems and others. Generally speaking, a day in a modern life without usingsatellites is impossible.

In 1975, the Soviet Union launched the �rst Sputnik satellite, and due to the greatpolitical as well as technological animosity between the Soviet Union and theUnited States back then, Sputnik was closely observed and studied by Americanscientists. One group of scientists in particular led by Dr. Kreshner noticedthat the position of the satellite can be determined with the use of the Dopplerdistortion, and thus using the same concept they concluded that the satellite candetermine one's position on Earth. And thus was the introduction of the globalpositioning system, commonly referred to as GPS.

This system is capable of determining the exact location of any device or structureon Earth or in its orbit with accuracy up to 5 m, moreover using di�erential GPSas well as error-correction techniques an accuracy of 1 cm can be achieved inshort ranges [1].

2.1.2 Cellular Networks

A cellular network is a radio network composed of cells. Each cell is provided witha �xed, stationary transmitter, referred to as a base station. The base stationcan be located in the center of the cell. In this case, it would then be denotedas a cell-centered structure. On the other hand, when the base station is locatedon the edge of three cells, then the cell would be denoted as a three-sectoredstructure. Each cell is assigned to provide coverage to a certain geographicalarea, thus the constellation of cells in the network serve to provide radio coveragefor large geographical areas that a single base station is not capable to serve byits own. Cellular networks provided at the time of their deployment a meansfor better radio coverage, greater number of users, and less power consumptionproperties.

The fact that cellular networks were designed to support multiple users poseda requirement that the base station is capable of receiving radio signals frommultiple users. It also has to di�erentiate the source of transmission of each sig-nal. Thus several multiple access schemes were proposed. Time division multipleaccess (TDMA), where time is divided orthogonally and in the assigned time

8 2. Theoretical Background

slot the user has the whole bandwidth of the channel at his disposal. Frequencydivision multiple access (FDMA) in which the total bandwidth is divided intoorthogonal frequency channels, each of which to be assigned to a user in opera-tion. A more complex and e�cient scheme such as the code division multiplexing(CDMA) is also implemented. CDMA operates such that the whole bandwidth isavailable to a user at any time. The operation of this scheme is based on a codecommon to the mobile and the base station. Thus multiple access is provided incellular networks [2].

In the design of the cellular networks, the networks were designed to ensuregreater capacity than the case with a single transmitter. Thus in contrast withthe single transmitter scenario where a single channel of frequencies is assigned,the cellular network provides each cell with a certain channel frequency. Thesame channel that is used in a given cell for instance can be deployed in anothercell. Thus the reuse of the same channel in di�erent cells is what is known as thechannel reuse. This is one of the most signi�cant features of cellular networks.In TDMA/FDMA scenarios the cells using the same channel frequency shouldbe at least one cell apart. That is, those cells should not be neighboring inorder to avoid interference. For CDMA there is no need to maintain the one cellseparation between two cells using the same channel.

By the deployment of the same channel frequencies in non adjacent cells whileensuring no interference would provide much greater capacity and utility of thefrequencies. In the design of the cellular networks, the cells are supposed to behexagonal in shape in order to ensure the maximum coverage of geographicalareas as a whole. However in practice the cells are not uniform in shape. Theirshapes may vary according to the area where it is deployed [2].

On the practical level, the cellular network notation has been applied to one ofthe cellular networks' most important application which is the mobile phonesnetworks. Thus when the word \cellular" is mentioned, the mobile device iswhat jumps to mind and not the cellular network technology. The mobile phones,especially the modern ones, use cellular networks because of the limited resourcesof power, frequency. Those factors are supported in the cellular networks as statedabove.

The relation between cellular networks and location estimation techniques is inthe fact that the cell where the cellular phone is located is known. This locationinformation is available at the centralized station governing each cell. The local-ization method is discussed in more detail in Section 2.3 which is also applied inother localization systems.


2.1.3 Wireless LAN

A wireless LAN is a data transmission system designed to provide location-independent network access between computing devices by using radio wavesrather than a cable infrastructure. Thus it uses the air or wireless medium fordata transmission (channel) rather than the wired medium.

Wireless LAN is a well known technology. This is partially due to the high dataspeeds it supports. Another important advantage of wireless LAN over wiredLAN that made it so widely deployed in a short time is the exibility it providesto the users. Mobility was something out of the scope even with laptops whenconnection to the network is needed. With wireless LAN, this became possible.Also, it incurs lower overhead when it comes to the complexity of the connectionsand the cost of connecting media. No special equipment is required to attachcomputers together making the user feel all tied up.

The frequency range, on the other hand, is a bit restricting because not allfrequency bands are allowable. That is there are some bands that are totallyrestricted. For example, military communications and some medical (hospital,ambulance) communications are done over restricted frequency bandwidth. Thismeans that no one other than the licensed users can use these channels. Buyinga license for an unallocated channel and using it for some application is veryexpensive. Besides, to make the application international, the same bandwidthhas to be allocated all around the world. This is awkward because it is not easyto �nd the same frequency band free in all the countries where the application isto be installed.

The solution to this problem was to select the free frequency band to run wirelessLAN on. This frequency band is internationally known as free of charge andanyone can use it for aspired applications. The problem that arises here is thatthis channel, being free and readily accessible, is very noisy. It is used for manydi�erent applications at the same time. This is like a group of people all talkingat the simultaneously and never listening to each other. One can imagine thenoise they make.

This is analogously the case in the free bandwidth that wireless LAN uses. One ofthese bands is the famous 2.4 GHz band. This band is home for the most widelyspread wireless LAN. Wireless LAN uses some other frequencies like 900 MHz(the oldest free band standard) and 5.8 GHz. But the 2.4 GHz is also homeof Bluetooth and many other wireless technologies. Thus, the solution to thisproblem lies in the protocol stack of the wireless LAN, speci�cally in the MAC(Data Link) layer [3].

The MAC layer is responsible for detecting all the collisions that happen at thephysical layer (the wireless channel). There is a small di�erence between LANand wireless LAN in the MAC layer. Ordinary LAN (wired) works on simple


collision detection and retransmission of the packet that has collided with someother packet from the same, or maybe di�erent, technology. This is possible inthe wired case because all the nodes (computers) can \hear" each other sincethey are practically all connected to each other by wire.

When the shared medium is the air, there are other problems that may arise dueto the fact that not all the nodes are aware of all the other nodes at the same time.Thus, the MAC layer in the wireless LAN works on collision avoidance rather thancollision detection simply because it can not always detect the collision. This ishow the wireless LAN protocol deals with the noisiness of the channel.

All these decisions, algorithms, and many other details that de�ne the standardsof wireless LAN and how it functions are documented in an o�cial and interna-tional IEEE standard called the IEEE 802.11. Through out the development ofthe technology, this standard has been continuously updated. There are versionsfrom `a' through `g' with 802.11g being the latest and most widely deployed tillnow [3].

WLAN has been previously used in localization applications. It uses the signalstrength that is received at the wireless adapter to determine the distance betweenthe access point and the mobile device. This localization method is discussed inmore details in Section 2.3. Moreover, an implementation of a location estimationsystem that uses WLAN is discussed in Section 2.6.

2.1.4 Bluetooth

Bluetooth wireless technology is a short range, low power, robust communicationsystem intended to operate as a cable replacement between di�erent devices.The objective of the Bluetooth technology was described as a means for unifyingthe communications between devices. This objective was related to the king ofDenmark in the 11th century, Harold Blatand (Danish for Bluetooth) after whomthe technology was named. King Blatand managed to unify Norway, Sweden, andDenmark and thus the analogy between his name \Bluetooth" and the Bluetoothtechnology was formulated. The Bluetooth technology is identi�ed by the logoin Figure 2.1

Bluetooth Speci�cations

The Bluetooth device operates at an ISM unlicensed frequency at 2.4 GHz, thechannels ranges from 2.4 GHz to 2.4835 GHz, the Bluetooth radio uses 79 channelsin this range [4]. The fact that this frequency band is free is an advantage sinceone can operate at this frequency for free without the need for licensing. However,since this frequency is free other technologies operate at this frequency, morespeci�cally the rapidly-growing WLAN technology operates at this band, thus


Figure 2.1: Bluetooth Logo

this would cause an interference. In order to reduce this interference, Bluetoothuses frequency hop spread spectrum (FHSS). A Bluetooth channel is divided intotime slots each 625 �s in length. The devices hop through these time slots making1600 hops per second [4].

One of the signi�cant features of the Bluetooth technology is its low power con-sumption. The classes of power ranges in Bluetooth are classi�ed relative to therange of distances they can accommodate for. Class 1 accommodates for a cover-age distance of up to 100 m and a power of 100 mW, Class 2 accommodates fora coverage distance of around 10m and a power of 2.5 mW, this class is the mostcommon. The third class denoted as Class 3 which is very rare in the marketprovides a coverage distance of 10 cm up to 1 m with a power of 1 mW [4].

Inquiry Procedure

The process that a Bluetooth device should initiate if it is willing to discover anyBluetooth devices in its range, either for the purpose of undergoing a connectionwith them in the future, or only for the sake of discovery is an inquiry procedure.

The inquiry procedure can be classi�ed into three di�erent substates dependingon the intended function of the user. Figure 2.2 illustrates the inquiry procedurebetween a Bluetooth access point and mobile devices.

The inquiry substate is used for the purpose of discovering new devices. Inthis substate the transmitter (master) would continuously transmit an inquirymessage; an inquiry message is composed of an ID packet that represents anidenti�cation of the device. This ID packet consists of the device access code(DAC) or inquiry access code (IAC). The inquiry message is transmitted at thedi�erent hop frequencies (32 frequencies, note that in the inquiry procedure 32of the 79 frequency channels are used) so to ensure that this message reachesdevices operating on those frequencies. In this substate the transmitting devicewould open and read any received frequency hop spread (FHS) packets.Then itwould continue the transmission so the device does not acknowledge any of theresponses it might receive. It just opens and reads them [5].


Mobile devices are initially at the

inquiry scan state.

Access point broadcasts an

inquiry.

Mobile devices become in the inquiry

response state.

Access point receives inquiry

responses.

1

2

Figure 2.2: Bluetooth Inquiry Procedure

The inquiry substate is accessed either if the device is in standby state, that isidle (Bluetooth-wise), or is in a connection with another Bluetooth device. Inthe �rst case, the inquiry takes place normally since the whole capacity is in thedisposal of the device; while in the second case the device should free as muchcapacity as possible before it is able to perform the inquiry [5].

The inquiry substate is terminated through three ways, when a timeout is reachedthat is when the inquiry interval is ful�lled (default inquiry interval is 10.24 ms),when the device decides it has a su�cient number of responses, or through acommand from the user to terminate the inquiry [5].

When the device enters the inquiry substate to scan and discover the neighboringdevices, it would not get any responses if the other devices do not want to bediscovered. If a device (slave) intends to be discovered and wants to scan forany inquiries in its surroundings, it must enter in the inquiry scan substate.The inquiry scan substate like the inquiry substate can be entered either froma standby state or from a connection state. This substate is either terminatedby the user, or by a timeout when the inquiry scan interval is over (default scaninterval is 11.25 ms). The scan should, like the inquiry substate, be able to hop bythe di�erent frequencies to account for inquiries performed at those frequencies.


The scan performed in this substate is of two types, the standard scan in whichthe scan is performed on a single hop frequency basis through the 32 channels.On the other hand, the interlaced scan performs two back to back scans, while theinterlaced scan can produce better results; however it requires the scan interval tobe at least twice the scan window, so it should be twice the original scan intervalin the standard scan scenario [5].

After the device (slave) has been in the inquiry scan substate, it might receivean inquiry message from the device (master). The slave device is not obliged torespond to this inquiry message; its decision is up to the user's desire and hiscon�guration. If the device is to respond to the inquiry message it would be inthe inquiry response substate, again this substate can be entered either from astandby state or from a connection state. In this substate the slave device wouldrespond to the inquiry message with an FHS packet. This includes the device'sBluetooth address which is a 48-bit identi�er unique for each Bluetooth device.The packet also includes other parameters such as the device's name, its class,and its received signal strength identi�er (RSSI) which is the strength or powerof the signal received upon the inquiry. This feature was not present in the earlierversions of Bluetooth and was deployed with the 1.2 version of Bluetooth [5].

Connections Method

The inquiry procedure does not create or require a logical link it, but it consistsonly of the channel access code which is associated with the physical channel.However, the main functionality of Bluetooth is not in the inquiry procedure. It isin the capability of devices to perform a connection with another device, transferdata, and perform a service irrespective of the underlying physical layer [5].

Bluetooth supports two kinds of links: asynchronous connectionless (ACL) linksfor data transmission and synchronous connection oriented (SCO) links for au-dio/voice transmission. The Bluetooth data rate is 1 Mbps while the throughputon an asymmetric ACL link is 721 Kbps in both directions and 57.6 Kbps inthe return direction. A symmetric ACL link allows data rates of 432.6 Kbps.Bluetooth also supports up to three 64 Kbps SCO channels per device. Thesechannels are guaranteed bandwidth for transmission [5].

Communication in Bluetooth networks occurs between a master device and aslave device. The master device is the device that would initiate the communica-tion, and the slave is obviously the device that is communicated with, however itis noted that the master/slave role can be switched after a connection is estab-lished. The basic Bluetooth personal area network (PAN), is comprised of thecommunication link between a master device and a slave device, or slave devices.This basic network is referred to as a piconet. A piconet can hold up to eightdevices, one master device only and up to seven slave devices, and those devices


would share the same channel, and each would be identi�ed in this piconet witha 3-bit identi�er. In order, for a network, to cover a wider range and larger num-ber of devices, multiple piconets are connected as illustrated in Figure 2.3; thisnetwork is referred to as a scatternet [5].

Figure 2.3: Bluetooth Scatternet

Bluetooth Pro�les

In addition to its basic functionality, the Bluetooth stack in the application layerincorporates certain pro�les that provide services and protocols. Those protocolsenable the Bluetooth devices to make use of certain applications and enable theconnectivity with di�erent types of devices that, would be otherwise impossibleto connect with because they operate on a certain pro�le. The pro�les are not bythemselves part of the Bluetooth technology, it is the job of the manufacturingcompanies to incorporate those pro�les in their devices, in order to extend theconnectivity and functionality of their devices. An example basic pro�le is the�le transfer pro�le that enables the transferring of �les between devices, anothernot so basic pro�le would be the LAN access pro�le that serves in enabling theBluetooth device to have LAN communication capabilities [6].


Bluetooth Versions

To date, the Bluetooth speci�cation has passed through four versions: 1.0, 1.1,1.2, and 2.0.

Bluetooth 1.0, 1.0a, 1.0b had many problems; the manufacturers thus su�eredmany di�culties in the communications between their Bluetooth devices.

In version 1.1, most of the problems and errors present in version 1.0 were �xed.Support for non-encrypted channels was provided, moreover a new feature wasadded which is the RSSI, which can be read after the connection between theBluetooth devices is established [5].

The 1.2 version of Bluetooth was backwards compatible with the previous ver-sions, and several enhancements were added to it: It was provided with higherspeeds of transmission in practice, adaptive frequency-hopping spread spectrum(AFH), which improves resistance to radio frequency interference by avoidingusing crowded frequencies in the hopping sequence, extended synchronous con-nections (eSCO), which improves voice quality of audio links by allowing retrans-missions of corrupted packets, access to the timing information for Bluetoothapplications, also a new and important feature in the 1.2 version is the capabilityto read the RSSI upon inquiry [5].

The 2.0 version is backwards compatible with the 1.x versions of Bluetooth. Themain enhancement is the introduction of enhanced data rate (EDR) of 2.1 Mbit/swhich resulted in the following enhancements: 3 times faster transmission speed(up to 10 times in certain scenarios), more bandwidth, thus better performancein the multilink scenarios, an improved bit error rate (BER) performance, andalso less power consumption [5].

Although it is mostly speculation, the next generation of the Bluetooth tech-nology is expected to allow yet faster transmission rates and a much improvedrange. Some even argued that the increased bandwidth and improved data ratemay threaten to make WLAN technology obsolete. Others respond to this ar-gument claiming that the Bluetooth technology would be overtaken by the de-velopment in the WLAN technology. A third more moderate view suggests thatboth technologies, with the constant researching involving them, would keep onprogressing each in a distinct region. While WLAN will be primarily driven byInternet access, the Bluetooth would be more concerned with the phone headsets.Hence both will coexist for di�erent aspects of wireless communications [5].

2.1.5 Sensor Networks

Most sensors are electrical or electronic, although other types exist. A sensor isa type of transducer (energy converter). Sensors are either direct indicating likea speedometer, or are paired with an indicator (perhaps indirectly through an


analog to digital converter, a computer and a display) so that the value sensed be-comes human readable. Aside from other applications, sensors are heavily used inmedicine, industry and robotics. Technical progress allows more and more sensorsto be manufactured with micro electro mechanical systems (MEMS) technology.In most cases this o�ers the potential to reach a much higher sensitivity [7].

Sensors, in their most primitive applications were meant to monitor parametersthat people can not precisely keep track of like the temperature of a patient.Then, they were more and more incurred with monitoring parameters that peo-ple can not monitor at all like the temperature of a volcano. Thus, in recentapplications sensors are acquiring an increasing importance in military applica-tions and in monitoring severe environments. In such scenarios, even placing thesensors in place is a hard or maybe impossible task. This forces the spreading ofsensors (maybe from an aircraft) over a vast �eld. The challenge here is for thesensors to communicate the data through each other to some determined loca-tions. They acquire information about their locations with respect to each otherand to the environment at runtime [8].

Sensors and sensor applications have greatly developed and changed. Lately, lo-cation awareness has been added to the tasks of a sensor. This location awarenessis obtained from the capability of the sensors to sense the other objects aroundthem and thus obtain their location.

2.2 Location Based Services

In the boom of wireless technologies, di�erent services are arising. These includestrictly location dependent services. Such services are diverse and may be in theinterest the customer, provider, and even the government.

2.2.1 Positioning

Customer service is the main goal of many technologies. These technologiesaim at satisfying the customer and meeting all his needs. With the boom ofwireless technology in the last two decades, new services came into the light spot.The omnipresence of mobile phones highlighted the importance of location basedservices [9].

The �rst location based service that comes into mind is the positioning service.This idea was initially tackled on a global scale through the GPS service. A usermight need to know his location. In other scenarios, groups like police, the army,medical sta�, construction engineers and many others might require positioningservices with di�erent accuracy. This made positioning services highly demandedand hence an active and dynamic �eld for research and implementation [10].

2.2. Location Based Services 17

Other needs for positioning include knowing the location on a map. Finding theroad and the shortest path to a destination also needs positioning. In general,knowing one's position is a demanded service. It is the basic service of locationbased services. If any location based service is to be provided to a user, thelocation of the user needs to be �rst identi�ed [11].

2.2.2 Tracking

Tracking is another application that �nds some great demand in many domains.It is needed from a simple civilian handy service to a complicated surveillanceintelligence application. Many applications can use the tracking facility. For ex-ample, �nding lost objects that are equipped with simple transmitters, studyingsome animal species, pursuing a suspect by his mobile phone, conducting surveil-lance by secret intelligence, in addition to monitoring the motion of vehicles andsearch and rescue operations [12].

In all of the above applications, a transmitter device is situated on the device tobe tracked. This device continuously transmits a signal of a certain frequencybandwidth and power characteristics. The tracking system works on receivingthese signals, analyzing them, �ltering them and �nally transform them into aset of coordinated. These coordinated are then handed over to a screen thatdisplays the position of the device in pursuit on a screen map. This way, thetracking team can easily �nd their way to the goal [13].

In intelligence or military applications, the same algorithm works but more so-phisticated means are used to keep track even of the faintest signals. Also, thespeed and accuracy at which the position of the tracked device is displayed onthe screen need to be better. This gives these teams the plus over others bybetter performance of the tracking devices. Finally, the tracking problem is everdeveloping and newer methods like the dynamic track following (DTF) have beenimplemented. DTF makes use of piezo-electric material and high frequency tonesto enhance a video tracking technology [14].

2.2.3 Invoicing

With the emergence and prosperity of position based services arises the issue oflocation based billing. A service provider that has managed to achieve locationbased services need to bill the users of his services according to the locationthey use this service at. Di�erent location dependent billing schemes are neededbecause, for example, accessing a service from a far location is more expensivethan accessing it from a close location [15].

The ability of location based billing is needed in tiered pricing. Tiered pricingis a pricing scheme that provides a lower quality service for a cheaper price.


This means that the service provider should be aware of this user that is usingtiered pricing. Thus, location based billing is a helpful aspect here. Moreover,software de�ned billing is another implementation of location based billing. Inthis scenario, the billing zones are not clearly de�ned by physical connectionsbecause no physical connection can be established in a wireless network. Nor canthe zone be de�ned by by certain nodes because all the nodes in a wireless networkare unstable. The solution is to use software de�ned billing for the geographiczone. The software times the presence of a certain user in each zone it passes in.This means the software should be aware of the location of the user [16].

2.2.4 Reminding

In the crowded day of a busy life, reminders are crucial to keep track of one'stasks. The popular solution that people use to this problem is setting time-triggered reminders on their personal electronic devices. But if the things theywant to remember are related to their passing by certain places and not by time,another approach is needed. If the location can trigger the reminder, this willsolve the problem. One way to have an interactive location is using Bluetooth.Bluetooth is a more probable solution in reminding services because it is a exibletechnology that can be found on di�erent devices [17].

This way, the user sets his mobile, palm or PDA to remind him to do a taskin a certain place. When he passes in the proximity of this place, the remindergets triggered by other Bluetooth devices that are speci�c to that place (by MACaddress). This innovative solution to the reminding problem makes it simpler onthe user to set the reminders and makes the reminders more interactive and notout of place.

2.2.5 Pro�ling

A regular visitor of an exhibition might do numerous things in the exhibition onhis di�erent visits. Interacting with the merchandise and with the representativesat the exhibition gives him an experience that he needs to remember on his nextvisit to build upon it. The pro�ling service saves a log of the cameras and audiodata of the visitors interaction at each stand. They then are associated to themobile device (mobile phone) the visitor carries with him, through the Bluetoothfor example.

On any of the later visits to the exhibition, the user can simply approach thestand he wants to remember something about from last time. The Bluetoothdevice at the stand is triggered by spotting the Bluetooth device of the user in itsproximity. This causes it to load the log of the user and make it available. If theuser requests the information, it is sent to his device by the Bluetooth device on

2.3. Localization Methods 19

the stand and consequently, he can re-access all the experience and any criticalinformation that occurred in it [18].

2.3 Localization Methods

Localization methods involve the interaction between two or more communicatingdevices. Generally, the channel between the devices is wireless, although somelocalization methods can be applied in scenarios where the channel is wired.A communicating device can be either a transmitter or a receiver at a giventime. In all localization methods, a signal is transmitted from the transmitterand propagated through the channel to the receiver. The receiver estimates itslocation based on the arrival of the received signal and its properties. Theseproperties, that vary as the signal propagates through the channel, distinguishone localization method from another. To date, localization methods dependon properties like the received signal's time of arrival, angle of arrival, or itspower. Furthermore, variation of the time of arrival property includes the timedi�erence of arrival of the transmitted signal among multiple receivers. Also,another localization method called cell identity does not depend on the propertiesof the received signal itself yet depends on the identity of the receiver that iswithin the transmitter's range.

2.3.1 Time of Arrival

One way to determine the location of a mobile device is by measuring the timeof arrival (TOA) of the signal knowing the time when it is sent and the speedat which it propagates. The signal's source is represented by a stationary devicewhose location is already known. The localization procedure involves estimatingthe distances between the mobile device and stationary devices. Moreover, everydistance between the mobile and stationary device forms the radius of the circlethat is centered by the stationary device. The location of the mobile device isestimated by the intersection of these circles.

The correspondence between time of arrival and the distance between the mobileand stationary device lies in the fact that distance is directly proportional topropagation time. Speci�cally, the distance that a wireless signal covers is equalto the product of its speed and propagation time. For real world applications, themeasurement accuracy of TOA has a signi�cant e�ect on the accuracy of locationestimation. Knowing that the speed of a wireless signal propagating through airis around 3 �108 m/s, an error in the measured TOA of 1 �s leads to an error inthe distance estimation of around 300 m. This error propagates to the estimatedlocation of the mobile device because it relies on the distances. Therefore, the


use of this localization method depends on the accuracy requirements of the ap-plication as well as the accuracy of the TOA measurement that speci�c hardwareprovides [19].

2.3.2 Time Di�erence of Arrival

Another localization method is the time di�erence of arrival (TDOA). It involvesmultiple stationary receivers that have highly synchronized clocks and collaborateto �nd the location of the signal's source. A signal is transmitted from themobile device to the synchronized receivers. Each receiver saves the time atwhich it receives this signal and communicates it with the other receivers. Thetime di�erence between each two consecutive receivers corresponds to the distancedi�erence between the mobile device and the stationary receivers. These receiversrepresent the foci of a hyperbola on which the mobile device is located.

Location applications require three receivers that represent the foci of six hyper-bolas. More complicated scenarios, where elevation is also accounted for, requirefour receivers that represent the foci of three hyperboloids. The intersection ofthese hyperbolas represents the position of the mobile device. Although these hy-perbolas intersect in theory, in practice they do not intersect due to errors in timemeasurements and synchronization. Therefore, mathematical approximations areapplied to interpolate the location of the mobile device [20].

2.3.3 Angle of Arrival

Another localization method uses the angle of arrival (AOA) of the received signalas an indication of the angle at which the receiver is with respect to the signalsource. Measuring the AOA of the received signal requires a direction awareantenna. This antenna is composed of an array of antenna elements that areable to divide their directivity lobes equivalently among di�erent directions. Theantenna indicates the lobe that has the greatest intensity and hence the angle atwhich the signal is received. It also measures the intensity of the received signalto estimate the distance between the transmitter and receiver.

In this localization method, the mobile device normally plays the role of thetransmitter and the stationary device plays the role of the receiver. This is be-cause widely used mobile devices like mobile phones, personal digital assistants(PDAs), and laptops do not have direction aware antennas. Thus, implementa-tions of this localization method rely on the ability of the stationary device tomeasure the AOA of a signal coming from any mobile device [10].

2.4. Power Based Location Estimation 21

2.3.4 Received Power

Another way to determine location is by measuring the power of the receivedsignal. Because the signal's power attenuates as the signal propagates throughair and the attenuation is proportional to the distance covered, this distance canbe estimated given the power of the received signal. This localization methodrelies on the received power from a number of sources. Therefore, the location ofthe mobile device is estimated from the intersection of the circles that correspondto each source.

Moreover, the accuracy of this method depends on the accuracy of sending thesignal at constant power and and the accuracy of measuring the power at thereceiver. On one hand, any variations in the power at which the signal is sent areunknown at the receiver, and these cause the receiver to faculty consider suchvariations as attenuation with respect to distance. Therefore, applications thatrely on this localization method must have a priori knowledge about the sentsignal's power which is �xed. On the other hand, errors incurred at the receiverwhile measuring the signal's power also contribute to the error of the localizationmethod as a whole [19].

2.3.5 Cell Identity

A rather easy to deploy localization method is implemented by identifying the cellwhere the transmitter resides. Each cell represents an area of the communicationsystem that a central base station covers. It relies on the identity of the receiverrather than the characteristics of the received signal. The mobile device transmitsa signal to stationary receivers in range. The identity of the receiver correspondsto the location of the mobile device. Because this is the only factor in thislocalization method, it doesn't provide accurate location information about themobile device.

Moreover, the cell size in communications systems are usually large and corre-spond to the range that the base station covers. In short range communicationssystems such as wireless local area network (WLAN) and Bluetooth, the lowerbound of the range is 10 m. Therefore, location based services that use shortrange communications systems and need �ne accuracy to within 1 to 2 meters,cannot rely on cell identity as a localization method [19].

2.4 Power Based Location Estimation

There are two approaches in using the received power as a means to estimatelocation. One approach is based on a simple model. The other approach isperformed using a database of previous measurements.


2.4.1 Model Based

One way of location estimation is based on a model that involves a relation be-tween the distance between the transmitter and receiver and the power of thereceived signal. More accurately, the model includes a relation between distance,transmitted and received power, and channel characteristics. In location esti-mation applications, the distance is the unknown that is to be estimated fromthe other known parameters. The transmitted power is usually prede�ned to beconstant to simplify the estimation process, while the received power is measuredat the receiver. The channel characteristics depend on the environment wherethe location estimation application is deployed. The exact relation between thedistance and power depends on the design of the model. Various models existfor various environments. The most general and simplest one is the free spacepathloss model represented by:

log(d) =PTX � PRX +GTX +GRX �X� + 20 log(�)� 20 log(4�)

10n(2.1)

where d is the distance, PTX is the transmitted power in dB, PRX is the receivedpower in dB, GTX is the gain at the transmitter in dB, GRX is the gain at thereceiver in dB, X� is a normal random variable with standard deviation �, � isthe wavelength, and n denotes the e�ect of obstacles and walls.

Although the use of this simple model is fairly straightforward, it does not provideaccurate results. A more appropriate model that provides more accuracy forlocation estimation applications is the empirical model. The empirical modeldepends on the environment where it is used. The design of this model involvestaking measurements of received power and relating them to the correspondingdistances. Furthermore, curve �tting is applied to approximate this relation.

Once this distance is calculated, it is the application's role to use it as it needs. Forinstance, in location estimation applications, this distance is estimated from morethan one source and is used to estimate the location of a mobile device. Usually,the transmitter corresponds to the mobile device and the receiver corresponds tothe stationary device. Therefore, the mobile device transmits signals to variousstationary devices that measure the received power. These measure power valuesare sent and collected at a central server that calculates an estimate of the locationby using techniques such as triangulation.

To wrap up, location estimation based on a simple model requires the choice of themodel that suits the environment. Using a general pathloss model is simple, whileusing an empirical model requires taking and analyzing measurements beforeusing the model but provides better accuracy.

2.5. Accuracy Enhancement Algorithms 23

2.4.2 Database Based

The other way of location estimation is based on saving previously measuredpower values in a database and using it during the operation of the application.Building this database involves taking measurements of received power at speci�clocations, normally at equidistant points. Although at a �xed location, receivedpower is theoretically constant, measured values vary due to slight changes in theenvironment and error in the accuracy of the transmitted and receiver power. Yetthe average of the received power maintains a constant value, so it can be usedas a reference value at the considered location. Received power is measured frommore than one source, usually three, and the average values from each source arecalculated. Besides the average values, the database stores the coordinates of thepoint where the power is measured.

During the operation phase, newly measured values are compared to the valuesin the database. The closest value in the database corresponds to an estimate ofthe location. In order to �nd the closest values in the database that correspondto the values from the di�erent sources, the Euclidean distance is used as follows:

d =p(M1 � S1)2 + (M2 � S2)2 + (M3 � S3)2 (2.2)

where d is the Euclidean distance, M1, M2, andM3 are the measured values fromthe three di�erent sources, and S1, S2, and S3 are the average values that aresaved in the database and that correspond to each source.

The distance d is calculated for each entry in the database and the location is esti-mated such that d is minimized. As a further improvement, instead of calculatingjust the minimum distance, n minimum distances are calculated. Equation (2.2)represents the special case where n is equal to 1. As n increases and more en-tries in the database are considered in the location estimation procedure, resultsbecome more accurate until n reaches a certain limit that is around 5. Beyondthis value, results become less accurate because entries that are far from the truelocation are considered in the estimation as well.

2.5 Accuracy Enhancement Algorithms

This section presents two algorithms to further improve the accuracy of the esti-mated location: the Bayesian �lter and the Kalman �lter. We discuss both thesealgorithms that, if applied to our system, would provide it with more accuracyin its location estimation.


2.5.1 Bayesian Filter

No matter how accurate a localization algorithm is, unfortunately, there is nolocalization device that takes perfect measurements or works well in all situations.Thus, the motivation behind using Bayesian �lters is to try and get better resultsfrom the measured data. Bayesian �lters are named so after Thomas Bayes; anEnglish mathematician that gave a great contribution to stochastic mathematicsin his short life (1702-1761) starting with the well known Bayes' Theorem.

Estimating an object's location is arguably the most fundamental sensing jobin many location aware computing tasks. It is thus a natural domain in whichto illustrate the application of Bayesian �lter algorithm. Representing locationsstatistically enables a uni�ed interface for location information. This lets uswrite applications independent of the devices used; even when using very di�erentdevice types, such as GPS and Bluetooth dongles.

In any location algorithm, some data is measured in a certain form. Every algo-rithm needs di�erent forms of data. The data maybe time, power, images, soundsand many other forms depending on the algorithm used for location estimation.This data is used to determine the position, or at least the best possible estimateof the position of a mobile device. One choice is to use this data, sample bysample to locate the position of a mobile device at consecutive instances in time.

Another trend is to determine the position of the mobile device depending onthe current data and also on the outcome of the previous data. For example, ifwe are tracking the position of a runaway fugitive that is followed by a sensor.Instead of using the sensor data only to get the fugitive's position at each instantin time, one can use the current data coming from the sensor along side withprevious position. The list of old data outcome that can be used to determinethe current position can include previous position, direction of motion (from thelast two points), the rate of motion, the acceleration of motion and so on.

To illustrate, assume that the device's data consists of a sequence of time-indexedobservations y1, y2, . . . yt. The belief, B(xt), is then de�ned by the posteriordensity over the random variable xt conditioned on all data available at time tas follows:

B(xt) = p(xtjy1; y2; : : : ; yt) (2.3)

In simple English, the belief answers the question, \What is the probability thatthe person is at location x if the measurements' history is y1, y2, . . . yt for allpossible locations x?" In general, the complexity of computing such posteriordensities grows exponentially over time, because the number of measurementsincreases over time. Thus, an assumption at this stage simpli�es the growingcomplexity of the calculations.

The key is in assuming that the dynamic system taking measurements is Markov.In probability theory, a stochastic process has the Markov property if the condi-

2.5. Accuracy Enhancement Algorithms 25

tional probability distribution of future states of the process, given the presentstate, depends only upon the current state. In other words, it is conditionally in-dependent of the past states given the present state. A process with the Markovproperty is usually called a Markov process. This assumption simpli�es the cal-culations.

To update the Bayes �lter, the following steps should be followed. Whenever asensor provides a new observation Ot, the �lter predicts the state according to:

B�(xt) =

Zp(xtjxt�1)B(xt�1)dxt�1 (2.4)

where B�(x) is the belief that represents a certain location x knowing the pre-vious location of x before taking the new (latest) measurements acquired by thedevice. All parameters indexed t-1 represent the directly previous version of theparameter.

The �lter then corrects the predicted estimate using the latest device information:

B(xt) = �tp(ytjxt)B�(xt) (2.5)

where �t is a normalizing constant that ensures that the posterior over the entirestate space sums up to one.

The above steps mean that the belief the device is present at a certain locationis calculated at each possible location it can assume. This is done knowing thecurrent location of the device. Then after that, the device information that hasbeen sent from its current location is included in the calculations. This re�nesthe belief function and gives higher probability to the most probable location.Finally, as all probabilities should sum up to one, the belief is multiplied by ascaling factor to ensure this property.

2.5.2 Kalman Filter

The Kalman �lter is a variation of the Bayesian �lter that can be used to improvethe accuracy of localization estimation algorithms. The �lter is named after itsinventor, Rudolf E. Kalman, though Peter Swerling actually developed a similaralgorithm earlier. Stanley Schmidt is generally credited with developing the �rstimplementation of a Kalman �lter. It was during a visit of Kalman to the NASAAmes Research Center that he saw the applicability of his ideas to the problemof trajectory estimation for the Apollo program, leading to its incorporation inthe Apollo navigation computer. The �lter was developed in papers by Swerling(1958), Kalman (1960), and Kalman and Bucy (1961).

It is a recursive data processing algorithm that combines information from dif-ferent sources to produce an estimate of required values [21]. It assumes that


the information sources have a white Gaussian noise distribution. The estimatedvalue is calculated from (2.6) and (2.7):

x̂(t) = z1 + k(t)(z2 � z1) (2.6)

where x̂(t) is the newly estimated value, z1 is the �rst source of information, andz2 is the second source of information, and

k(t) =�2

1(t)

�2

1(t) + �2

2(t)

(2.7)

where �1(t) and �2(t) are the standard deviations of the values coming from the�rst and second sources respectively.

In location estimation systems, the �rst source to the Kalman �lter comes fromthe estimated value of the location that is based on the localization algorithm.The second source is the combination of the previously estimated location andthe velocity of the user.

2.6 Previous Implementations

This section presents an overview of four localization systems that have alreadybeen implemented: GPS, RADAR, DOLPHIN, and eXspot. These systemspresent three di�erent approaches and technologies in their attempt to designa functioning localization system.

2.6.1 Global Positioning System

The GPS is an international localization system that uses satellites to locatecertain devices on Earth. The GPS system is controlled by the United StatesDepartment of Defense, which was responsible for designing it, however it can beused by anyone for free. Obviously a system with such importance and complexityis managed on daily basis; the yearly maintenance cost of the system is up to400 million dollars.

The GPS consists of at least 24 satellites in 6 orbital planes. Each satellite circlesthe Earth twice every day at an altitude of 20,200 km. The satellites carry atomicclocks and constantly broadcast the precise time according to their own clock.

The receiver computes the distance to each of the four satellites from the di�er-ence between local time and the time the satellite signals were sent (this distanceis called a pseudo range). It then decodes the satellites' locations from their ra-dio signals and an internal database. The receiver should now be located at theintersection of four spheres, one around each satellite, with a radius equal to the

2.6. Previous Implementations 27

time delay between the satellite and the receiver multiplied by the speed of theradio signals.

In order to measure the time delay between satellite and receiver, the satellitesends a repeating 1,023 bit long pseudo random sequence; the receiver knowsthe seed of the sequence constructs an identical sequence and shifts it until thetwo sequences match. Di�erent satellites use di�erent sequences, which lets themall broadcast on the same frequencies while still allowing receivers to distinguishbetween satellites. This is an application of Code Division Multiple Access, orCDMA [1].

2.6.2 RADAR

The RADAR system is an RF-based system that performs indoor localizationand tracking. RADAR exploits the capabilities of the wireless local area network(WLAN). WLAN is one of the most widely deployed wireless communicationssystems. The RADAR system makes use of the signal strength (SS) to estimatethe location of the device. SS is included in each packet the WLAN adaptersexchange among each other. It is a parameter of the hardware.

In the design of the system an experimental test bed was constructed. The testbed was in an indoor area of 980 m2. Three base stations were placed for local-ization. The laptop to be localized was Pentium-based running on a MicrosoftWindows 95. The laptop, as well as the three base stations, was equipped with aDigital RoamAboutTM network interface. The SS of each location in the test-bedwere recorded (at least 20 samples of SS were recorded at each location).

After sweeping the whole area and recording the entries in a database came theexperimenting phase in order to determine which localization technique to beused. There were two options: the SS would be measured for each user, andcompared to the entries in the database to determine the corresponding locationrelative to the measured SS. The second option was applying a propagation modelthat relates the distance to the signal power. Thus by knowing the SS, thedistance is simply computed [22].

For the �rst technique the results are obtained for three cases. In the �rst case,the three base stations' measurements are considered. This case is called theempirical method. In the second case, a random base station is considered byitself. This method is denoted as the random method. In the third case, the bestbase station relative to its position with respect to the mobile device is the onlyused. This case is denoted as the strongest BS method. The best results wereobtained from the �rst case, the empirical methods.

Using the propagation model, which is in this case the free-space pathloss model,the results were a bit worse than the empirical method, but much better thanthe random method and the best BS method.


The design decision in this system was settled on this method, which unlike theempirical method did not require the calibration phase. The empirical is moresusceptible to the variation of the environment and the access points. This makesit su�er from a great overhead and in exible.

The accuracy of the RADAR system after its implementation with the propaga-tion model was in the range of 2 m to 3 m [22].

2.6.3 DOLPHIN

The distributed object locating system for physical-space internetworking (DOL-PHIN) system is an ultrasonic indoor localization system that operates in a dis-tributed manner (ad hoc manner). This makes it in need to rely on other pre-con�gured nodes. The system operates on ultrasonic signals but it is possible toimplement it using RF signals in the future. The nodes used in the system haveboth ultrasonic and RF signal transmission and reception capabilities.

The localization algorithm operates as follows. A few number of nodes (a mini-mum of three) need to be con�gured manually before the operation is initiated.As the operation is initiated a node which was pre-con�gured sends an RF signalthat contains its location to the nodes present in the medium. Upon the recep-tion of this signal, those nodes �gure out the position of the pre-con�gured node.They then initiate an internal counter. The pre-con�gured node would then sendan ultrasonic signal to the nodes in the medium. When a node receives theultrasonic signal, it stops its internal counter and recognizes the count time [23].

Now, this node has the time of propagation of the ultrasonic signal throughthe internal count time. It also has the position of the transmitting node fromthe previous RF signal. The speed of transmission of the signal is also known.Then the node can determine its position directly. This is how the node in theenvironment recognizes its position. If this node receives three RF signals fromdi�erent nodes it is capable of determining its 3D location. Note that after anode is aware of its location, it can operate as a reference node that would leadthe other nodes to discovering their positions.

The testing of the DOLPHIN system in an indoor scenario proved to be accu-rate up to 15 cm. These results were achieved with the implementation of theultrasonic signals scenario in the localization method [23].

2.6.4 eXspot

The eXspot implementation was designed to record the experience of visitinga scienti�c exhibition. This exhibition is set up in hard conditions that makescienti�c learning very hard. Learning in these informal educational settings

2.7. Recommendations 29

is unstructured, unsystematic, highly motivating, and often takes place withina family group with multiple competing interests and agendas. The resultinginteraction with any single exhibit is eeting and typically lasts about thirtyseconds in length. An adult in a family group may want to know more about thescienti�c phenomena the exhibit highlights and its history, or may want to interactwith it longer, but is pulled away by children to the next event or exhibit [18].

The �rst implementation of a visitor `remembering' system at the Exploratoriummade use of custom designed `PI stations' which mounted on to a stand a radiofrequency identi�cation RFID reader, an infrared gun and a digital camera. Thesestudies carried out by researchers at HP Labs found that capture was useful andthat majority of users opted to login after their museum visit to their personalallocated web space.

The solution the eXspot suggested to this problem is to provide visitors withsome infrared detectable ID. The registered users can be viewed by an infrareddetector at selected stands that display scienti�c experiments. Along with theinfrared detector, the user gets some web space. When the user approachesan equipped stand, the detector takes note of that along with some personalphotos. After leaving the exhibition, the user can access his own web space thathe previously acquired upon registration. He can also take a further look on allthe scienti�c displays that he passed by. The personal photos that were takenare also accessible [18].

2.7 Recommendations

Following a series of discussion meetings, we arrived at a group of recommenda-tions. These recommendations were the result of logical thinking and some smalltesting environments when needed. The recommendations deal with the sourceof inquiry, database vs pathloss model issue and algorithm improvement.

2.7.1 Source of Inquiry: Mobile vs Access Point

After all the talk that has been presented about the inquiry substate, the re-maining question is where to perform inquiries. We have two choices betweenthe mobile device and the access point. If we choose to do the inquiry on themobile phone, we have to pay attention to some points. A positive thing is thatthe inquiry substates will only be triggered by the mobile device when it wants todiscover its location. The access point would then respond to this inquiry. Themobile device obtains the RSSI reading from this response and the responses ofthe other two access points. The phone sends this data to the server, throughthe access points, where the location estimation takes place. Finally, the server


sends the �nal results, which are coordinates, to the mobile device through theaccess points as well.

In the above scenario, a relatively calm medium is maintained. Doing the inquiryin the mobile device happens only when a localization procedure is needed. Per-forming the inquiry on an access point means that they should keep inquiring asto serve any mobile device that may approach their proximity at any point intime. On the other hand, this incurs less transmission overhead. In other words,the inquiry takes place on the access points and the RSSI values are read directlyon the server. No transmission of the RSSI values should take place from themobile device to the serve. The only transmission is that of the coordinates andit takes place at the end.

This �nal point proves crucial in the time overhead especially in a scenario thatincludes Bluetooth device mobility. Also, getting the RSSI on the mobile devicemeans the variability of the detector and consequently, RSSI inconsistency. Thisand what have proceeded led us to decide inquiring on the access point.

2.7.2 Location Estimation Assessment

In order to assess the location estimation outcome, we studied two ways of deter-mining the location of a mobile device from the RSSI values. These two methodsare the database method and the pathloss model method.

The database based method involves a calibration phase before the incorporationwith the localization algorithm. The calibration phase consists of continuousand consecutive measurements of RSSI values at as much needed points in thelocalization area. At each point, multiple RSSI values are taken and their averageis inserted in a table. Each entry of this table contains the RSSI value and thecorresponding coordinated of each point in the area. A similar table is constructedfor each of the access points. When running the localization algorithm, themeasured RSSI values are cross compared with the pre-constructed database in acertain way. Then the most likely coordinates are returned to the mobile device.

In the pathloss model method, a totally di�erent approach is applied. The mea-sured RSSI values are used to determine the distance that separates the mobiledevice and the corresponding access point. This is done according to a certainpathloss model of choice. The next step is doing a triangulation method basedon the three estimated distances. The simplest method here might be drawingthree circles centered at the access points and of radii the corresponding distancesbetween them and the mobile devices. In a perfect case, the intersection of thesethree circles is the location of the mobile device. Most of the times, the circlesdo not exist and some compensation should be applied.

In a case where the distances derived from the RSSI values are reliable andconsistent, the latter method comes in handy because of the great time overhead

2.7. Recommendations 31

cancellations it allows. If this reliability is not achievable, the former databasebased method is recommended.

2.7.3 Localization Algorithm Improvement

The localization algorithms implemented using the Bluetooth technology are stillin the early stages of development. The location estimation algorithms considerthe average RSSI measurement or the mode as the variable of interest. But thealgorithms overlook other values that can be of signi�cance to the estimation, suchas the standard deviation of the measurements. Moreover, the adaptation of thesystem to support multiple environment pro�les or even multiple mobile pro�les,and to increase the e�ciency and scalability of the system is also overlooked.Support for such features would help improve the performance of the system.

Chapter 3

System Design

3.1 Design Overview

The purpose of the system is to provide location based services to the user whois carrying a mobile device.

The system is composed of clients that access location based services, a centralserver that provides these services, and Bluetooth access points that provide thecommunication link between the clients and the server. The clients are repre-sented by mobile devices that have Bluetooth support such as: mobile phones,PDAs, and laptops. The server is represented by a computer that accesses adatabase containing location and service information. Figure 3.1 represents ageneral overview of the system model.

3.2 Experimental Analysis

The experiment intends to provide us with answers to crucial questions, questionslike: What is the nature of RSSI? Is it of varying nature? What is its level ofsensitivity? How should the laptops (emulating the access points) be placedin the setup? How accurate is the localization with RSSI using the standard,most commonly used, method that uses the mean of the RSSI measurements andcomputes the Euclidean value as a method for location estimation? All of thesequestions and other issues are tackled in this experiment.

3.2.1 Hardware

In the experimental procedure, the mobile device used was the I-MATE PDA2.The access points were emulated by the Dell Inspiron 600m Notebook, with

3.2. Experimental Analysis 33

Switch

DatabaseServer Bluetooth Access Point

User with Mobile

Bluetooth Access PointBluetooth Access Point

Figure 3.1: System Model

Bluetooth 1.2 capabilities as well as Linux operating system. The notebook wasprovided with a program, written in the Python programming language, whichenabled the notebook to obtain the RSSI values at inquiry. Then the programautomatically inputs these values into a database along with the correspondinglocation of the PDA.

3.2.2 Environment Setup

The environment in which the experiment was conducted was a typical indoorscenario. The environment of choice was the Digital Lab of the Faculty of En-gineering and Architecture at AUB. The Digital Lab is 9 m in length, 5.5 min width, and 2.5 m in height. The propagation had a line of sight conditionsbetween the PDA and the proposed access points. However, there is signi�cantmulti-path fading at certain instances because of the presence of the computersall over the sides of the lab.

The lab was divided into a coordinate space; each unit of measurement wasdenoted by three tiles (0.9 m). The access points, emulated by the Inspiron 600mNotebook, were to be placed as shown in Figure 3.2 at position A, position B,

34 3. System Design

and position C.

5.5 m

9 m

2.5 m2.0 m

2.0 m

A B

C

Figure 3.2: Experiment Environment

Since there was only one notebook available we had to move it through the threepositions one after the other, so as to simulate the real-time scenario.

The PDA was placed on a wooden stool, at a height of 1.2 m. The reason forplacing it on the wooden stool is to avoid the body-loss e�ect that would becaused by someone holding the PDA.

3.2.3 Operation

While placing the notebook at each of the three positions the environment wasscanned, through its x-axis and y-axis. At each position the inquiry with RSSIscan was applied for 10 seconds, thus obtaining an average of 20 RSSI measure-ments per position. Once the scan was �nished, we had obtained a databaseof the RSSI measurements at each set of x-y coordinates and for each notebookposition.

Afterwards, three sample measurements were taken. As the PDA was variedthrough three random positions in the lab, its RSSI measurements at each po-sition were measured from the three notebook positions in the same fashion aswas performed in the database construction.

3.2. Experimental Analysis 35

3.2.4 Analysis and Results

After the three sample measurements were obtained, we could now perform acomparison between the RSSI measured at the three positions and their cor-responding values in the database. The mean of the RSSI measurements wereconsidered in the database as well as with the three sample measurements. More-over, we analyzed the performance of the notebook positions, by plotting themean RSSI vs the distance relative to these positions. Figure 3.3, Figure 3.4, andFigure 3.5 represents the plot relative to postions A,positon B, and position Crespectively.

0 1 2 3 4 5 6 7 8 9-76

-74

-72

-70

-68

-66

-64

-62

-60

-58Access Point A

Units of Distance (0.9m)

RS

SI

Measured Data Linear Fitting 7th Degree Fitting

Figure 3.3: RSSI Variation with Respect to Distance at Access Point A

In the process of obtaining the accuracy of the experiment conducted, a C codewas designed that intakes the three sample mean RSSI measurements and iteratesthrough the database. The database would contain the positions along with thecorresponding mean RSSI measurements. The code would compute the Euclideandistance between the sample measurements and the database measurements, andthen the smallest distance is taken corresponding to the estimated location. Theresults obtained demonstrated an average error of 2 m.

The results obtained in the experiment gave us an essential feedback on theperformance of the RSSI. The RSSI measurements obtained turned out to be of a uctuating nature. These measurements varied on an average of 20 units for eachposition, noting that the uctuations increased with the distance. Furthermorethe RSSI measurements were very sensitive to the variations in the environment.Moreover these measurements assured the need for us to develop a new approach

36 3. System Design

0 1 2 3 4 5 6 7 8 9-78

-76

-74

-72

-70

-68

-66

-64

-62

-60


RS

SI

Access Point B

Measured Data Linear Fitting 7th degree Fitting

Figure 3.4: RSSI Variation with Respect to Distance at Access Point B

0 1 2 3 4 5 6 7 8-80

-75

-70

-65

-60

-55

-50


RS

SI

Access Point C

Measured Data Linear Fitting 7th degree Fitting

Figure 3.5: RSSI Variation with Respect to Distance at Access Point C

in the localization algorithm. They also con�rmed design decisions such as thefact that we need three access points in our system. However the results of theexperiment demonstrated in the were not as theoretically expected (especiallyFigure 3.3).

3.3. Mobile Device 37

We proposed possible reasons for that. One of them might be that the environ-ment was not as ideal as proposed, noting the presence of the lab computers andequipment. The WLAN which is operational in the lab operates at the same fre-quency as the Bluetooth technology. The number of measurements taken at eachposition is relatively low, approximately 20 values. Finally, the use of a generalpurpose notebook instead of a dedicated access points is de�nitely a weakness inthe experiment.

These problems and fallacies in the experiment led us to the need of conductinga new experiment in later stages. The new experiment should try to overcomethose weaknesses, so that we would obtain yet better results and thus can makebetter and more de�nite conclusions.

3.3 Mobile Device

Generally speacking, the location of the mobile device is the same as the locationof its user because most mobile devices are hand-held. Moreover, it is throughthis mobile device that the user triggers the service by running the applicationinstalled on his mobile device. This application will force the Bluetooth adapterin the mobile into the inquiry scan substate to be discovered by the access pointswhich are in the inquiry substate, and to respond to these inquiry requests. Thenafter the position of the mobile device is determined, the mobile is updated withthe location information so the user could make use of the presented service.

3.3.1 Programming Environment

From the aforementioned functionality required from the mobile device, it is ap-parent that the programming done on the mobile device constitutes a majorportion of the project. The application of the mobile device should have an ac-cess to the Bluetooth adapter as to control its substates. It should also be ableto receive the location information from the server, and output the service rela-tive to the information received. From here the importance of the programmingenvironment on the mobile device is recognized.

The programming environment is comprised of three entities: the operating sys-tem, the programming language, and the programming libraries.

Operating Systems

Each mobile device is provided with an operating system (OS) that governs itssoftware applications. However, the operating systems for mobile devices vary intheir capabilities and openness. Most mobile devices are provided with operating

38 3. System Design

systems that are exclusive to their manufacturer, and in most cases to theirmodel number. These operating systems do not support aftermarket software,except for Java. Thus they do not provide complicated programming environmentrequirements. Noting these issues, we decided to consider the Symbian OS as apreference for developing our application.

Symbian was initiated as a venture company formed by Nokia, Ericsson, Mo-torola, Matsushita, and Psion. The target of this project was creating an op-erating system that is applicable to various types of mobile devices. The Sym-bian OS is featured by an open standard system for mobile device programming.Moreover, the Symbian OS is equipped with implementations of various commu-nication protocol, and enables their disposal easily in the programs. In additionto that, the Symbian OS has a wide set of APIs across its devices, which enablesthe programmers to develop robust, functional applications. The Symbian OSmainly supports C++ as a programming language. However, many Symbian OSdevices can also be programmed in OPL, Python, Visual Basic, Simkin, and Perltogether with the J2ME and Personal Java avors of Java [24].

Thus Symbian OS generally supports the C++ API. As for Java, Symbian hasbeen provided with support for di�erent Java based APIs. More speci�cally theJava API for Bluetooth Technology (JABWT) has been supported in the laterversions of the Symbian OS, and this is of signi�cance for us [24].

Lately, the Symbian OS has gained wide popularity over its competitors becauseof its programming capabilities as well as its modularity. The modularity enablesquick development over other operating systems. Symbian OS has been incor-porated with Nokia, Sony Ericsson, Motorola, Panasonic, and Samsung mobiledevices.

Programming Languages

Obviously, there are numerous programming languages. However, not all of themprovide support for mobile capabilities. The most commonly used and supportedprogramming environment on mobile devices is Java 2 platform, micro edition(J2ME) [25].

J2ME is a runtime programming language. It is a collection of Java APIs forthe development of software for resource constrained devices such as PDAs, cellphones and other consumer appliances. J2ME has gained so much popularity inmobile applications because of the exibility in the development of the applica-tions that it provides. But what singles J2ME out the most is its universality.J2ME applications can operate on any device as long as this device is providedwith the J2ME virtual machine. Moreover the J2ME application can be executedon any device. So, there is no need for compiling it at the device of operation.This is not applicable for applications developed in di�erent environments. Thus

3.3. Mobile Device 39

J2ME ensures compatibility of operation. In addition to all what has been men-tioned, J2ME provides APIs that are signi�cant to the project. More speci�callythe JABWT, which is de�ned in Java speci�cation request (JSR) 82, is essen-tial for incorporating the programming environment with the Bluetooth stackrequirements [25].

Software Libraries

In this project, the programming environments in general and on the mobiledevice in particular, are not single goal intended. So in addition to the fact thatthey should support libraries that enable the development of applications withfancy graphical user interface, they are required to have an access to the Bluetoothstack. Thus the programming environment to be used should be extended bylibraries that enable such functionality. In the J2ME package, as we mentionedbefore, there is an API which is the JABWT that supports the access of theBluetooth stack [25]. Thus, it provides a control over the Bluetooth technologyon the mobile device. On the other hand C++ also includes such a library thatsupports Bluetooth, which is the Bluez library [26].

From what has been mentioned above, the mobile device to be used in the pro-posed system is preferred to run the Symbian OS that supports J2ME. J2ME isgoing to be the programming environment of choice because of its wide range ofcapabilities including its support for the JABWT API.

3.3.2 RSSI Acquisition Layer

The RSSI acquisition layer represents the capability of obtaining the RSSI fromthe received packet. Although in our design we propose that the RSSI acquisitionlayer is on the access points and not on the mobile device, we discuss the RSSIacquisition layer on the mobile device as an alternative design decision.

As previously mentioned in our system the mobile device makes use of theJABWT API of the J2ME environment. Thus it has access to the Bluetoothstack of the mobile device. So, when a device inquires for Bluetooth devices, andreceives an inquiry response, the FHS packet received can be accessed throughthe JABWT API and the value of RSSI is read. Note that this feature also has todo with the Bluetooth version through which the RSSI is read. If the version wasnot 1.2 or any later version, then this feature is not enabled. Another applicationof this layer is its capability to obtain the RSSI values when the mobile is in theconnection state. The corresponding RSSI value, in this case, is also accessedthrough the JABWT.

40 3. System Design

3.3.3 Communications Layer

The mobile communication is wireless, thus it is either through infrared, Blue-tooth, or WLAN. In our case, the wireless technology in use is the Bluetooth.Thus the communication layer, between this mobile device and the access pointsis governed by the Bluetooth technology and consequently is a personal area net-work (PAN). The link between the mobile device and the access points follows thecommunication methodology cotrolled by the Piconet structure where the mobiledevice is a slave device. This is because it is in the inquiry scan mode. On theother hand, the access point is the master device. The Bluetooth communicationis discussed in Section 2.1.

3.3.4 Presentation Layer

The service is obviously pointless if it can not be presented to the client oruser. In the project, the service is applied to the mobile device as a means ofpresenting of this service. Noting this, the user willing to receive the locationbased service should be provided with an application on his mobile phone. Thisapplication permits the user to request this service and be able to exploit itsfeatures. Moreover, for the application to be user friendly, it should be providedwith a well designed graphical interface. Through this graphical interface, theuser is able to trigger the application, access the di�erent features of the service,as well as control the settings of the application. The application is also providedwith a help menu that helps the users exploit the capabilities of the applicationand thus the service. However, the most important feature of the application isits interfaces portrayal of the service. For example, for the map tracking scenario,the graphical user interface of the application would have the function of in takingthe location information it receives through its PAN, as well as the topology of theenvironment, and then output the users location on the map of the environment.

3.4 Server

The server is the most integral part in the design. A bundle of substantial tasksare assigned to it. The tasks include controlling the access points by invokingthem to inquire when needed, keeping track of the incming RSSI readings andtheir source, applying the localization algorithm on the read RSSI values, andsending the calculated coordinates back to the speci�c mobile device. As clearlypresented, the server is the central controller of the whole system. The accesspoints act as its extended arms through whcih it senses the RSSI readings.

In the demostration phase of implementing our project, the server does not haveto be a full- eged one with super computing powers. An ordinary computer that

3.4. Server 41

has full control of the access points is su�cient. On the other hand, for scalabilityissues, the server should be capable of serving all the mobile devices present inthe setup the system is running in. Failing to serve all the mobile devices in acertain scenario should be totally avoided. Thus the capabilities of the requiredserver change with the type on the environmental setup.

3.4.1 Operating System

When it comes to the OS, the servers have a wider horizon than the mobiledevices. There are several kinds of operating systems. All of these OS's canbe divided into two main categories. The OSs either directly belong to thesecategories or are variants or combinations of them both.

Command line interface (CLI) OSs such as DOS, use only the keyboard for in-put. Modern OS's use a mouse for input with a graphical user interface (GUI)sometimes implemented as a shell over a CLI. The most generic sense of theterm shell means any program that users use to type commands. It is called ashell because it hides the details of the underlying operating system behind theshell's interface. The appropriate OS may depend on the hardware architecture,speci�cally the CPU. Since the early 1990's the choice for personal computers hasbeen largely limited to the Microsoft Windows family and the Unix-like family,of which Linux is becoming the major representative. Mainframe computers andembedded systems use a variety of di�erent operating systems, many with nodirect connection to Windows or Unix, but typically more similar to Unix thanWindows.

What concerns us from these operating systems are the ibraries and applicationprogram interfaces (API) that are operating system dependant. So far, all oursearches, contacts and knowledge have lead us to Linux based libraries. Bluez,PyBluez, JABWT are examples of full edged libraries that we have been pro-vided with through out contaces. They are all open source but unfortunatelysome of them are undocumented. Bluez mainly involves programing in C, Py-Bluez is the Python version of Bluez and JABWT is Java APIs for BluetoothWireless Technology. All of these libraries and APIs are open source and aimedat Linux operating systems. This is why our choice has fell on a Linux operatinsystem. We chose the Fedora Core 4.

3.4.2 Location Estimation Layer

This layer is the part of the system that lies in the shade. It is, as the commun-ciations people call it, the hidden backbone. Through it or on it everything runs,yet, it is hidden from the users that bene�t from it. On it, the application layerwill smoothly �t and run all sorts of location based services.

42 3. System Design

In this layer the position estimation, through the coordinates of the mobile device,takes place. As a starter, it runs on the server. It uses the measured RSSIvalues and applies the algorithm to them. The output of this process will be theestimated coordinates of the mobile device. The next step, which involves thesecoordinates, depends on the location based service that is running.

The estimation algorithm that runs in this layer will include a Kalman �lter. Ascan be clearly seen in Figure 3.3, Figure 3.4 and Figure 3.5, the blue stars thatrepresent the acquired RSSI readings vs distance do not demonstrate a clear ow.It is true though that this irregularity in the RSSI performance may be blamedon many wrong factors in the experimentation environment as will be cited inChapter 4. But still, these kinds of vibrating distortions can best be treated mya Kalman �lter.

3.4.3 Algorithm Enhancement

Due to the fact that indoor localization using the Bluetooth technology has notbeen suggested till lately, the systems developed have not yet reached the full po-tential of this technology in terms of accuracy and e�ciency. Thus in our projectwe intend to provide design enhancements that would contribute to the indoorlocalization using Bluetooth research and implementation domains. Althoughthis aspect of design had not been covered in the �rst phase of this project, weintend to cover it in the upcoming phases. Possible algorithm enhancements mayinclude on of the following points.

Second Moment

Apart from Kalamn �ltering, one can apply other enhancements to narrow downthe error margin. An interesting suggestion that we have arrived at is taking thevariance of the measured data into account. It may be in the calibration phase, ifwe give in to a database based implementation, or in the data acquisition phase, inboth implementaions. In either scenario, taking advantage of the second momentof the is a good idea since the data is already there. The average is the �rstmoment of the data. The variance of the measured RSSI gives us informationabout the dispertion of the data and how far it is from the mean. This informationmay prove crucial regarding the presence of obstacles that block the line of sightcomponent of the wave. In other words, from the dispertion of the data, we cantell if there is an obstacle. Knowing the topology of the room, this can help usin the localization process.

3.4. Server 43

Environment Pro�les

A problem in the design of indoor localization algorithms is that they assume, inthe design process, a perfect scenario or a single scenario. However an applicationthat is supposed to run in real-life conditions should account for di�erent scenar-ios. Otherwise, the results in wrongly assumed scenarios will be false. So wepropose the to provide multiple pro�les in the estimation of the distance. Eachpro�le would account for a di�erent scenario. For instance, pro�le A could sup-port a large number of people, pro�le B could support a small number of peopleand so on. The pro�le switching will be either manual and done by an adminis-trator, or automated and peformed by the server. This will help increasing thee�ciency of the algorithm.

Bluetooth Pro�les

In addition to the support of multiple pro�les of the environments, another en-hancement we propose for implementation is the support of multiple pro�les ofmobile devices. This is due to the fact that mobile devices, of di�erent powerclasses of Bluetooth, provide di�erent range of RSSI readings. Thus a designthat supports a class 2 Bluetooth adapter may not be as accurate as a class 1Bluetooth adapter. Consequently, we propose the support for multiple pro�lesfor the mobile devices for better performance.

3.4.4 Services Layer

The purpose of the services layer is to provide information services such as maptopologies, land marks, reminder messages, invoices, and history logs. Di�erenetexamples of location base services have been thoroughly discussed in Section 2.2.As much as they are diverse, they all depend on the location of the mobile devicethat is usually carried by a user.

After running the algorithm and a combination of the suggestes enhancements,the server can then use the estimated coordinates to apply any of the aforemen-tioned mentioned services. In some applications, the proximity is enough in itself.There is no need for the coordinates. These services include history logs, and re-minders. Some other services need coordinates, and myabe precise and reliableones. These applications include map topologies and land marks.

3.4.5 Database Structure

The server should include one more functionality. It should have a database thatincludes two kinds of information. These kinds are to support location estimation

44 3. System Design

information and location services information. The Location estimation informa-tion contains tables that map coordinate sets to RSSI values. This is speci�c toa database based implementation. The location services database contains infor-mation about the maps, history logs, land marks, invoicing details and the sort.The server should manage both kinds of databases e�ciently so that the overallsystem runs well and without annoying delays.

3.5 Access Points

Every access point should be programmed to deal with server in many functions.It should inquire at a speci�ed rate that might be changed from the server ac-cording to a certain parameter. It should keep the server informed of all of theseparametes because it is its extended arm as speci�ed earlier.

As for the number of these access points that should be used, we have made along discussion on the feasibility of using each number of them. If we are to use asingle access point, that might seem to be a nice and less costy choice on the �rstglance. But as Figure 3.6 shows, all points that are on a circle centered at theaccess point will have the same RSSI value. This makes the location of a mobiledevice with a single access point practically impossible.

Figure 3.6: 1 Access Point

Even when we place the access point just beside a wall of the medium we wantto cover as Figure 3.6 shows, we have only elimnated have of the region which isa circle. The other semi-circle determines a whole region and not a �xed solution

3.5. Access Points 45

of the location of the mobile device, thus we decided to eliminate this choice fromour set of solutions.

Then we moved to the possibility of using two access points. Two access pointsmeans two circles each centered at one of the access points for each device in themedium. But two circles usually intersect in two points as it is clearly illustratedin Figure 3.7. This is still a problem because we have either one of two equiprob-able positions for each mobile device. Then we though of eliminating one of thesesolutions by moving the access point to the one of the boundaries of the room asshown in Figure 3.7. Still, one has to pay special attention that the whole arealies in �eld of the access point.

Figure 3.7: 2 Access Points

This seems �ne, but this solution is not scalable. If the system is to be scaledfor a big room that cannot be covered by the limited range of the Bluetooth,the proposed con�guration of Figure 3.7 fails. Thus we moved on to the scalablethree access points solution.

In the three access points approach, for evey device, one can draw three circlescentered at each access point. Here, the problem of singling out the correctposition is solved. Figure 3.8 shows how in an ideal scenario all three circlesintersect in a single point.

Yet, it is not always perfect case like Figure 3.8 shows. In many of the cases, smallerrors on the radii of the circles will cause them to intersect in three points. Still,many estimation solutions can be done for these cases. What is surely gainedhere is the scalability of the system.

46 3. System Design

Figure 3.8: 3 Access Points

3.6 Design Summary

In the design of this location based application, the software pieces are dividedinto seperate layers. The reason for the seperation of the layers is to accountfor portability of the application among mobile devices. This seperation formsa set of independant layers whose implementation can change without a�ectingthe overall functionality of the system. This is achieved by designing a protocolthrough which these layers can communicate. By following the speci�cations ofthis protocol, these layers can interact correctly irrespective of the underlyingimplementation of each. Speci�cally, the implementation of logic layers such aslocation estimation and services remain the same for all di�erent devices becauseit is independant on the hardware resources. On the other hand, the implementa-tion of other layers such as RSSI acquisition, presentation, and communicationsdepends on hardware resources such as the Bluetooth controller interface andversion and graphics chipset, and thus varies among di�erenct devices.

Since we are at an early stage of the system design, we need an experimentalsetup that would help us get a avor of the real-time operating scenario. We alsointend to acquire the ability to decide on crucial design decisions.

Chapter 4

Implementation

In this chapter, the bulk of the project work is discussed. This work was mainlydone in the spring semester. There were many hidden issues and obstructionsthat we never saw until we went deep in the implementation phase. These, alongwith many other implementation issues are discussed in the upcoming sections.

4.1 Communication Protocol

The communication protocol is the main bridge of our application. It is thebridge that connects the mobile device to the server and manages the interactionbetween them. Many ideas were discussed on how this bridge should be built;simplex, duplex, full-duplex? The temptation is always to build the best, in otherwords to go for the full-duplex idea. But the designer ought to keep in mind theend goal of the application and optimize the tools to achieve this aim.

4.1.1 Link Type

In the case of localization, no matter what the application is, its basic idea is alocation estimation that will be used to apply more options on it. Thus, if thephone has full knowledge of the elements present in the exhibition, it needs nottell anything to the server. It only needs to receive the location (coordinates) fromthe server. This coordinates that the server has calculated depending on someRSSI readings that are client independent. They only depend on the inquiry fromthe server and the database that has been previously constructed in the setupphase.

If the above points are wrapped up, we arrive to the need of simplex connectionthat transmits the data in a single direction from the server to the client. Thisdata is the coordinates that have been calculated and interpolated by the server.

48 4. Implementation

In our application development, we spent sometime on the connection and arrivedon duplex and full-duplex connections. The code details of which are present inthe �nal submission. But as a good design practice, we ruled out whatever is notneeded and crucial to our application. This way, we only kept on relevant toolsthus reducing any unnecessary overhead or complications.

4.1.2 Client Programming Environment

After deciding on the characteristics of the connection, it was time to build itnow, for this we needed to program the mobile device, which in our case is a SonyEricsson P910 mobile phone / PDA. Mobile phones are generally programmable intwo ways. The �rst one is the J2ME (Java 2 Micro Edition) way which is commonto all mobile devices that have a JVM (Java Virtual Machine) integrated into theirOS (Operating System). The second method, which is simply C programming, isspeci�c to those mobile phones that support the Symbian OS. Luckily, the P910has a Symbian OS. Using C is much easier especially when dealing with hardwareprogramming such as programming for the mobile device's Bluetooth module asin our case.

But, to be able to write a program in C for the mobile device, we need to have acompiler that compiles for the ISA (Instruction Set Architecture) of the processorthe P910 has integrated on chip. Here, the advantage of using J2ME becameclearer for us. In addition to this, when programming using J2ME, we do notneed to move the whole code to the mobile phone to test it because of the presenceof the so called "emulators". Each big mobile device fabricating company likeSony Ericsson, Nokia, and Motorola etc provides this software emulator thatemulates the mobile phone with all its keys and functionalities on the screenof the computer. Thus, the software can be totally written and tested on thecomputer before being moved to the mobile phone at the end.

Unfortunately, this is not present for the C language. So, if we are successfuland we �nd the compiler that compiles for the ISA of the P910 processor, wewill not be able to test the software except on the target, the phone itself. Thiswould increase the time overhead signi�cantly and impede our development inthe project.

On the other hand, if the mobile device has a JVM, this problem is totally solved.The JVM is a middle software layer that functions as follows. It takes the codewritten and saved in a JAR (Java Archive) �le and translates it into a code thatfollows the ISA of the hardware it is sitting on. The format of the JAR �les isinternationally unique, and the compiler (and the wireless tool kit I was using)automatically produces the JAR �le upon compilation. This is why our choicefell on using the J2ME and not good old C.

Finally, we had to do the hands-on job and write the code for a connection class

4.1. Communication Protocol 49

that will handle all the basics we decided on above. For this we had to �nd a goodsource of fast learning of how to write programs that uses the Bluetooth protocolsand fast. In this, the book entitled "Bluetooth for Java" came in handy and wasof a great help for us [27]. It contained all the necessary bits and pieces in anorganized fashion. As a fast introduction, and to verify that we are writing correctcode to the Bluetooth module, we wrote a small code that inquires the currentmedium for ten seconds, �nd all the other present Bluetooth enabled devices anddisplays their MAC addresses and their friendly names on the screen.

4.1.3 Connection Layer

After the success of the veri�cation step, we moved on to creating the �nal con-nection code that we can use in our end application. Soon enough, we discoveredthat a Bluetooth connection can be done on two separate layers of the Bluetoothprotocol stack. Below, you can see the complete Bluetooth protocol stack:

Figure 4.1: Bluetooth Protocol Stack

The two layers that we can write out connection code to turned out to be theRFCOMM layer. Its connection protocol is called "btspp" (Bluetooth Serial


Port Pro�le). This layer provides the ordinary connections for all the Bluetoothapplications we know of. From the simple ftp (File Transfer Protocol) that wenearly daily do to the complex OBEX or voice over Bluetooth applications. Thislayer provides security and high encoding. In our case, this security that needspairing and authorization introduces an unnecessary overhead that we can domuch better without. Also, the advanced encoding scheme this layer providesmakes the time to establish a connection relatively long. This is also a setbackfor our application.

Reading further into JSR82, we found a way around this problem. In the �gureabove, there is a layer directly below the RFCOMM layer called the L2CAPlayer. This layer is also supported in the JSR82, i.e. it can be used to establisha connection. The tools to establish a Bluetooth L2CAP connection is presentin the J2ME libraries. The connection protocol of this layer is also called l2cap(Logical Link Control and Adaptation Protocol). The good points about thislayer are that it provides a fast connection (low encoding), it needs no pairing,and it uses the MAC address as the target of the connection. The RFCOMMlayer searches for the connection URL on each Bluetooth device it �nds and thusit needs more time to establish the connection.

4.1.4 Server Programming Environment

For a week, we tried to establish the relevant Bluetooth libraries for the J2SE.Many di�culties were faced, but we were getting closer. Then, after a meeting,we decided to make all the code on the Linux-running server written in C. Thiswas one of the best decisions that we should have made earlier. The fact that wehave chosen J2ME for the mobile device is because it had some pluses over C.But when it came to the server, we seemed to take J2ME by default and forgotto rethink it in the same constructive manner as we did for the mobile phone.Certainly, C beats Java because the only big set back for C when we were dealingwith the mobile phone was compiling to a di�erent ISA than the one it is runningon. On the server side, we are working on an x86 ISA and also compiling for it.

Now that we have both the server side and the client side settled tools-wise, itwas time to write down a code that establishes a connection between one of theBluetooth dongles and the mobile phone, transmits data from the server to thephone, and then closes the connection. After another week of programming andtesting, this end results was achieved.

Finally, we arrived at creating a robust communication protocol where a stringthat contains the coordinated needed by the application is transmitted from theserver to the mobile phone over a Bluetooth L2CAP connection. The code thatdoes this was put in a wrapper class called "Connection.java". For more infor-mation about the code, see enclosed documentation.

4.2. Server 51

4.2 Server

The work on the server is partitioned into two parts: building the database andthen running the application that uses this database. More than one databasecan be build according to the requirements of the application. Furthermore,the application is designed to be generic and scalable by setting options thatcorrespond to di�erent environments and hardware used.

4.2.1 Database

Before the application runs, it has to build a database that it relies on to performlocation estimation. The place in which the application is deployed is dividedinto a number of squares represented by X and Y coordinates. RSSI valuesare measured on each coordinate pair and the values are stored in the databasealong with the coordinates. Moreover, more than one database is built and eachcorresponds to a speci�c type of Bluetooth devices.

A Generic Approach

This database is designed to take command line options upon starting to setgeneric variables that depend on the environment in which the database is builtand the hardware used. These command line options include the following:

� Access point device number: Every access point is identi�ed internally inthe server by a device number. This device number is assigned by the serverupon its connection with the access point.

� MAC address of the mobile device: Every mobile device has its correspond-ing range of RSSI values. Therefore it is required to identify the devicewhose values are stored in the database to distinguish among various de-vicee types and classes.

� Number of RSSI measurements: The number of RSSI measurements thatare collected and averaged in the database.

� X and Y coordinates: The number (limit) of X and Y coordinates fromwhich the RSSI values will be measured.

Access Points Initialization

The �rst step in building the database is initializing the Bluetooth access pointsand opening them in order to be able to receive from them RSSI values. This


involves creating an HCI socket for each Bluetooth access point and setting itsoptions in order to be able to read data direction information and time stamp.Moreover, a �lter is also set on this socket so that only requested data is read.After setting up these options and �lter, each socket is bound to the MAC addressof the corresponding Bluetooth access points in order to be able to communicatewith that access point. Finally, after establishing a way of communication witheach access point, an HCI command is sent to them to read the inquiry mode.The inquiry mode as speci�ed by the Bluetooth speci�cation could be either\Inquiry with RSSI" or \Normal Inquiry without RSSI". Therefore, if it is notalready set to \Inquiry with RSSI", another HCI command is sent to the accesspoint to set it accordingly. This change a�ects all communication going throughthis access point independent of the source and destination of the transmitteddata.

Database Initialization

The database is represented by a simple API that provides the capability to readand write data. The smallest element of communication with the database iscomposed of a set of RSSI values and a pair of coordinates (x and y). EachRSSI value correspond to the Bluetooth access point from which the RSSI valueis read. Moreover, because every mobile device has its corresponding range ofRSSI values, there are databases corresponding to each device. The appropriatedatabase is selected through this initialization phase.

Coordinates Management

While building the database the system asks the user to stand at speci�c coor-dinates and it will then read RSSI measurements from that location. To make iteasy for the user, the order in which the system speci�es the coordinates is suchthat the user only moves one step. Therefore, starting with the origin (0,0), thesystem increases X until it reaches the limit of X (X,0). It then increments Y byone and starts decreasing X back from (X,1) to (0,1). Similarly Y is incrementedand X is increased again and the whole process repeates until the limit of Y isreached and all the points are covered until the last point (X,Y).

RSSI Measurement

At each point, a number of RSSI measurements are collected for each accesspoint. The result is then averaged and put in the database as a collection of 3RSSI values corresponding to the 3 access points and 2 coordinate pairs: X andY.

4.2. Server 53

Moreover, reading RSSI values works by sending an \Inquiry with RSSI Request"to the access points and then waiting for replies. The system reads the repliesand identi�es their type from their headers. If the reply is an inquiry responsewith RSSI value it records the RSSI value. Otherwise if the type of the reply isan error message, it ignores it. Finally, if the reply is an information messagethat says the inquiry process is �nished, the system knows that there are no moreRSSI measurements to record. Therefore it checks if it has recorded enough mea-surements relative to the required number of RSSI values per location speci�edby the user. If the values are not enough, it repeats the process again until therequired number of measurements is met. After that, any remaining replies thathave not been processed are removed from the queue of replies to leave roomfor the new measurements that correspond to the new location speci�ed by thesystem.

4.2.2 Application

The application's purpose is to search for Bluetooth devices and tell them theirlocation. These devices are reached through the access points that are always inan inquiry state searching for Bluetooth devices in their range. Once a deviceresponds to the inquiry scan, the RSSI value of the signal it sends is measuredand recorded. The RSSI values corresponding to this mobile device and comingfrom all access points are collected and compared to the values in the databaseto �nd the closest match. Once the location is estimated, the server opens aconnection with the mobile device and sends it its coordinate values.

A Generic Approach

This application is also designed to take command line options upon starting toset generic variables that depend on the environment in which the applicationis running and the hardware used. These command line options include thefollowing:

� Access point device number: This is similar to the device number in thedatabase. The relation between the two is that in the application the devicenumber is used to get the RSSI measurement to be compared with thecorresponding value in the database that came from the access point withthe same device number.

� Number of RSSI measurements: The number of RSSI measurements thatare collected and averaged at run time to be compared to the values in thedatabase.


Access Points Initialization

This phase is also done while running the application in the initialization phase.This includes opening HCI socket connections, applying �lters, setting options,binding the sockets to the access points, and �nally making sure that the inquirymode is set to \Inquiry with RSSI".

RSSI Measurement

The server continuously performs \Inquiry with RSSI" from each access pointand reads the corresponding replies to get RSSI measurements. It also identi�esthe mobile device that is responding to the inquiry request by extracting its MACaddress from the header of the reply. So it collects a number of RSSI measure-ments from each access point, averages them, and compares them to the valuesin the database respectively. The closest match is selected and the correspondingcoordinates indicate an estimate of the location of the mobile device. Finally,after estimating the location of the device, the server builds an L2CAP socketthat represents its connection to the mobile device and connects to the devicethrough its MAC address. The connection is made through any access point thatis ready to establish the connection. The server sends the X and Y coordinatepair conforming to the designed protocol as discussed in Section 4.1. In the meantime, the corresponding access point will no longer be able to perform inquiriesbut this will only take a few milli seconds. On the other hand, the other accesspoints will still be able to perform inquiries and collect RSSI values. Finally theserver closes this L2CAP connection with the mobile device, resumes the inquiryprocedure, and the whole process repeats.

4.3 Mobile Application

The phone application, named BLEMA (an abbreviation for Bluetooth LocationEstimation Mobile Application) is a Java compiled archive (or a JAR �le) con-taining all the services implemented for the project. The program is designedaround one central API class which handles the Bluetooth connectivity for theother components of the program. The remainder of the program manages theforms and options which are visible to the user; each form handled using methodswithin its own class.

The implemented services selected for demonstration purposes reveal the basicusages of the localization application. However, note that extra services whichinterface with the user can be easily developed. Thus the application is bothextensible and adaptable.

4.3. Mobile Application 55

The services which we have chosen to include in our application to provide a goodexample of the types of services possible with our system are:

� Basic Map positioning;

� Location-based o�ers;

� Location-based search mechanism

All these services as well as any extended services are highly dependent on theBLEMA server application running on the server machine. This section providesan overview of the phone application development process; the functionality em-bedded in the application will be thoroughly examined.

As mentioned in an earlier stage of the report, the programming language ofchoice for the implementation of these services is J2ME. The main reason forthis choice is the portability and adaptability of J2ME applications to all Java-enabled mobile devices, as well as the exibility they permit in the design ofuser-interface applications.

4.3.1 Application Hierarchy

The application begins with a welcome screen that displays the logo of the ap-plication. The welcome screen would be displayed before moving on to the mainscreen upon a button click. The main screen of our application presents the basicfunctionality of the program, which is the map. This screen thus displays themap of the topology with the position of the user with respect to this topology.Figure mainscreen shows the main screen of the application. This screen alsoinstructs the user to choose one of the aforementioned services. The outline ofthe states that the application presumes is illustrated in �gure states. Note thatfrom here on the next screen loaded is dependant on the users choice.

4.3.2 Map Positioning

The straight-forward service for localization applications is a dynamic map. Thusin the application a map of the topology in which the service would be running isdisplayed on the mobile device. The map is a 2-Dimensional, top view portrait ofthe topology. On this map, the position of the user is visualized and is constantlyupdated, as the user moves around.

The map is implemented with the extension of the Canvas class in the Java Mi-croedition Environment [28]. The Canvas class allows the exploitation of the


paint() method, this method which allows us to manipulate the graphical inter-face, which is very demanding for a pure visual service such as the map. The mapcould be 3-Dimensional but for simplicity purposes we provide the 2-Dimensionalmap which satis�es the positioning requirements. As for the actual position-ing, a star on the map would characterize the users position. This position(x-coordinates and y-coordinates), which is provided by the server, is translateddynamically on the map. And a signi�cant feature in this service is the appli-cations ability to update the position of the user constantly, so as soon as theserver is aware of an update in the users position, it sends the new coordinatesto the mobile device, which intakes them and displays them directly on the map.Again the update of the map is done using the extended capabilities of the canvasclass which has a built-in method which is the repaint(), this method as its namesuggests allows the repaint of the map at each update, and this repaint is donevery e�ciently and quickly.

Being the most basic service in our application, the map is set as the main screen,and from this screen the user has the choice of either exploiting this service byitself or moving on to other services and functionalities of the application. Notethat if accessed in the o�ine mode the users location would be set to the origin,which is the upper left corner of the map.

Figure 4.2: Phone Screen


4.3.3 Location-based O�ers

A service that exploits the capabilities of localization is advertisements; supposea stand in a mall or a fair wants to announce that it has a discount on mobiledevices for instance, but it only intends to inform nearby users. This service isimplemented in our application, thus users are informed of any o�ers or adver-tisements presented by a nearby stand. Actually this service is divided into twoparts: on one hand the user can from the main menu choose to go to the O�ersscreen which displays the o�ers presented by the di�erent stands or sections inthe environment in which the service is deployed.

The other aspect of this service is more challenging; the user needs to be inthe regular mode which is the main screen (My Position). As the user movesthrough out the environment, whenever he is three meters from a stand that hasan o�er posted, then a pop-up message would be displayed announcing this o�er.The user then has the chance to dismiss the pop-up message; else it would justdisappear as he is more than three meters from the stand, and then the userreturns to the original map.

Note that the o�er information is dynamic, that is the server provides the mobiledevice with the o�er information available, thus it has the capability of updatingthese o�ers.

4.3.4 Location-based Search

This service enables the user to search through the products o�ered in a mallor a fair or any similar environment. Then it enables the display of the searchresults and/or determines the places where the search results are located on themap with respect to the users position. So basically this service includes multipleaspects in our application and they can be illustrated as follows:

From the main menu, the user chooses the List button to input the list of itemsthat he wishes to search for. This moves him to another screen; this screen has achecklist of the items available in the environment. Note that in a more realisticscenario, one screen can not hold all the items available in the environment atonce, thus the items, would be divided into categories for scalability purposes.And this can be done easily but since we do not - in our testing scenario - havesuch a large item list, we will settle for one screen containing the whole list. Backto the application, the user can either check certain items at a time using thepointer, or he can select all the items at a time using the Select All button, andthe user has also the choice to deselect whatever items he had chosen using theDeselect All button. After the user checks whatever he items he wants to searchfor, he moves back to the main screen, and now he has his list saved for futureor immediate usage.


Then the user has the choice of checking a summary of the list search resultsupon choosing the Detailed Cart. A search method is then applied on the savedlist and a screen with detailed search results of the list is displayed. This screendisplays the number of items that are found on each stand as well as their names.

Again from the main menu the user has a choice of displaying the places wherethe items he wanted to search for are located. This is possible by choosing theShow Cart option. This option displays ags on the stands at which the itemsare available. So the user would have the position of the stands that he wants tovisit as well as his own position, thus he is able to determine the most e�cientpath for navigating through the medium. Now if the user intends to return tothe original regular map, he can choose the My Position button.

4.3.5 Threading Issues

After transmitting data successfully from the server to the mobile phone, weturned our attention to writing the �nal application. It is not after a long timethat we fell into a common problem when dealing with servers, clients and con-nections. Our client is actually the logical server in the connection because theserver will connect on it to provide it with data. The phone should be alwayslistening for the coordinated to come, thus it is a logical server. The server canconnect, whenever it has ready up-to-date data to transmit, to an always listeningsource (the logical server) thus it is the logical client.

The problem is simply that an application running a logical server, such as theone we are writing on the mobile phone, will totally block when it enters the"listen" stage of the connection. It will remain in this blocking stage until thelogical client (our server) connects on it. The problem is even bigger because wewant to always stay updated with the latest position. To solve this problem, weneed to separate the blocking portion of the code from the rest of the application.

Thus, we were in a desperate need to learn something about threads. We hadsome elementary information about threads and how they are like separate codesrunning simultaneously and controlled from the same code. Another week and ahalf with a book called "Taming Java Threads" was enough to give us an enoughhands-on experience with threads to be able to write whatever we need for ourapplication program [29].

So now, after the dust has settled down, we have three main threads running inour application. The main thread is the one that gives the user the exibilityof browsing among the di�erent service portions of the program. The other twothreads continuously run in the background and share a variable among them.The �rst of them is always listening for a connection that carries new coordinatesfrom the server. When it successfully receives something new, it updates theshared variable with the new value and moves on to listen for a new connection.


The second thread continuously checks for the shared variable. When the sharedvariable is updates, it updates the position on the main screen (map).


Figure 4.3: User Interface States of Client

Chapter 5

Accomplishments

Many steps have been done so far throughout the nine month period. To keepgood track of what have been done, the inclusion of this chapter is essential.Adding facts about the needed tools and budget gives the report a tangible aspect.

Through the past few months, our work was mostly related to the theoreticalaspect of the project. An extensive literature survey and an experiment wereperformed to provide us with the required theoretical background, as well as toanswer important design questions. A system design was then proposed alongwith a detailed but tentative work plan for the months to come. Finally, an im-portant accomplishment in the early stages was when Ericsson agreed to sponsor,and fund the project.

5.1 Meeting with Ericsson

After �nalizing the primary FYP topic terms between the supervisor and us, wedecided to propose the project to Ericsson Lebanon Communications in a requestfor their sponsorship of the project.

At the headquarters of Ericsson Lebanon Communications in Sin El Fil, we metwith Ericsson representatives Mr. Ramzi Sukkar and Mr. Moueen Nassar. Wepresented and discussed the topic of the project and the di�erent design aspectscorresponding to the system. Mr. Sukkar and Mr. Nassar then demonstratedEricsson's will to sponsor the project �nancially. They also agreed to provide uswith any documents or information that might be useful in our design.

62 5. Accomplishments

5.2 Literature Survey

In order to gain a su�cient theoretical background that would enable us to designthe system, as well as explore the implementation capabilities of the hardwareand software of this system, we were required to conduct an intensive literaturesurvey.

This survey covered localization systems, location based services, localizationtechniques, and accuracy enhancements algorithms. We also investigated previ-ous implementations of localization systems. We studied their design decisions,and investigated the logic behind those decisions. Moreover, a signi�cant surveywas conducted on the Bluetooth technology, which is our localization system ofchoice, in order to explore its capabilities and limitations. We used this survey toexplore programming environments pertinent to our project and more speci�callyto the experimental setup that was conducted. Thus, it comprised the biggestportion of our work during the past few months. Furthermore, we regard it ofgreat importance for the implementation decisions to be taken in the followingstages.

5.3 Experimentation

After conducting the literature survey, and gaining enough theoretical back-ground, we decided to perform an experiment that would enable us to get a avor of what we had studied. Moreover this experiment was intended to giveus an idea of the system capabilities and its functioning in the real time environ-ment. The experiment was conducted in the later stages of �rst portion of theproject. It provided us with valuable feedback that would enable us to make thedesign decisions that should enable the best functionality of the system. Also,as mentioned in Section 3.2, certain problems that we had encountered in theexperiment require us to perform further experimentation in the �rst stage of thefollowing phases.

5.4 System Design and Plan

After administering the literature survery and the experimental setup discussedbefore, we reached some decisions in our system design. These decisions include:using the RSSI as a method for localization, the number of access points, thesource of inquiry, and the inquiry procedure. We still plan on doing additionaland more extensive experiments that can help us arrive at more stable RSSIvalues. Also, we need to determine some design issues for the coding phase. Thiscan be done right after getting reliable RSSI values. Moreover, the service we

5.5. Timeline 63

will implement will be appropriatly planned to meet the needs of mobile phonesusers.

5.5 Timeline

Table 5.1 shows a the timeline of the project execution procedure we followed inthe spring term. Mind you that the process of writing the report took place atall stages in parallel with the execution of each phase.

Phase Duration Estimated Dates

Experimental Analysis 2 Weeks Feb. 6 - Feb. 19Localization Algorithm Enhancement 1 Week Feb. 20 - Feb. 26Location Service 3 Weeks Feb. 27 - Mar. 19Server Development 2 Weeks Mar. 20 - Apr. 2Access Point Development 2 Weeks Apr. 3 - Apr. 16Mobile Application Development 2 Weeks Apr. 17 - Apr. 30Additional Features 2 Weeks May 1 - May 14Project Testing and Demonstration 2 Weeks May 15 - May 28

Total: 16 Weeks Feb. 6 - May 28

Table 5.1: Tentative Spring Work Plan

5.6 Budget Estimation

Concerning the direct costs and starting from the system implementation needs,we prepared some information regarding the hardware and software tools wehave used. The hardware components were used to build up the backbone of thesystem. We developed all of the software part.

For the access points we used USB dongles. From the mentioned hardware spec-i�cations above, we can summarize the system implementation requirements inTable 5.2.

5.6.1 Funding

This project is funded by Ericsson Lebanon Communications. So, we are lookingforward to receive the needed funding for the system components. The EricssonP990 mobile phone will be very handy for this project. It can be easily pro-grammed. Adding to this, it has the crucial Bluetooth radio 1.2 version. This

64 5. Accomplishments

Item Cost per Item Total Cost

1 � BlueGiga Wrap Access Point Servers v2291 $480.00 $480.001 � SDK Software $275.00 $275.003 � Bluetooth Dongles / Creative CB2431 $36.67 $110.012 � USB Extension (5m) $7.33 $14.661 � USB-Extender (150 ft./45.72m) $125.99 $125.99

Total: $1005.66

Table 5.2: Costs Summary

will give the implementation phase a great exibility. It is not out yet, but it willbe in the markets soon.

Chapter 6

Testing and Analysis

In our project, testing was not a classical phase that is performed at the end ofeverything. We were forced to incurr testing throughout the project developmentstages.

6.1 RSSI Accuracy

We tried doing an inquiry with RSSI commands on many di�erent Bluetoothdevices. The uctuations were the same. The only di�erence we were gettingamong devices was in the range of RSSI we get from them. Particularly, theBlueGiga access point showed a much stronger range. Its range started from -25dbm (to-30 dbm) while most of the other devices started from -45 dbm to (-50dbm). Still, we did not get any accuracy gains form this because the whole rangeshifted. We did not get something between -25 dbm and -85 dbm, but between-25 dbm and -65 dbm. Suddenly we were hit by the fact that we are not goingto achieve any accuracy gains regarding the uctuation and range issues. This isthe nature of the discrete and not so �ne RSSI readings.

6.2 Hardware Setup

We were faced with two other problems regarding the BlueGiga access points.The �rst one is that they had to be fabricated after July 1st 2005 in order tocomply with the 2.0 standard and be able to perform inquiry with RSSI. Thiswill certainly add some temporal overhead. In addition to this, we found out,from the BlueGiga we had on hand, that we might need the SDK to trigger theinquiry with RSSI as we did using the C code. Otherwise, we would have tocompile a code to the processor of the BlueGiga. This may lead us to distracting

66 6. Testing and Analysis

problems away from our core subject. Also, there will be a great overhead on the�le transfer between the BlueGiga and the server on one hand and the BlueGigaand the mobile phone on the other hand.

Bearing this in mind, we started thinking about canceling this mid-way stepbetween the server and the mobile phone. After all, we only need the BlueGigaas an inquiry source and as a �le transfer method. We know that the former onecan be done equivalently e�cient on both a BlueGiga as on an ordinary Bluetoothdongle. But the latter surely needs some programming. This will force us to usethe SDK programming environment. This means that we have to buy it, get toknow how to use it, and live with a great time overhead that might a�ect theapplication as a whole.

This is when the idea of buying three Bluetooth dongles and some USB exten-sions came in. This will simplify the control over the Bluetooth access points.The programming environment in this case will be the Linux environment withits exibility and wideness. Also, the time overhead would have been cancelled.Actually, the Linux system can be told to work with any one of the attached Blue-tooth dongles separately at any time. The radios see each other independently;this was very promising and encouraging.

After searching a lot for Bluetooth dongles that were able to perform inquirywith RSSI, buying at least two and failing, we found a one that complies to ourstandards by pure luck. We bought it from its original owner and started workingwith it.

6.3 Zone Area

More than �ve di�erent test setups were done each time changing a variable. Wetried decreasing the maximum distance from the dongles (ultimately decreasingthe room area), increasing the number of RSSI taken during the setup phase,increasing the number of RSSI taken during the runtime phase, acquiring RSSIvalues upon a connection. The only thing that seemed to work with some con-sistency in the results was increasing the zone we were trying to locate in to a3m x 3m (9m2 blocks). The results in this case, with enough RSSI readings inthe setup phase (around 230 readings) and enough RSSI readings during the runtime phase (around 20 readings), came out to be �nally consistent. Thus, wedecided to enlarge the zones for better accuracy.

6.4 Bluetooth Module Sluggishness

Throughout our extensive experimentation periods, we noticed an essential pa-rameter to our application that may enhance or seriously degrade the perfor-

6.5. Scalability Issues 67

mance of our application. This is the speed at which a certain Bluetooth moduleresponds to the inquiry with RSSI commands. We worked with a very fast re-sponder (IMATE PDA2), a slightly slower one (Sony Ericsson T630) and veryslow one which unfortunately was the P910 we used in our demonstration. Itseems to give a single RSSI response every �ve seconds on average which com-pared to around four RSSI responses per second of the IMATE is very poor. Still,we had to stick to it for programming purposes.

This sluggishness seems to have its roots in the power management of the device.After all the P910 is a small PDA and it still has a battery that is the size of thatof the T630 (which is an ordinary phone) or slightly larger. This forces a strongpower control on the Bluetooth module (among other phone hardware resources)that only allows full power for the module after establishing the connection. Thisis logical since the module does not have to respond to all RSSI inquiries becausenot all of them are for it. But this seriously degrades the performance of ourapplication. If we are to stick to one RSSI reading to determine the position, theerror will be signi�cant. If we choose to wait long enough to get the necessaryRSSI readings to get a within-bound error, the time overhead will be unbearablefor the user.

The IMATE on the other hand had a large enough battery that could supporta full edged running Bluetooth module all the time. Thus, this will give uswhat we need in terms of a lot of RSSI readings (to maintain error bound) in ashort time (to server fast enough). This will help developing the application inbranches like mobility issues and result �ltering.

Thus, we recommend that future hardware that uses our application have least, orbetter, no power control of the Bluetooth module. After all, what we are doingindoors is similar to outdoors GPS and may one day integrate with it to givepinpoint location to a room level (or 3m error bound) earth wide. This deservesmore power to be given to Bluetooth modules on mobile devices because theyhave a priority here.

6.5 Scalability Issues

It is crucial here to point out that our application is not governed by the smallsetup we did for demonstration purposes. Our application is totally scalableto whatever range is preferred. The only thing that is needed is spread the areawith enough Bluetooth module to cover all the needed localization space. We are,in other words creating a sort of a centralized wireless network. The plus thiswireless Bluetooth network has over WLAN networks is that Bluetooth moduleis present on almost every new mobile device. Actually it was named so for thisgathering characteristic it acquired upon fabrication.

68 6. Testing and Analysis

The application, code wise, does not depend on the number "three" that we chosefor our demonstration. We actually chose this number because anything belowthis number is poor in accuracy according to the literature survey done in the falland from our personal experience through the testing and experimentation wedid in the spring. Our code, on both server and on client side is general enough.The server code waits for three RSSI readings from any three modules for anyBluetooth module, calculates the position, tries to connect to the module throughany of its arms (dongles) and sends it the result.

We may also say that this is an optimized solution. This can be seen throughthe fact that the three RSSI readings the server is going to acquire for a certaindevice will surely be the best three. This is so because the inquiry-with-RSSIand its response procedure is faster and better (more accurate) the closer is thedistance. Also, when the server wants to connect to the module and provide itwith the calculation results, it will do so through the best module because theconnection code at the server, in nature, uses any of the modules and moves tothe next upon failure.

6.6 Further Enhancements

Some further code can be written here in the future to tell the server to try toconnect to the module through one of the three modules that were the �rst inacquiring the RSSI readings because they are more likely to be in the vicinity ofthe module the server is trying to connect to.

Also, as a scalability issue, the connection may to become duplex. This is sobecause with growing exhibition size, the database for the stands present in theexhibition will grow and become a bottle neck if we want to incur it on the clientside as we did in our demonstration. Thus, the database will be maintained onthe server side. The duplex connection will be needed because the client will needto tell the server about the things it is looking for. Once a duplex connectionis achieved, it is even better to do a full-duplex one to reduce the overhead ofcreating a connection to talk with the same client but in the opposite direction.This is also not so hard to implement once a duplex connection is established.A fast check is done if a connection already exists. If yes use it, if not createit. This is attainable because Bluetooth L2CAP connections are full-duplex bynature.

To create a duplex connection, a similar code of what is currently present at theserver (logical client because it is the one connecting to the phone) should beimplemented in a new thread (as in programming thread) on the mobile phone.Similarly, a copy of what is now present at the phone (the logical server because itis the one the dongles are connecting to) should be implemented in a new thread

6.6. Further Enhancements 69

on the server side. Speaking with an experience of dealing with threads, this isnot a hard tasks, it just needs some time to implement.

Chapter 7

Conclusion

The increasing e�ort applied in the development of location based services in thelast few years has been further fueled by the persistent advances in the �eld ofwireless communication. These advances are enabling more and more accuratelocalization. Moreover, the Bluetooth technology in particular is presenting itselfas a strong candidate technology for indoor localization. This report presents anovel design that exploits the Bluetooth technology capabilities to implement alocation based service.

7.1 Wrap-up

A system design is proposed in this report. This design proposes the technologiesthat will be applied in order to reach the �nal product. The design proposesthe use of the signal strength as a means for localization. Moreover, the systemin design exploits the dedication of three access points, a server, and a mobiledevice to attain the localization capabilities. The mobile device as well as theserver should be provided with the software that enables them both to performthe localization algorithm and present the location based application. The accesspoints are mainly used to measure the RSSI values. Then they share this RSSIinformation through the server and arrive at the location of the mobile phone.They are also used to provide a means of communication between the server andthe mobile phone.

This report presented the work that has been performed in the past nine months.This work includes the research performed on the localization technologies. Itcontains the literature survey that enabled us to take important design decisions.It also incorporates the experimental procedure and analysis conducted and theproposed system design. It also shows a detailed discussion of the implementationphase. Finally, we felt it is of good bene�t to register our remarks about someproblems and enhancments. All these aspects are covered throughout this report.

7.2. ABET Evaluation 71

7.2 ABET Evaluation

In every engineering new innovation, it is vital to recall the most basic principleof ABET's Code of Ethical Conduct for Engineers which states the following:"Engineers uphold and advance the integrity, honor and dignity of the engineeringprofession by using their knowledge and skill for the enhancement of humanwelfare". The code of ethics includes other principles, but this principle encirclesthem all. In their work, engineers' designs and implementation should alwaystake into consideration the welfare of whoever and whatever could be a�ectedby their work. This welfare extends from the economic, environmental, ethical,health considerations to safety, manufacturability, and sustainability of the workprovided.

As soon-to-be engineers, this guiding principle has set strict constraints for our�nal year project. In this project we, from the beginning, starting with the choiceof the project, to the design phase, and �nally to the implementation phase havecommitted our selves to this principle, "to enhance human welfare".

Economically, our project satis�es low budget pro�les. The application is simplyinstalled on a mobile device (which is extremely widespread), the application isdependent on the Bluetooth radio of the mobile device which operates on a freeand unlicensed frequency band of 2.4 GHz. This is from the users side. Fromthe server or provider side, there needs to be a server coupled with a Bluetoothnetwork that enables the coverage of the area of deployment. So, from here arisesthe cost of the server as well as the cost of Bluetooth dongles which is not veryhigh (around $20 each). Again here the fact that the Bluetooth operates at afree frequency band is a plus.

The project we have designed is sustainable. The code generating the mobileapplication is robust, and has the ability to handle exceptions in the system. Onthe server side, the software running on the server is also very robust; its crashpossibilities are very low. However the server hardware itself and the Bluetoothradio in the network needs checking semi-annually, but in regular conditions theBluetooth network should last for a long time.

On the environmental and health level, our project provides no threats on bothlevels. The Bluetooth radio is extremely harmless; it provides no harm what-soever to the users or regular passengers in the coverage area of the Bluetoothnetwork. Moreover no harm to the environment can be caused by our projectwhich is composed of consistent solid blocks that have no impact on the environ-ment. Moreover, the blocks constituting our project, which are the applicationon the mobile device and the server and Bluetooth network do not need any spec-i�ed safety measures of their own. The same safety measures that apply to theuse of a regular mobile device obviously comply here. However there should becaution in the setup of the Bluetooth dongles and the server as not to pause any

72 7. Conclusion

possible threats to the passengers around the environment as well to the systemitself.

Bibliography

[1] \Gps world," http://www.gpsworld.com/.

[2] Andrea Goldsmith, Wireless Communications, Cambridge University Press,New York, 1st edition, 2005.

[3] \The institute of electrical and electronics engineers, inc.,"http://www.ieee.org/.

[4] \The o�cial bluetooth membership site," http://www.bluetooth.org/.

[5] \Speci�cation of the bluetooth system,"http://www.bluetooth.org/foundry/adopters/document/.

[6] \The o�cial bluetooth wireless info site," http://www.bluetooth.com/.

[7] Nissanka B. Priyantha, Hari Balakrishnan, Erik Demaine, and Seth Teller,\Anchor-free distributed localization in sensor networks," April 2003.

[8] Lingxuan Hu and David Evans, \Localization for mobile sensor networks,"Mobicom, September 2004.

[9] Josef Hallberg, Marcus Nilsson, and Kire Synnes, \Positioning with blue-tooth," IEEE Telecommunications Magazine, vol. 2, pp. 954{958, February2003.

[10] Dragos Niculescu and Badri Nath, \Ad hoc positioning system (aps) us-ing aoa," Joint Conference of the IEEE Computer and Communications

Societies, vol. 3, pp. 1734{1743, 30 March{3 April 2003.

[11] T. S. Rappaport, J. H. Reed, and B. D. Woerner, \Position location usingwireless communications on highways of the future," IEEE Communications

Magazine, vol. 4, pp. 33{41, October 1996.

[12] Mansoor Alicherry, Harsha Nagesh, Chitra Phadke, Vishy Poosala, andSumesh J Philip, \Balancing the accuracy and practicality of location track-ing in heterogeneous mobile networks," IEEE Communications Society, vol.5, pp. 3316{3320, 29 November{3 December 2004.

74 BIBLIOGRAPHY

[13] Rashmi Bajaj, Samantha Lalinda Ranaweera, and Dharma P. Agrawal,\Gps: Location-tracking technology," IEEE Computer Society, vol. 35, no.4, pp. 92{94, March 2002.

[14] \V2000 palsite," http://v2000.palsite.com/.

[15] \Location based services," http://www.mobilein.com/.

[16] \Pcworld.com," http://www.pcworld.com/.

[17] Miguel Rodriguez, Juan P. Pece, and Carlos J. Escudero, \In-building loca-tion using bluetooth," 2005.

[18] Sherry Hsi, Rob Semper, Waylon Brunette, Adam Rea, and Gaetano Bor-riello, \exspot: A wireless r�d transceiver for recording and extending mu-seum visits," 2003.

[19] Antti Kotanen, Marko Hannikainen, Helena Leppakoski, and Timo D.Hamalainen, \Experiments on local positioning with bluetooth," in In-

formation Technology: Computers and Communications, 28-30 April 2003.

[20] \Era :: Products :: Time di�erence of arrival (tdoa) multilateration princi-ple," http://www.era.cz/.

[21] Dieter Fox, Je�rey Hightower, Lin Liao, Dirk Schulz, and Gaetano Borriello,\Bayesian �lters for location estimation," IEEE Pervasive Computing, vol.2, no. 3, pp. 24{33, July-September 2003.

[22] Paramvir Bahl and Venkata N. Padmanabhan, \Radar: An in-building rf-based user location and tracking system," Microsoft Research, February2000.

[23] Y. Fukuju, M. Minami, H. Morikawa, and T. Aoyama, \Dolphin: an au-tonomous indoor positioning system in ubiquitous computing environment,"in Software Technologies for Future Embedded Systems, 15-16 May 2003.

[24] \Symbian os - the mobile operating system," http://www.symbian.com/.

[25] \Java 2 platform, micro edition (j2me)," http://java.sun.com/j2me/.

[26] \Bluez - o�cial linux bluetooth protocol stack," http://www.bluez.org/.

[27] Bruce Hopkins, Bluetooth for Java, Apress, Berkeley, CA, 1st edition, 2003.

[28] Daryl Wilding-McBride, Java Development on PDAs, Addison-Wesley,Boston, 1st edition, 2003.

[29] Allen Holub, Taming Java Threads, Apress, Berkeley, CA, 1st edition, 2000.

Documents

Bluetooth Based Location Estimation for Mobile ... 1 Introduction Wireless communication technologies have undergone remarkable advances over the last decade. This re ected directly