Learning Center
Plans & pricing Sign in
Sign Out



           Alex   Geller
           Arie   Abramovici

         Eduard Bortinkov
Table of Contents
  1. Introduction
           Project And Developing Team .............................. 3
           Project Overview ................................................... 3
           Project Description ................................................ 3
           Introduction To project Concepts ......................... 4
  2. The Watch-me System
           Watch-me Design .................................................. 7
           Watch-me Communication ................................... 8
           Watch-me Server ................................................... 9
           Watch-me Client ................................................... 13
           Watch-me messages .............................................. 15
  3. Watch-me features
           Watch-me IM Features .......................................... 20
           Watch-me Location Features ................................ 20
           Watch-me Statistical Features ............................... 20
  4. Installing and Running the Watch-me System
           Installing and running Watch-me Server .............. 21
           Installing and running Watch-me client ................ 21
           Important notes on compiling watch-me system .. 21
  5. Watch-me User Manual
           Main Screen........................................................... 22
           Creating new user .................................................. 22
           Registering ............................................................ 22
           Subscribing to a Group.......................................... 23
           Sending a message ................................................ 23
           Loading a map ....................................................... 24
           Getting info on group ............................................ 24
           Naming a Location ................................................ 25
           Define DND .......................................................... 26
           Query user statistics .............................................. 26
           Query user location ............................................... 26
           Query all groups on server .................................... 26
  6. Subjects Learned during the course of the project
           Subjects Learned in the project ............................. 27
  7. Bibliography and References ....................................... 28
  8. Appendixes
           Appendix 1 JAIN SIP Stack.................................. 29
           Appendix 2 Placelab ............................................. 41
1. Introduction

1.1 Project and Developing Team

Our Spring 2005 Semester Project is called ―Watch me –using java‖, it has been
cataloged as #09 on Comnet Laboratory Project List.

Developing team consists of:
- Project Supervisor: Eduard Bortnikov
- Students: Arie Abramovici and Alex Geller

The project website is

1.2 Project Overview

The main goal of Watch-me project is to build a Location Aware Instant Messaging
Application. A Location Aware application (or Presence Application) is an application
that determines the user’s geographical location, and according to past locations,
determines a higher-level description of the user’s status.
Instant Messaging is a wide spread array of applications whose function is to relay
messages between two or more people.
The idea behind this project is to implement a common instant messaging application,
and then enhance it, by answering one of the first questions asked in any conversation:
―Where are you‖?

1.3 Project Description

The watch me project consists of a client and a server.
Multiple clients can log on to the server and have conversations with each other.
Clients can use the system on mobile devices. In this case the system uses the mobile
device capabilities in order to determine each user’s location. Then, other users are
informed of the user’s location when chatting with him.
Moreover, the system collects statistics on users locations. The users can view these
1.4 Introduction to project concepts

In this section we will quickly introduce the user to several concepts used in the

Instant Messaging

Instant Messaging is a wide spread array of applications whose function is to relay
messages between two or more people.
In the past few years instant messaging has become a wide spread phenomena. Today
millions of users use instant messaging to have conversations all over the globe.
Just a few of the popular instant messaging application are:
AOL Messenger
MSN Messenger

Sip Protocol

SIP- Session Initiation Protocol, or SIP, is end-to-end client server session signaling
protocol. Meaning this protocol allows users to register to a server, and afterwards
connect to each other, regardless of their current location. SIP also has extensions for
Instant Messaging and Presence. Two parties run the SIP protocol: the users and the SIP
server (which consists of SIP proxy, Registrar and location server). The users contact the
server and register (allowing the user to change device transparently). After the
registration, the users can contact the proxy to get the location of other users and message

For more information see appendix : SIP protocol

Wireless LAN (or WLAN)

Acronym for Wireless Local Area Network. A type of LAN that uses high-frequency
radio waves rather than wires to communicate between nodes. WLAN consists of base
stations (access points to the LAN) and wireless devices (laptops, Ipaqs etc.). The devices
contact the access point that acts as a Hub and provides connectivity for the wireless
devices. A wireless computer can "roam" from one access point to another, with the
software and hardware maintaining a steady network connection by monitoring the signal
strength from in-range access points and locking on to the one with the best quality.
Usually this is completely transparent to the user. They are not aware that a different
access point is being used from area to area.

Current standard is:
IEEE 802.11

RSSI is an acronym for Received Signal Strength Indication. RSSI is a measurement of
the strength (not necessarily the quality) of the received signal strength in a wireless
environment, in arbitrary units. RSSI can be used internally in a wireless networking card
to determine when the signal is below a certain threshold at which point the network card
is clear to send (CTS). Once the card is clear to send, a packet of information can be sent.


(Actually the real name is ―trilateration‖ as real mathematical triangulation uses angles as
well as lengths)

Triangulation is a method of determining a location based on a couple of distances from
known points.

Imagine you are somewhere in the United States and you are TOTALLY lost -- for
whatever reason, you have absolutely no clue where you are. You find a friendly local
and ask, "Where am I?" He says, "You are 625 miles from Boise, Idaho."

This is a nice, hard fact, but it is not particularly useful by itself. You could be anywhere
on a circle around Boise that has a radius of 625 miles, like this:

You ask somebody else where you are, and she says, "You are 690 miles from
Minneapolis, Minnesota." Now you're getting somewhere. If you combine this
information with the Boise information, you have two circles that intersect. You now
know that you must be at one of these two intersection points, if you are 625 miles from
Boise and 690 miles from Minneapolis.
If a third person tells you that you are 615 miles from Tucson, Arizona, you can eliminate
one of the possibilities, because the third circle will only intersect with one of these
points. You now know exactly where you are -- Denver, Colorado.

Location aware application

A Location Aware application (or Presence Application) is an application that determines
the user’s geographical location, and according to past locations, determines a higher-
level description of the user’s status.
     2. The Watch-me System

     2.1 Watch-me Design

                           JAIN SIP               JAIN
    Communication          Stack                  SIP      Client
                                                  Stack    GUI

       Control                                            Controller

       Model                                              RSSI

       Location        Distance
       Calcultaion     Calculation
       Plugin          Plugin

SQL Database

The watch-me system consists of a server and a client.

   The client collects signal strength (RSSI, which can be used to determine
   The client sends RSSI data to the server via JAIN SIP (over SIP protocol).
   The client sends and receives instant messaging messages from the server via
      JAIN SIP (over SIP protocol).

   The Server Receives RSSI Data from the client via JAIN SIP Stack (over SIP
   The Server uses the RSSI data to calculate the client’s location using Location
     Calculation and Distance Calculation plug-ins.
   The Server stores data about users location through time in the SQL database
     using SQL controller
   The Server holds data about user messaging groups
   The Server sends and receives messaging data from the client using JAIN SIP
     Stack (over SIP protocol)

22.2   Communications

As mentioned before, all Watch-me communication is done in SIP Protocol by
2.3 Watch-me Server
The Watch-me server consists of the following Packages:

2.3.1 Communication Package

The communication package is responsible for incoming and outgoing communications
in the server.
The communication is done in SIP protocol using JAIN SIP Stack.
The communication package handles incoming events from the SIP Stack and dispatches
them to the suitable controller.

2.3.2 Model Package

This package contains all the data the system has on users, groups, etc.
During the run of the system, the data is updated by the controls so that at every point the
data in the model is current.
If the server terminates for some reason, the data saved in this package has a back-up in
the SQL database, and will be re-loaded from there.
The data the system stores in the model is:
      All users in the system
      All groups in the system
      The groups a user is member of and vies versa.
      All rooms defined in rooms XML
      All Access Points defined in access-points XML
      For each user the names for all rooms he named
      For each user his current location, and when did he enter the room

2.3.3 Control Package

This package takes the commands received by the communications package, translates
them into logical command and manipulates the data in the system to respond to that
The control package is divided into several different interfaces for future extensibility.
The interfaces are:

      IM Control:
          o Handles all IM functionality
          o Handles subscribe, un-subscribe, invite, and IM messages.
      Location Control:
          o Handles all location driven events.
          o Handles incoming location updates received from the client
              as he moves.
          o Handles naming of rooms
         o Handles definition and cancels of do not disturb.
      Management Control:
         o Handles management of the data.
         o Handles creation of new users
         o Handles register and un-register of users in the system
         o Handle all the different queries submitted by the user

2.3.4 Location Calculation

Note: This part of Watch-me project uses work done in the Wireless location server
project of Comnet lab.

The server calculates users location using triangulation.
The server receives RSSI data from the client.
The server then proceeds to calculate the user location using two methods:


This method calculates the distance from a point using RSSI measurement for signal
received from that point.
After empirical studies, we found that the best results were give by this formula:
                                                          64  SignalStrength
 DISTANCE  8 10                                                  30


This method receives a list of access-point locations and the distances from that access-
point (calculated by DistanceCalculation).
The algorithm for finding the location is:

   1. For each access-point create a circle with radius of distance from that access
   2. For every 2 access-points:
         a. Find the 2 points of intersection between the circles
         b. Add to a list of chosen points one of the 2 points which has the minimum
             sum of distances from other access-points
   3. Return the average of the chosen points.
2.3.5 SQL control and Database

Watch-me system uses an SQL database for storage of statistics on users location, and for
persistency issues.
For program persistency, all the data that is contained in Model package is also contained
and updated in the SQL Database. That way, during server run we use data stored in the
memory for server speed, but if the server is stopped it can be restarted with the data in
the system.

We chose to use PostgreSQL Database.

The PostgreSQL advantages are:

   1. It is an established open source database.
   2. It can run on both linux and windows operating systems. Since the Watch-me
      server is written in Java, the entire watch-me platform in server side can run on
      one computer, linux or windows.
   3. It has support for built-in Java SQL platform – JDBC, which means easier
      programming of SQL in Java.

All access to the database is done via the database controller. The controller receives a
request from one of the server controls, and creates a matching SQL query for the

2.3.6 Server XML Files

In order to run properly the server needs information about defined rooms in the system
and access points locations. This knowledge is entered in 2 XML format files. The files

1. Rooms XML: The file Rooms.xml defines all rooms in the system. A room must be
pre-defined for users to be able to name it. This files gives room dimensions and room
key. Each room’s key must be a unique string. This key is associated in the system with
that room and must never be changed, although new rooms can be added. The rooms are
defined in format of:
>Key>1111</Key< The room key
>StartX> 0 </StartX< The lower X bound in meters
>StartY> 0 </StartY< The lower Y bound in meters
>StartZ> 0 </StartZ< The lower Z bound in meters
>EndX> 12 </EndX< The upper X bound in meters
>EndY> 7 </EndY< The upper Y bound in meters
>EndZ> 0 </EndZ< The upper Z bound in meters
> /Room>
2. Access Points xml: The file AccessPoints.xml defines access points and their location.
This data is used in the triangulation process. The data is defined in format of:
<MAC>00022D1ECAEC</MAC< The MAC of the access Point
>Location>( 8.45, 3.85 , 0 )</Location< The X , Y, Z location meters
2.4 Watch-me Client

The Watch-me Client has the following packages:

2.4.1 Communication Package

This packages implements the communication on the client side. The userNode class
receives incoming communication and sends it to the right handler.

2.4.2 Handlers Package

This handles the sending of outgoing SIP messages and the parsing and handling of
received SIP messages. Each type of message has it’s own handler which handles all
incoming and outgoing messages of that type. For example and outgoing register
message would be sent through the RegisterHandler, and incoming register message
should be directed to the same handler.

2.4.3 Control Package

This package implements the controls of the Watch-me Client. There are currently two
The ViewControl class controls the client’s GUI.
The CommunicationControl controls the client’s communication.

2.4.4 View Package

This package implements the client’s GUI.
The GUI was developed using Java swing library.

2.4.5 RSSICollector Package

This package implements the client’s RSSI collector. The RSSI collector collects the
RSSI data for the client, and sends it to the server via the communication controller.
The RSSI runs in a new thread so that it won’t interfere with the client’s behavior.
The RSSI data is collected using the PlaceLab package.

Place Lab is software providing low-cost, easy-to-use device positioning for location-
enhanced computing applications. Place Lab tries to provide positioning which works
worldwide, both indoors and out (unlike GPS which only works outside). Place Lab
clients can determine their location privately without constant interaction with a central
service (unlike badge tracking or mobile phone location services where the service owns
your location information).
The Place Lab approach is to allow commodity hardware clients like notebooks, PDAs
and cell phones to locate themselves by listening for radio beacons such as 802.11 access
points, GSM cell phone towers, and fixed Bluetooth devices that already exist in large
numbers around us in the environment. These beacons all have unique or semi-unique
IDs, for example, a MAC address. Clients compute their own location by hearing one or
more IDs, looking up the associated beacons’ positions in a locally cached map, and
estimating their own position referenced to the beacons’ positions.

Placelab has a full client, but also an open source Java package that retrieves all the
placelab data.

For more information see appendix 2: placelab

2.4.6 Client Map XML

In order to use a map for showing people’s location the user needs to load a map.
Loading a map is done by specifying an XML file containing the data about the map.
The map data is the location of a gif or jpg file containing the map and the map
dimension. The user needs to specify the dimensions in real world the map holds, in
The format for the XML:
>MapLocation>./resource/floorplan3.JPG</MapLocation< - The location of the map file
        >MapWidth>24</MapWidth< --- The map width in meters
        >MapHeight>15</MapHeight< --- The map Height in meters
2.5 Watch-me messages

In order to implement the location functionality of the Watch-me server, the Watch-me
group extended the SIP protocol to include new types of messages.
During the run of Watch-me system the following messages will traverse the network:

CreateUser- This message creates a new user in the system. A user must be created
before he can log on. Therefore, a clients sends create user message, specifying the
username and password.
The Create user syntax is:

Call-ID: nist-sip-im-register-callId1
CSeq: 1 REGISTER message type is register for CreateUser message
From: <sip:mooomooo@>;tag=5072 The message is sent from
the new user
To: <sip:__newUser@> The message is sent to __newUser
Via: SIP/2.0/TCP technion-
Max-Forwards: 10
Content-Type: text/plain;charset=UTF-8
Contact: <sip:technion-irina:11111;transport=tcp>
Expires: 1000
Content-Length: 12

mooomooo~moo The syntax of the message is Username~password

Register- this message is normal SIP register message. It specifies an existing user
logging on.

This message syntax is the normal SIP Register message except for a password that is
sent as message body:

Call-ID: nist-sip-im-register-callId1
From: <sip:arie@>;tag=3111
To: <sip:arie@>
Via: SIP/2.0/TCP technion-
Max-Forwards: 10
Content-Type: text/plain;charset=UTF-8
Contact: <sip:technion-irina:11000;transport=tcp>
Expires: 1000
Content-Length: 4

Arie The password of the user registering
Subscribe- subscribe message signifies a user joining a group. This message can be sent
from the client to the server if a user wishes to join a new group. This message can also
be sent from the server to the client if the user has been subscribed in the past to that
group an is now logging in again.
The Subsctibe message syntax is normal SIP subscribe syntax.
SUBSCRIBE sip:technion-irina:11000;transport=tcp SIP/2.0
Call-ID: nist-sip-im-subscribe-callId1
From: <sip:group1@>;tag=9950
To: <sip:arie@technion-irina>
Via: SIP/2.0/TCP;branch=z9hG4bK03b28c7e1de66bc50c7fa14ae5a4b12d
Max-Forwards: 70
Contact: <sip:;transport=tcp>
Expires: 1000
Event: presence
Accept: application/pidf+xml
Route: <sip:arie@technion-irina:11000;tcp>
Content-Length: 0

Invite- invite is sent from the client to server in order to invite a group of user or a
specific user to chat.

Syntax is normal SIP invite syntax:

INVITE sip:;transport=tcp SIP/2.0
Call-ID: nist-sip-im-invite-callId1
From: <sip:arie@>;tag=402 sender
To: <sip:group1@> receiver
Via: SIP/2.0/TCP;branch=z9hG4bK6c82d56ccd5b4066b5e20cd9d064221f
Max-Forwards: 70
Contact: <sip:;transport=tcp>
Event: presence
Accept: application/pidf+xml
Content-Length: 0

Message- this is a text message sent during chat from a user to a group or a different

Syntax is normal SIP Message syntax:

MESSAGE sip:;transport=tcp SIP/2.0
Call-ID: nist-sip-im-message-callId1
From: <sip:arie@>;tag=2006 sender
To: <sip:group1@> receiver
Via: SIP/2.0/TCP;branch=z9hG4bK3e642b70a67b7c4b170607483a784e82
Max-Forwards: 70
Content-Type: text/plain;charset=UTF-8
Contact: <sip:;transport=tcp>
Content-Length: 16

Fdsfd Text sent by the user

Info- info is sent from the client to the server when a user requests information about a
different user or group.

Syntax is normal SIP info syntax:

INFO sip:;transport=tcp SIP/2.0
Call-ID: nist-sip-im-info-callId1
CSeq: 1 INFO INFO Message
From: <sip:arie@>;tag=7346 querying user
To: <sip:group1@> queried user or group
Via: SIP/2.0/TCP;branch=z9hG4bK1aeccd2f071220386bcf295d6819dfa8
Max-Forwards: 70
Contact: <sip:;transport=tcp>
Event: presence
Accept: application/pidf+xml
Content-Length: 0

Response: The response will be a list of users in the group, their status and location

Call-ID: nist-sip-im-info-callId1
CSeq: 1 INFO
From: <sip:arie@>;tag=7346
To: <sip:group1@>;tag=9738
Via: SIP/2.0/TCP;branch=z9hG4bK1aeccd2f071220386bcf295d6819dfa8
Max-Forwards: 70
Content-Type: text/plain;charset=UTF-8
Content-Length: 168

Syntax is : Username~Status~Location name~current x location~current y~current z
temp~OFFLINE~Unnamed~-1.0~-1.0~-1.0 negative measurements are sent for offline
arie~DND~room 375~19.84878172439884~4.7423083788289535~0.0

LocationData- this message is sent from the client to the server. This message contains
the RSSI data a client hears at a certain moment. The message is a list of access points
MACs and the signal strength received from these access points.

NOTIFY sip:;transport=tcp SIP/2.0
Call-ID: nist-sip-im-notify-callId1
CSeq: 1 NOTIFY The LocationData message is implemented as notify
From: <sip:arie@>;tag=3285
To: <sip:getLocation@> The location data message is sent to
getLocation service, in order to calculate the client’s current
Via: SIP/2.0/TCP;branch=z9hG4bK150fad1d8029db9ee5b38943510a2bfc
Max-Forwards: 70
Content-Type: text/plain;charset=UTF-8
Contact: <sip:;transport=tcp>
Event: presence
Accept: application/pidf+xml
Content-Length: 67

The syntax for this message is

The response for LocationData message will be a message containing the user’s current

Call-ID: nist-sip-im-notify-callId15
From: <sip:arie@>;tag=5947
To: <sip:getLocation@>;tag=390
Via: SIP/2.0/TCP;branch=z9hG4bK81cccae237abd566a4b25cdcc4b6e347
Max-Forwards: 70
Content-Type: text/plain;charset=UTF-8
Content-Length: 12

room 375~DND Syntax: Location~Status

Watch-me management and query messages-

This is a variety of message used for management actions (such as define/cancel dnd) or
queries about user (such as query user location at a specific time, or query user statistics).
All these messages are implemented as NOTIFY messages sent to different users at the
server ip. The user the message is sent to is the name of the service requested by the
client. Each type of message sends text data for the request in a specific syntax.
For example:

NOTIFY sip:;transport=tcp SIP/2.0
Call-ID: nist-sip-im-notify-callId296
From: <sip:arie@>;tag=1376 requesting user is arie
To: <sip:nameLocation@> user is requesting to name a
Via: SIP/2.0/TCP;branch=z9hG4bKa9e036a522541ec8996455789cabd90c
Max-Forwards: 70
Content-Type: text/plain;charset=UTF-8
Contact: <sip:;transport=tcp>
Event: presence
Accept: application/pidf+xml
Content-Length: 25

my name~16.675~9.5625~0.0 Syntax of name location

The services provided are:

NameLocation- A user gives a new name for a room. Syntax of the body is: room
name~X~Y~Z when (x,y,z) is a point in the room.
DefineDND- defines a room as a DND room. Body of the message is the room name.
CancelDND- cancels DND in a room. Body of the message is the room name
QueryUserLocation- queries the location of a user in a specific time. The syntax of the
body is: Queried username~Timestamp string of the time we wish to know about.
The reply for this message will be the name of the location the user was in at that time.
QueryUserStatistics- queries statistics about user behavior. The message body is the
name of the queried user.
The reply for this message will be a list of:
room name~percent of time
QueryGroups- query all groups on server. This message has no body.
The reply for this message is a list of groups on the server.
3. Watch-me features
3.1 Watch-me IM features

      Watch-Me system allows registered users to chat with other users or groups of
      The Server remember the groups a users subscribes to, so that the next time he
       logs on he will see those groups in his group list.

3.2 Watch-me Location features

      The Watch-Me system automatically detects the user’s
      A user can choose a name for each location.
      A user can get a map of the locations of all the members of a certain
       group. The system will show the status, location and location name (as
       chosen by the user) for each member of the group.
      The user can define locations in which he does not wish to receive
      Upon arriving to such a location, his status will automatically change to
       DND (Do Not Disturb), and he will not receive any messages while in that

3.3 Watch me Statistical features

      A user may inquire about the location of another user in a specific time.
      A user may receive statistics about another user. Those statistics show
       the percentage of time the user spent in each location.
4. Installing and running Watch-me system

4.1 Installing and running the watch-me server

   1.   Download Postgre SQL server
   2.   Create an account named watchme with password hattrick
   3.   Create a new database named database owned by the watchme account
   4.   Download Watch-me server binaries
   5.   Run run.bat

4.2 Installing and running the watch-me client

   1. Download the watch-me client binaries
   2. Run run.bat

4.3 Important Notes on compiling and running Watch-me system

       The Watch-me server and client can be compiled by any Java compiler/IDE
       In order to compile and run the server you need to add to your project (IDE) or
        add to the classpath (javac) the jar files of ―gov.jar‖ , ‖javax.jar‖, ‖postgresql-8.0-
       In order to compile and run the server you need to add to your project (IDE) or
        add to the classpath (javac) the jar files of ―gov.jar‖, ―javax.jar‖, ―placelab.jar‖

       ]]
5. Watch-me User Manual
5.1 Main Screen

5.2 Creating new user

   1. Click ―Menu‖ from the Main Screen
   2. The ―Create user dialog‖ will appear
   3. Enter a username, password and the IP of the server. Username should be
      a name no group or other user has.
   4. A message confirming that the user was created will appear

5.3 Registering

   1. In the main screen enter username, password, server IP and a port that is
      not used by other program
   2. Click the ―Sign in‖ button.
   3. Your status should change to online and the ―Sign in‖ button to ―Sign out‖
5.4 Subscribing to a group

   1.   In the main screen click ―Menu‖
   2.   Click ―Subscribe Group‖
   3.   Enter a group name.
   4.   The new group will appear under ―My Groups‖ in the main screen

5.5 Sending a message

Option 1:

   1. Subscribe to a group
   2. Double Click with left mouth button on the group name under ―My
   3. Messaging screen will

   4. Click on the ―Text to send‖ field
   5. Enter text
   6. Click ―Send‖ button

Option 2:
   1. Click ―Menu‖ from main screen
   2. Click ―Send an IM‖
   3. A dialog will appear asking for username or group name.
   4.   Enter username or group name
   5.   The chat window will appear
   7.   Click on the ―Text to send‖ field
   8.   Enter text
   9.   Click ―Send‖ button

5.6 Loading a map
   1. Click ―Load a map‖
   2. Choose an XML file containing the location of the map file and map size.
      If you downloaded the binaries off Watch-me website, the file is

5.7 Getting info on Group

To get a list of users in group and their locations:

Option 1:
   1. Subscribe to group
   2. Right click the group name under ―My Groups‖

Option 2:
   1. Click ―Queries‖
   2. Click ―Query group‖
   3. Enter group name
   In order to see a map of users location you will need to load a

5.8 Name a Location
To give a location your name:

   1.   Load a map
   2.   Click ―Menu‖
   3.   Click ―Name Location‖
   4.   ―Name Location‖ dialog will appear
   5.   Enter location name
   6.   Left click a point in the room you wish to name
   7.   A message confirming the naming of the location will appear

After naming the location, all places where location is shown, your name will appear for
that location.
5.9 Define DND

If you want to define a location in which you don’t want messages to be received:

   1.   Name a location
   2.   Click ―Menu‖ from main screen
   3.   Click ―Define DND‖
   4.   Enter the name you gave that room
   5.   A message confirming the definition of DND will appear

5.10 Query User Statistics

Returns a list of location, and the percentage of time the user spent in each location

   1. Click ―Queries‖ from main screen
   2. Click ―Query user location‖

5.11 Query user location

Returns the location of the user in a specific time

   1.   Click ―Queries‖ from main screen
   2.   Click ―Query user location‖
   3.   ―Query user location‖ dialog will appear
   4.   Enter the name of the ser you wish to query about, and the time you want
        to know about

5.12 Query all groups on server

Returns a list of groups with users on server.

   1. Click ―Queries‖
   2. Click ―Query all groups on server‖
6. Subjects Learned during the course of the project

SIP Protocol- We learned during the project the SIP protocol in detail, including the
working with a server in SIP.

JAIN SIP Stack- As the server and client are implemented with the help of JAIN SIP
Stack we learned how to work with the JAIN SIP Stack.

RTC Client API- our first thought about implementation was to implement the client with
RTC API. Therefore we studied the RTC Client API. However, we learned that the RTC
API is a high level API, and does not allow low-level access to the SIP messages
themselves. That is why we abandoned this idea in favor of JAIN SIP Stack.

Placelab- one of problems in the project was getting rssi data from an ipaq or a laptop.
We solved this problem by finding the placelab package. The placelab package is created
for determining device’s location, and so, along with other things it can determine the rssi
of many devices including some versions of ipaq and laptops running windows xp.

Java SQL programming- during the course of the project we learned the JDBC interface
which is a java interface for SQL programming. This was used in the Server Database.

Java XML programming- during the course of the project we learned the Java DOM API
for XML parsing. This was used for client and server XML parsing.

Programs on ipaq-during the course of the project we tried running our system on ipaqs.
However we encountered many problems with that.
First, ipaqs today are not strong enough to run heavy programs. Therefore, our client
would run very slow on ipaq. Moreover, as Microsoft doesn’t support java anymore (
Microsoft supports only J#), we couldn’t find a JVM that would run our client on ipaq.
Second, we looked at the option of running client in J#. We encountered some problems,
as J# is not 100% compatible with modern java but we solved them with the help of
ikvm. However we found that Microsoft doesn’t have a compiler that compiles J# into
ipaq programs.
Third, we looked at the C# option. Microsoft has a compiler that compiles C# programs
for ipaqs. We tried to look into the option of running C# client using RTC API. The
problem with that was that the RTC API dlls are dlls written for C or C++. C and C++ are
unmanaged languages. This means that whenever an object is created by these languages
it is the programmer’s responsibility to allocate and free the memory managed by that
object. On C#, similar to Java, the run-time enviroment is responsible for this activity.
Therefore, running C or C++ code from C# program externally becomes a problem. In
order to do so one has to compile the C dll into semi-C# dll, and than create an interface
inside his program for each object and method used from C.
As we saw this would be to much of a problem, we decided to abandon the idea of
running the client from ipaq and stay with a laptop.
Bibliography and References

  1.   Comnet project - Magma Group Communication
  2.   Comnet project - Wireless location
  3.   A JAIN-SIP Instant Messaging Client for the People
  4.   Placelab
  5.   SIP tutorial from
  6.   Postgre SQL.
  7.   Almanac - Java JDBC examples
Appendix 1 Jain SIP Stack


• SIP is an IETF specification that has been adopted by the communications
industry in the form of 3GPP, 3GPP2, OMA and ITU.
• The IETF specification defines the SIP protocol in text format
• The SIP Community holds various interoperability events to ensure the credibility of the
• As a developer you are free to implement the protocol in any language, hence define
your own interface for accessing the defined behavior of the protocol as outlined by the
IETF standard.
• While IETF specification ensures interoperability between stacks, it doesn’t address
interoperability of applications across stacks.
• JAIN SIP satisfies this need in the Java programming language. It ensures true
interoperability in that by utilizing the JAIN SIP specification you have interoperability
between stacks and the interoperability of applications across stacks, often referred to as
application portability.
– Both stack interoperability and application portability are required in this new age of
communication standards.

• Designed for developers who require powerful access to the SIP protocol.
• JAIN SIP can be utilized in a user agent, proxy, registrar or imbedded into a service
• JAIN SIP supports the SIP protocol functionality described in RFC
• JAIN SIP the following SIP extensions;
– RFC 2976 allows for the carrying of session related control information that is
generated during a session.
– RFC 3262 provide information on progress of the request processing.
– RFC 3265 the ability to request asynchronous notification of events.
– RFC 3311 allows the caller or callee to provide updated session information before a
    final response.
– RFC 3326 the ability to know why a SIP request was issued.
– RFC 3428 allows the transfer of Instant Messages.
– RFC 3515 requests that the recipient refer to a resource provided in the request.

SipStack Interface

• Manages Listening Points and Providers.
• SipStack associated with an IP address.
─ Can have multiple Listening points.
• Application can have multiple SipStacks.
• Cannot be deleted once created.
• Instantiated by the SipFactory and initialized with a property set.
• ‘javax.sip.*’ properties are reserved and names defined for stack configuration
• Defines retransmission settings.
• Defines router information.

• JAIN SIP provides a convenience function that ensures all retransmissions are handled
by the JAIN SIP implementation.
– Reduces complexity for applications acting as user agents.
– Reduces complexity for integrating JAIN SIP as a base implementation
for a SIP Servlet container or a JAIN SLEE implementation.
• Configured via Java properties on the SipStack Interface.
– Default is off.
• The default handling of message retransmissions in JAIN SIP is
dependent on the application.
– Stateful proxy applications need not be concerned with retransmissions as these are
handled by JAIN SIP.
– Typically User Agent applications must handle retransmissions of ACK’s and 2xx

Stack Properties
– Sets the IP Address of the SipStack. This property is mandatory.
– Sets a user friendly name to identify the underlying stack implementation. This
property is mandatory.
– Sets the outbound proxy of the SIP Stack.
– Sets the fully qualified classpath to the application supplied Router object that
determines how to route messages before a dialog is established.
– This configuration value informs the underlying implementation of supported extension
methods that create new dialog's.
– A helper function for User Agents that enables the stack to handle retransmission of
ACK Requests, 1XX and 2XX Responses to INVITE transactions for the application.

SipProvider Interface

• Register a SipListener to the SipProvider.
– Notifies registered Listener of Events
• De-register a SipListener from the SipProvider.
– Once de-registered, no longer receive Events from SipProvider.
• Client and Server Transaction creation methods.
– For sending Request and Response messages statefully.
• CallIdHeader creation method.
• Send Requests and Responses statelessly.
• Listening Point manipulation methods.
– Only one provider per listening point.

Responsibilities of JAIN SIP.
• Provide methods to format SIP messages.
• The ability for an application to send and receive SIP
• Parse incoming messages and enable application access
to fields via a standardized Java interface.
• Invoke appropriate application handlers when protocol
– Message arrivals and Transaction time-outs
• Provide Transaction support and manage Transaction
state and lifetime on behalf of a user application.
• Provide Dialog support and manage Dialog state and
lifetime on behalf on a user application.

SipListener Interface

• A single SipListener per SipStack which implies a single
Listener in the architecture
– All SipProviders associated to a Sipstack have the same
• Process Request's either statefully or statelessly
dependent on application logic.
• Process Response's to a recently sent Requests statefully.
• Process Transaction timeouts and retransmits Timer
    –   Transaction processing notifications

Responsibilities of the Application
• Application registers an implementation of the SipListener
interface to interact with the SIP Stack.
• Application must register with the SipProvider for all
messaging capabilities with the stack.
– Application requests transactions for stateful messaging.
– Application sends stateless messages.
– Access stack objects.
• Application receives messages from the stack as Events via
the SipListener interface.
Event Model

• The architecture is developed for the J2SE environment therefore is event
based utilizing the Listener/Provider event model.
– There is a direct reference between the event provider and event consumer
– Event consumer must register with the event provider
• Events encapsulate incoming Requests and Responses.
• Event Model is one way i.e. Application doesn’t send out events, it sends
out messages.
• The event model is asynchronous in nature using transactional identifiers to
correlate messages.
• The SipListener represents the event consumer and listens for incoming
Events that encapsulate messages that may be responses to initiated
dialogs or new incoming dialogs.
• The SipProvider is the event provider who recieves messages from the
network and passes them to the application as events.

• General package
– Defines the architectural interfaces, the transaction and
dialog interfaces and the event objects of the specification.
• Address package
– Address package contains a generic URI wrapper and
defines SIP URI and Tel URIs interfaces.
• Message package
– Defines the interfaces necessary for the Request and
Response messages.
• Header packages
– Header package defines interfaces for all the supported
headers and extension headers

JAIN SIP defines four different factories each with respective
responsibilities, namely:
• SipFactory
– This interface defines methods to create new Stack objects and
other factory objects.
• AddressFactory
– This interface defines methods to create SipURI’s and
• HeaderFactory
– This interface defines methods to create new Headers objects.
• MessageFactory
– This interface defines methods to create new Request and
Response objects.


Messages and Headers

• There are two type of messages in SIP, which JAIN SIP defines as
– Request messages are sent from the client to server.
• They contain a specific method type that identifies the type of Request.
• A Request-URI which indicates the user or service to which this request is
being addressed.
– Response messages are sent from server to client in response to a
• They contain a specific status code that identifies the type of Response.
• A Request-URI which indicates the user or service to which this request is
being addressed.
• A reason phrase that is intended for the human user.


• Messages may contain multiple Headers of the same type.
– The Headers of a given type within a message is significant, i.e. Headers
which are hop-by-hop must appear before any Headers which are end-to-end.
• A Message Body may contain a session description.
– JAIN SIP defines this format an Object which allows the body to be a String or
an Object type defined the Session Description Protocol (SDP) JSR
specification and also a byte array.

Request Message Types

The following request messages are defined by the core SIP

– Invites a participant to a session
– Ends a client’s participation in a session
– terminates a transaction
– Queries a participant about their media capabilities
– For reliability and call accepta nce (3-way handshake)
– Informs a SIP server about the location of a user

Request Message Types

The following request messages are defined by various SIP

– Session related control information generated during a session.
– For reliability of provisional responses.
– Update a session without impacting the state of a dialog.
– Request notification from remote nodes when certain events occur.
– Notification from remote nodes when certain events occur.
– For sending instant messages.
– Refer to a resource provided in the request.


• SIP headers are similar to HTTP headers fields in both syntax and
• JAIN SIP models each SIP header as a specific interface as opposed
to have a single generic interface to handle all header information.
– Each interface specifies the Headers acceptable parameters.
– More explicit protocol support – parsing support for each header.
• JAIN SIP supports all the headers defined in RFC 3261 and other
headers introduced by supporting the following additional RFC's:
– RFC3262 - RAckHeader and RSeqHeaders for the reliable delivery of
provisional responses.
– RFC3265 - AllowEventsHeader, EventHeader and
SubscriptionStateHeader to support the event notification framework.
– RFC3326 - ReasonHeader to support information on why the request was
– RFC3515 - ReferToHeader to support recipients to refer requests to
another resource

JAIN SIP Extensible by Design
• SIP Extensions described in internet drafts and RFCs typically
– New SIP Methods
• New dialog creating methods
– New SIP Headers.
• JAIN SIP defines an extensible framework to support new headers
standardized for SIP:
– New SIP methods can be set using the string method field of a
– An application informs the stack of dialog creating methods, by
specifying the method name to the EXTENSION_METHOD
property of the SipStack configuration.
• JAIN SIP defines an extensible framework to support new headers
standardized for SIP:
– Defines a ExtensionHeader interface that contains the header
name and header value attribute pair.
– Can be created and accessed by name.
A SIP transaction consists of a single request and any responses to that request.

Transaction Support

• JAIN SIP standardizes the interface to the generic transactional model defined
by the SIP protocol
– JAIN SIP models both Client and Server Transactions as Interfaces.
• Transaction is created on incoming Request or may be created to send
outgoing request.
– When a Request is sent out statefully, application must request a ClientTransaction
– When a new Request arrives, application determines whether to handle request via
a ServerTransaction
– When a Request in an existing dialog arrives the stack automatically associates it to
a ServerTransaction
• When a response arrives, the Stack possibly associates a previously created
ClientTransaction with the response
– May be stray
• Messages are passed to the SipProvider in order to generate a new
transaction. This transaction can be used to send the message onto the
• Implementation manages the association between Transactions and Dialogs.
Dialog Support

• A Dialog is a peer to peer association between communicating SIP
– The dialog represents a context in which to interpret SIP messages.
• Dialogs are never directly created by the Application.
– Dialogs are established by Dialog creating Transactions (INVITE,
SUBSCRIBE…) and are managed by the stack.
• Dialog deletion may be under application control.
– Though not generally recommended.
• Dialogs are used to maintain data needed for further message
transmissions within the dialog
– Route Sets, Sequence Numbers, URI’s of the parties in the dialog.
• Dialogs have a state machine
– Early, Confirmed, Completed and Terminated.
• Transactions may belong to a Dialog
– Dialog state changes as a result of changes in Transaction State.
– Access to dialog functionality from the transaction interface.
Appendix 2 Placelab

Place Lab: Device Positioning Using Radio Beacons in
the Wild
Anthony LaMarca1, Yatin Chawathe1, Sunny Consolvo1, Jeffrey Hightower1, Ian
Smith1, James Scott2, Tim Sohn3, James Howard4, Jeff Hughes4, Fred Potter4, Jason
Tabert5, Pauline Powledge1, Gaetano Borriello4, Bill Schilit1
1Intel Research Seattle 2Intel Research Cambridge
3Department of Computer Science, UC San Diego
4Department of Computer Science & Engineering, University of Washington
5Information School, University of Washington
Abstract. Location awareness is an important capability for mobile computing.
Yet inexpensive, pervasive positioning—a requirement for wide-scale adoption
of location-aware computing—has been elusive. We demonstrate a radio
beacon-based approach to location, called Place Lab, that can overcome the
lack of ubiquity and high-cost found in existing location sensing approaches.
Using Place Lab, commodity laptops, PDAs and cell phones estimate their
position by listening for the cell IDs of fixed radio beacons, such as wireless
access points, and referencing the beacons’ positions in a cached database. We
present experimental results showing that 802.11 and GSM beacons are
sufficiently pervasive in the greater Seattle area to achieve 20-30 meter median
accuracy with nearly 100% coverage measured by availability in people’s daily
1 Introduction
Allowing users to discover and communicate their positions in the physical world has
long been identified as a key component in emerging mobile computing applications
[13]. Dozens of research and commercial location systems have been built using
sensing technologies including ultrasonic time-of-flight, infrared proximity, radio
signal strength and time-of-flight, optical vision, and electro-magnetic field strength.
There have been many research and commercial efforts to improve accuracy and
precision, shrink the size of the sensing hardware, simplify deployment and
calibration of sensors, and provide more convenient middleware.
Despite these efforts, building and deploying location-aware applications that are
usable by a wide variety of people in everyday situations is arguably no easier now
than it was ten years ago. First and foremost, current location systems do not work
where people spend most of their time; coverage in current systems is either
constrained to outdoor environments or limited to a particular building or campus
with installed sensing infrastructure. Applications like location-aware instant
messaging fall flat if they only work for a fraction of users or only during a fraction of
a user’s day.
Second, existing location technologies have a high cost of entry to both users and
application developers. Many location systems require expensive infrastructure,
calibration, or special tags, beacons, and sensors. The privacy cost to the
many stakeholders is also typically ignored or considered only after deployment.
These barriers leave location-aware computing in an unfortunate cycle: There are very
few users due to a dearth of applications; developers are not interested in writing
applications for nonexistent infrastructure; infrastructure investments are based on
user demand, of which there is little. This cycle has not prevented researchers from
prototyping and innovating in the application space. It has, however, prevented the
widespread experimentation and adoption of these applications by real users. The
result is that while we can give compelling demonstrations of location-based
applications, few can be used in the places they are most useful: where we live, where
we socialize, where we shop.
Place Lab addresses both the lack of ubiquity and the high-cost of entry of existing
approaches to location. Place Lab is a fundamentally different philosophy compared
to previous work because we focus on A) maximizing coverage as measured by the
percent of time location fixes are available in people’s daily lives and B) providing a
low barrier to entry for users and developers. The Place Lab approach is to allow
commodity hardware clients like notebooks, PDAs and cell phones to locate
themselves by listening for radio beacons such as 802.11 access points (APs), GSM
cell phone towers, and fixed Bluetooth devices that already exist in the environment.
These beacons all have unique or semi-unique IDs, for example, a MAC address.
Clients compute their own location by hearing one or more IDs, looking up the
associated beacons’ positions in a locally cached map, and estimating their own
position referenced to the beacons’ positions.
In this paper we show that existing radio beacon sources are sufficiently pervasive
and can be mapped appropriately to meet Place Lab’s goal of maximizing coverage in
most people’s daily lives. For example, Place Lab clients already have access to over
2.2 million mapped beacons situated in numerous cities and mechanisms are in place
to scale well beyond this number. This paper will also show how Place Lab’s use of
commodity hardware and commitment to user’s privacy lowers the cost of entry to
users and how the high beacon coverage combined with flexible programming
interfaces lowers the cost of entry for developers.
Precision of the location estimates, while important, is secondary to coverage,
privacy, and cost in Place Lab. That is, we believe it is important to model location
uncertainty and minimize it to the extent possible without requiring custom hardware
or limiting the operation to controlled environments. This philosophy is similar to
how ubiquitous wireless infrastructure remade telephony into an indispensable
everyday tool. A cell phone with tremendous voice quality that only works in only
one building has quite different affordances than one with passable voice quality that
works almost everywhere. The former tends to lend itself to more niche problems
like office automation while the latter finds a home in the hands of anyone who wants
to socialize and conduct business throughout their daily activities. Although accuracy
is not the primary concern in the Place Lab philosophy, it is clearly important to
evaluate and understand the accuracy of a beacon-based approach to location.
Therefore, this paper also presents experiments characterizing the accuracy of the
Place Lab approach as it relates to the types and densities of beacons in the
Place Lab is released under an open source license. Binary and source releases for
many platforms, as well as sample radio traces can be downloaded from Adoption of Place Lab has been encouraging; as of October
2004 our system has seen around 500 downloads per month and a number of
researchers are using Place Lab as a component of their projects.
This paper has three parts. First, we introduce the Place Lab architecture and show
how it achieves the coverage and ease-of-use goals. Second, we present several
experimental results quantifying the important relationships between beacon types,
coverage, density, and accuracy. Finally, we discuss the future research problems and
opportunities. This paper reports on the research contributions following the course
laid out in our challenge paper which proposed using 802.11 beacons to create a
global location system [11]. Specifically, we have designed a software architecture to
make general beacon-based location a reality, implemented a system supporting
multiple platforms and multiple beacon technologies, released the software through
the open source community, and conducted coverage and accuracy experiments in the
real world.
2 Related Work
Noticing the benefits afforded by high coverage and availability of a mobile service is
not a new observation. Modern cellular telephone service providers stake their
business on it. Moreover, many cellular providers are even starting to compute and
offer the locations of the devices on their network as part of a push to branch out
beyond basic telephony services. Separately, the Global Positioning System (GPS) is
a location system which was designed to maximize coverage. Unfortunately neither
cellular phone location nor GPS (nor any of the existing research location systems)
provide both maximal coverage measured by percent of time that location fixes are
available in people’s daily lives and an extremely low-barrier to entry for users and
GPS works world-wide and GPS capability can be added to existing devices using
a variety of external dongles, cards, and corded accessories. The basic GPS scheme
provides median accuracy of 10 meters, and various augmentation schemes have been
added to improve this. GPS could be said to meet goal B of Place Lab in that it
provides a relatively low barrier to entry (although an external card and antenna is
still an additional cost over current commodity hardware). However, GPS fails to
meet Place Lab’s coverage goal because GPS receivers, while having high availability
as measured by the percent of the earth’s surface covered, have poor coverage
measured by the percent of time they work where most people spend most of their
time. GPS receivers require a clear view of the sky and thus they do not work indoors
or under cover. They also work poorly in many cities where the so called ―urban
canyons‖ formed by tall buildings prevent them from seeing enough satellites to get a
position lock. This limited availability severely constrains the class of applications
for which GPS is an appropriate location technology. GPS is appropriate for and has
been used successfully in navigation, tourism and search and rescue applications
which primarily happen outdoors. Most individuals, however, spend the vast majority
of their day indoors so day-to-day applications that rely on GPS location alone would
have stretches lasting hours in which no changes in location would be reported. We
present experimental results to verify this claim in Section 5.
Cell-phone companies have long been able to track phone users with network
techniques like time-of-arrival or signal strength and handset techniques like assisted
GPS that combine handset GPS receivers with network servers to assist in location
calculation. E911 Phase II legislation in the US requires cell phone companies to be
able to locate handsets within 150 meters by Dec 31, 2005. E112 initiatives in Europe
are similar. Some cellular service providers have begun using the knowledge of
handset location to offer users location-based services and applications. An example
is AT&T Wireless’ Friend Finder that is part of their mMode services. E911-like
location services meet Place Lab’s goal of high coverage since they work wherever
normal cell phones do, but their success in providing a low barrier to entry is less
encouraging. While Place Lab clients compute their own location, cellular carriers
estimate a phone’s location in the network and sell that information back to the user
for a fee. The current fees of around $1 US per query substantially limit the
application domains for which users will be willing to access these services.
Furthermore, provider-driven location works only on cell phones whereas Place Lab
can present the same location programming interfaces on phones, notebooks, and
PDAs using any radio beacon technology.
A variety of previous device positioning systems use 802.11 access points as
beacons from which to estimate location. The RADAR system showed that 1.5 meter
accuracy could be obtained by constructing a detailed ―radio fingerprint‖ of the
available 802.11 access points and how strongly they could be heard along a one foot
by one foot grid within an office building [3]. Ekahau ( sells a
commercial software product that does very much the same thing with similar
accuracies. These systems differ from Place Lab in two ways. First, products like
Ekahau do not ship with any radio maps and require that the user collect this data
himself. This violates our barrier-to-entry goal that a system can estimate location
right out of the box. Second, deployment of these systems is only feasible in small
environments (places measured in square meters, not square kilometers) due to the
large amount of calibration data that needs to be collected and maintained. In contrast,
Place Lab uses sparser calibration data that can be collected while walking or driving
and is contributed by a community of users (and for this coverage and ease of
mapping, Place Lab concedes an order of magnitude loss in accuracy as later
experimental results will show).
Other similar systems that use specific radio sources in the environment include
RightSpot and Laasonen et al’s GSM based system. RightSpot showed that 15
kilometer accuracy could be obtained by using FM radio station strengths to predict
location on a smart wrist watch device [6]. Laasonen et al. use changes in the set of
nearby GSM cell towers to construct an abstract graph of places where the user goes
Finally, there are numerous indoor location system that make use of ultrasonic [10,
15], infrared [12], ultra-wideband radio ( These systems all require that
hardware infrastructure be installed in the environment to be monitored. These
systems are generally expensive, costing thousands to tens of thousands of US dollars
for a 1000 m2 installation. These systems primarily focus on optimizing accuracy
rather than wide-scale deployment and have accuracies in the 5-50 centimeter range.
They have coverage constrained to a room, building, or campus environment. While
this availability is sufficient for many home or office scenarios, limited coverage rules
out many personal and social applications targeted at people’s daily lives.
A wide variety of applications have been developed that utilize location-based
technologies. Without having to disclose their location to others, users can run
navigation-oriented applications that display their location on a map, highlight local
points of interest, or plot a route to a destination based on current location
(, Users that are comfortable disclosing their
location to their social network have access to applications like and
mMode’s Friend Finder ( that facilitate social interactions in
the physical world. Finally, for users willing to disclose location information to
institutions, useful day-to-day services like Yahoo Yellow Pages ( and
Google’s Local Search ( are available to anyone with a network
3 The Place Lab Architecture
The Place Lab architecture consists of three key elements: Radio beacons in the
environment, databases that hold information about beacons’ locations, and the Place
Lab clients that use this data to estimate their current location (See Figure 1). In the
following subsections, we describe each of these elements and how they are designed
to help meet Place Lab’s goals of maximal coverage of daily life and low barrier to
entry for users and developers.
3.1 Radio Beacons
Place Lab works by listening for the transmissions of wireless networking sources
like 802.11 access points, fixed Bluetooth devices, and GSM cell towers. We
collectively call these radio sources beacons. They all employ protocols which assign
beacons a unique or semi-unique ID. Hearing this ID greatly simplifies the client’s
task of calculating their position. As we will show in Section 5, the coverage and
accuracy of Place Lab is dependent on the number and type of beacons in range of the
client device. Fortunately, wireless networking infrastructure is being deployed at a
rapid pace in places that users spend their time. Most developed areas of the world
have GSM coverage and cities and towns are becoming blanketed with 802.11 access
Place Lab devices need only interact with radio beacons to the extent required to
learn their IDs. Place Lab clients do not need to transmit data to determine location,
nor do they listen to other user’s data transmissions. In the case of 802.11, receiving
1 Our measurements in downtown Seattle, for example, show an 802.11b density of 1200
access points per km2
beacons can be done entirely passive by listening for the beacon frames periodically
sent by access points. These beacon frames are sent in the clear, and are not affected
by either WEP or MAC address authentication. Other technologies like Bluetooth
require clients to initiate a scan in order to find nearby beacons. Due to restricted
programming interfaces, detecting GSM cell IDs requires handsets to associate with
nearby cell towers as they normally do when carried around and not on a phone call.
3.2 Beacon Databases
Place Lab has a critical dependence on the availability of beacon locations; if
Place Lab knows nothing about a beacon, being in range does not improve our
location estimates. In our architecture, the beacon database plays the important role
of serving this beacon location information to client devices. We allow there to be
multiple beacon databases and we do not specify whether beacon databases are
private or public, how clients authenticate with a database or how many databases a
client should load data from.
Many of these beacon databases come from institutions that own a large number of
wireless networking beacons. Organizations like companies, universities and
departments often know the locations of their 802.11 access points since this
information is commonly recorded as part of a deployment and maintenance strategy.
These data sets tend to be on the order of tens or hundreds of access points, and the
maps are typically quite accurate. While these data sets were not originally built for
doing beacon-based location estimation, it only requires a format-translation step to
add this data to Place Lab and location-enable the institution’s building or campus.
Other sources of Place Lab mapping data are the large databases produced by the
war-driving community. War-driving is the act of driving around with a mobile
computer equipped with a GPS device and a radio (typically an 802.11 card but
sometimes a GSM phone or Bluetooth device) in order to collect a trace of network
Place Lab Client
Radio beacons
War drivers and other
data contributors
Beacon databases
spotter Mapper
Fig.1. Key components in the Place Lab architecture
availability2. War-driving has become hobby for many radio enthusiasts and groups of
war-drivers have formed online and offline clubs to share and pool their trace data.
Each war-driving trace is a time-coded sequence of records containing the latitude
and longitude of where the record was taken, as well as the list of radio sources and
associates signal strengths that could be heard at that time. By pooling their war
drives together and applying some simple averaging, these groups have produced
estimated locations for millions of beacons. Public domain war-driving software has
been developed for most computing platforms, and there are many aggregation
websites to which war-drives can be submitted. While war-driving has traditionally
been performed in order to provide information about where nearby network access
can be obtained, Place Lab uses these maps in reverse to infer where we are given a
particular beacon is nearby.
Since the positions of beacons are being inferred from observations tied to GPS
estimates, war-driving databases only contain estimates of beacons’ positions. The
error in these estimates translates into a decrease in the accuracy of location estimates
made by Place Lab. However, what these databases lack in accuracy they make up for
in coverage making them highly useful for Place Lab. As an example, is the
largest of the 802.11 war-driving repositories, and contains over 2 million known AP
positions, and the recent ―World Wide War-drive‖ added 275,000 new access points
over an 8 day period (
At this time, Place Lab clients have access to location information for
approximately 2.2 million radio beacons, primarily 802.11 access points. These
mostly come from, but we have more accurate databases for UC San Diego
and the University of Washington as well as some GSM tower locations imported
from the FCC’s database. To allow us to experiment with beacon placement
algorithms, we also maintain our own database that currently has location estimates
for around 40,000 GSM, 802.11, and Bluetooth beacons.
3.3 Place Lab clients
The Place Lab clients use live radio observations and cached beacon locations to form
an estimate of their location. To make client both extensible and portable, client
functionality is broken into three logical pieces: spotters, mappers and trackers.
Spotters are the eyes and ears of the client and are responsible for the observing
phenomenon in the physical world. Place Lab clients typically instantiate one spotter
per radio protocol supported by the device. As an example, a laptop running Place
Lab might have a Bluetooth and an 802.11 spotter, while a cell phone might run a
Bluetooth and a GSM spotter. The spotter’s task is to monitor the radio interface and
share the IDs of the observed radio beacons with other system components.
An observation returned by a spotter is of little use if nothing is known about the
radio beacons. The job of the mapper is to provide the location of known beacons.
2 The term war-driving is an allusion to the 1983 movie ―WarGames‖ where Matthew
Broderick’s character David engaged in war-dialing by sequentially dialing blocks of
numbers in an attempt to discover and establish a modem connection with interesting
This information always includes a latitude and longitude, but may also contain other
useful information like the antenna altitude, the age of the data, a learned propagation
model, or the power of the transmitter. Mappers may obtain this data directly from a
mapping database, or from a previously cached portion of a database. This cache can
contain beacons for a large area, say the entire United States and Europe, or may, due
to capacity concerns, just contain information for a single city.
The tracker is the Place Lab client component that uses the streams of spotter
observations and associated mapper data to produce estimates of the user’s position.
The trackers encapsulate the system’s understanding of how various types of radio
signal propagate and how propagation relates to distance, the physical environment
and location. Trackers may use only the data provided to them by the spotter and
mapper, or may use extra data like road paths and building locations to produce more
accurate estimates. As an example, Place Lab includes a simple tracker that computes
a Venn diagram-like intersection of the observed beacons. This tracker uses very few
resources making it appropriate for devices like cell phones. Place Lab also includes a
Bayesian particle filter [1] tracker that can utilize beacon-specific range and
propagation information. While computationally more expensive, the Bayesian
tracker provides about a 25% improvement in accuracy and allows Place Lab to infer
richer information like direction, velocity and even higher level concepts like mode of
transportation (walking, driving, etc.). For more information on the intricacies and
advantages of using probabilistic Bayesian filters in location systems, see Hightower
et al. [5] and Patterson et al. [9].
3.4 Privacy
Privacy issues have had a strong influence on the design, implementation and use of
Place Lab. Place Lab’s key privacy principle is that devices should be able to
position themselves based on passive monitoring of the environment. This principle
gives the user control over when their location is disclosed, laying the foundation for
privacy-observant location-based applications. Unfortunately, while it is theoretically
possible to construct a device that senses GSM, 802.11, and Bluetooth passively,
current devices are not as passive as we would like. For example, some 802.11
device drivers broadcast their existence to the infrastructure regularly. Similarly, we
are not aware of any GSM cell phone that does not report itself to the infrastructure.
Although the Bluetooth standard does not require that a device transmit its MAC
address to neighboring devices when scanning, many of today’s Bluetooth devices do
so anyway.
Apart from passive scanning issues, another privacy trade-off is the manner in
which mapping data is downloaded to clients from the mapping databases. Due to
capacity issues, impoverished devices may only be able to load a small portion of the
mapping database. However, if mapping data is downloaded for a small region, say a
neighborhood, the operator of a mapping database has a reasonably fine-grained
estimate of a user’s location or potential location. Loading (and possibly discarding
most of) a country or continent’s worth of beacon locations gives the mapping servers
less information about a user’s location.
The war-drivers submitting their traces also have privacy considerations. Wardrivers
who submit their logs may not want a permanent record kept of the path they
take while collecting a log. An approach to mitigating this problem is to have trusted
entities anonymize and aggregate logs. For example, Place Lab has a design for a
distributed backend database that slices up logs on a per-beacon basis and randomly
distributes information about each beacon to a different node. Using this scheme, a
contributor’s war-driving path cannot easily be reconstructed yet the log is still useful
for mapping. Of course any approach involving a trusted-entity still relies upon users
trusting that entity.
Finally, we consider the privacy issues that affect the owners of the beacons used
by Place Lab. Cell phone providers, coffee shops, and hotels probably do not mind if
the existence and location of their network beacons are known. Individuals and
corporations, however, may be wary in some cases of having information about their
access points listed in a public database. They may be concerned about people
attempting to steal network access or about revealing that they have computer
equipment at a particular location. There are a variety of potential ways to mitigate
these concerns. 802.11 and Bluetooth beaconing can be manually turned off, making
them invisible to Place Lab. As stronger authentication becomes available for
wireless networks, some concern about beacon visibility may simply disappear.
Finally, there are possibly technical solutions to protecting beacon owners privacy in
Place Lab such as using an encrypted hash of beacon identifiers so that clients must
actually hear a beacon to resolve the true ID.
4 Implementation and Applications
With the exception of the small amount of native code that is written for each spotter,
Place Lab is written entirely in Java 2 Micro Edition (J2ME). Place Lab currently runs
on the following platforms and provides support for spotting the following beacon
types. In addition, all platforms can access GPS devices for location and war-driving.
Systems Architectures 802.11abg
Windows XP x86 ● ●3 ●
Linux x86, ARM, XScale ●
Os X Power PC ●
Pocket PC 2003 ARM, XScale ● ●3 ●
Symbian Series 60 cell phones ● ●
The Place Lab APIs for spotters, mappers, and trackers are consistent across all
platforms assisting developers in porting their applications to different platforms, e.g.
from a full-featured laptop to a cell phone. To further facilitate low-effort
3 Place Lab supports GSM beacons on these platforms using a Bluetooth data connection
to a
paired Series 60 phone which actually receives the GSM beacons and forwards them to
master device.
development, Place Lab supports five ways of communicating location information to
1. Direct Linking. Applications may link against the Place Lab Java library and
invoke a single method to start the location tracking service.
2. Daemon. For lighter-weight interactions, Place Lab can be run in daemon mode
and applications can query Place Lab via HTTP. This HTTP interface allows
programs written in most languages and styles to use Place Lab.
3. Web Proxy. Place Lab supports location-enhanced web services by augmenting
outgoing HTTP requests with extension headers that denote the user’s location. By
setting their web browser to use the Place Lab daemon’s web proxy (in the same
way one uses a corporate firewall’s proxy), web services that understand our HTTP
headers can provide location-based service to the user.
4. JSR 179. To support existing Java location-based applications Place Lab supports
the JSR 179 Java location API [2].
5. NMEA 0183. Place Lab provides a virtual serial-port interface that can mimic an
external GPS unit by emitting NMEA 0183 navigation sentences in the same
format generated by real GPS hardware.
Several applications have been developed by both us and the Place Lab user
community; we describe four of them below to illustrate the varied ways in which
applications can interact with Place Lab.
• Topiary. Topiary is a rapid prototyping tool developed at UC Berkeley for
designing location-enhanced applications [8]. A Topiary prototype can be run on
one mobile device while the designer monitors the user’s interactions from a
second mobile device (Figure 2 is a screenshot of Topiary). In this mode, the user’s
location is determined Wizard-of-Oz-style by having the designer click the user’s
current location on a map. Topiary has been augmented to allow the designer to
replace these Wizard-of-Oz estimates with live estimates from Place Lab running
on the user’s device. Topiary is using Place Lab as a GPS replacement, with the
advantage that unlike GPS, Place Lab works both indoors and out.
• The PlaceBar. We have developed a demonstration application called the
Fig. 2. A screenshot of Topiary, a prototyping tool for location-aware
applications. Topiary uses Place Lab to allow the prototypes to use live location
PlaceBar that uses a browser toolbar to manage a user’s interactions with Google’s
location-based search: In addition to the query terms,
Google Local accepts an address, or latitude and longitude and the results are
filtered to return pages relevant to nearby places. Google determines page location
by extracting information like addresses and phone numbers from the page content.
When a query is performed in the PlaceBar, the user’s location is obtained from
Place Lab and is automatically used as the location for the query.
• A2B. A2B is an online catalog of web pages that allows users to add new geocoded
pages or query for nearby relevant pages ( A2B can be
queried by either manually entering a location or using a custom client that talks to
a GPS unit. A2B extended their interface to support HTTP requests from by clients
running the Place Lab web proxy. Devices running the Place Lab proxy can now
talk directly to A2B in any web browser and automatically use their location-based
lookup service.
• Active Campus. The Active Campus project is one of the most widely used
802.11-based location-enhanced systems [4]. Active Campus offers a suite of
socially-oriented applications to students and classmates on the UC San Diego
campus. The Active Campus project is currently porting their application suite to
run on top Place Lab. The portability of Place Lab offers them more platforms
than the small number that are currently supported. The large beacon database also
offers them expanded coverage off campus in the surrounding cities.
5 Experimental Results
The coverage and accuracy of Place Lab depend on the number and mix of beacons in
the environment, making it difficult to make absolute statements about the system’s
performance. However, certain high-level statements about the Place Lab approach
are appropriate. First, due to the correlation of 802.11 and GSM beacon density with
population density, Place Lab works better in urban centers than in less populated or
rural areas. Second, Place Lab has better coverage in areas with ubiquitous GSM like
Europe compared to partially covered areas like the United States. To quantify both
the coverage and accuracy of Place Lab and how they vary by area we ran two
experiments. First, to test our hypotheses about daily-life coverage of the different
beacon technologies we outfitted users with an ensemble of small devices capable of
monitoring GPS, GSM and 802.11 signals and had them carry the devices during their
regular day. Second, we measured both 802.11 beacon density and corresponding
Place Lab accuracy in an urban, a residential and a suburban area. Our coverage
results were not surprising: both our user-time experiment as well as our density
experiment show nearly ubiquitous GSM and 802.11 coverage whose density
correlates with population density. Our accuracy results show that with sufficient
density, 802.11 beacons alone can provide median accuracy of around 15-20 meters
while GSM beacons alone provide accuracy of 100-200 meters.
5.1 Experimental Setups
We define the coverage of a location-tracking technology to be the percentage of time
that the technology can produce a new estimate of the user’s position based on what it
senses from the physical world. If a GPS device, for example, has a satellite lock for
15 minutes and then loses its lock for the next 30 minutes and gets it back for 15
minutes, the coverage for that period would be 50% with an average gap of 30
minutes. Note that, consistent with the Place Lab philosophy, our formal definition of
coverage is based on the user’s time, not on geographic area.
To compare the coverage of GPS and the beacon technologies used in Place Lab,
we outfit three users with a set of three mobile devices each and asked them to carry
the devices throughout portions of a typical day. The devices included a Belkin
wireless GPS, a Nokia 6600 and an Intel Stargate [14]. We logged, once per minute,
the availability of GPS, 802.11 and GSM. All three devices were small enough to fit
in a purse or backpack and had enough battery life to run for several hours. For our
users we chose people from the authors’ social network. None were computer
scientists or students and the user’s jobs included retail clerk, immunologist and a
home maker. Between the three users we collected more than 30 hours of logs (10 for
each of GSM, GPS and 802.11) that included work days as well as non-work days.
Based on these logs, computing the coverage and coverage gaps of the various
technologies was a straightforward task.
For the second experiment measuring beacon density its effect on accuracy, we
gathered GPS, 802.11 and GSM trace data from three diverse areas:
• Downtown Seattle – a mix of commercial and residential urban high-rises
• Seattle’s Ravenna neighborhood – a medium-density residential neighborhood
• Kirkland, Washington – a sparse suburb of single-family homes
For each locale, we drove around the areas for sixty minutes with a laptop, a GPS
unit, and a Nokia 6600 cell phone. 802.11 scans were performed at 4Hz using an
Orinoco 802.11 interface in the laptop. GPS readings were taken at approximately
1Hz using an external serial GPS unit. Finally, the GSM measurements were taken at
1Hz by the Nokia 6600 and relayed to the laptop via Bluetooth4. At all times we tried
to navigate within areas in which GPS lock would not be lost as GPS forms the
―ground truth‖ location to be used to estimate beacon positions and Place Lab’s
4 Unfortunately, our Nokia cell phones only allow us to know the ID of the current cell
with which the phone is associated, making it impossible to learn the full set of towers in
range. While this allows us to know if coverage is available, it does not let us learn about
density or Place Lab’s accuracy if all towers in range were known. Thus all GSM-based
Place Lab results are calculated using the single available cell ID.
5.2 Coverage Results
The results of our user-time coverage experiment are shown in the following table:
GPS GSM 802.1Test Subject 1
coverage avg. gap coverage avg. gap coverage avg. gap
Immunologist 12.8% 68 min 100% - 87.7% 1.6 min
Home maker 0.6% 78 min 98.7% 2 min 95.8% 1 min
Retail clerk 0% 171 min 100% - 100% -
Average 4.5% 105 min 99.6% 1 min 94.5% 1.3 min
In a real application, depending on the gap size it is often possible to apply
smoothing, dead-reckoning, or various heuristics to try to fill in the gaps sensibly.
This experiment ignores all gap-filling heuristics. Thus, we are not measuring the
percentage of time that the application can make a meaningful guess at the user’s
location, but rather the fundamental coverage of the lowest-level estimation
The coverage of GPS matched our expectations. It has poor user-time coverage
and long gaps because satellites are cut off indoors or under cover where many people
spend the vast majority of their time. Our subjects saw nearly ubiquitous GSM
coverage. This is not surprising because once wireless carriers choose to offer
coverage in an area, they strive to provide complete coverage. Even in places where
the signal level may be too low to make an actual phone call, for example in an
elevator or basement, it is still usually possible to see GSM beacons. The measured
802.11 coverage was slightly lower than GSM with similar gap sizes. From our data
we can draw two conclusions. First, this data supports our claims that beacon-based
location has the potential to provide user-time coverage which significantly exceeds
GPS and is possibly ubiquitous. Second, comparing the coverage and gap sizes of
GSM and 802.11 and assuming all other factors are equal, it seems GSM beacons are
the ideal radio technology for Place Lab. However, all factors are not equal and the
smaller cell sizes of 802.11 provide an opportunity for greater accuracy in Place Lab
as the results will show in the next subsection.
5.3 Density and Accuracy Results
To confirm our intuition that beacon densities are correlated to population densities,
we computed the distribution of the number of 802.11 access points in range per scan
for each of the three areas we measured. The three histograms and accompanying
satellite photos are shown in Figure 3. As expected, the highest density of APs were
seen in the downtown urban setting with an average of over 3 APs per scan, no scans
without APs, and a maximum of 15. Also not surprising, the suburban traces saw 0
APs (i.e. no 802.11 coverage) more than half the time and rarely saw more than one.
The most interesting result came from the residential Ravenna data in which AP
densities were higher than expected. With the exception of the approximately 10% of
scans with no coverage, the AP density distribution for Ravenna fairly closely
matched the downtown distribution. As we will explain shortly, the Place Lab
accuracy in Ravenna actually exceeded that of downtown.
To evaluate the accuracy of Place Lab in our three neighborhoods, we divided each
60 minute trace into two halves: training and evaluation. The training trace was used
to estimate beacon positions while the evaluation trace tests the accuracy of Place
Lab. During training, beacon positions were estimated by averaging together all
locations in which the beacon was observed. We then fed the evaluation trace into
Place Lab and computed the accuracy of its estimate using only 802.11, only GSM,
and fused 802.11 and GSM. To measure accuracy, the predicted estimates were
compared with an interpolation of the two GPS readings closest in time. Note that
GPS has an accuracy of 8-10 meters, bounding the accuracy of our measurements to
this level of granularity. The position estimate was computed using a Bayesian
particle filter tracker [5] with a sensor model that exploits the fact that observed signal
strength and beacon-frame loss rate correlate with distance. Per-beacon signal and
loss histograms are computed from the training data and these 50-100 bytes of
calibration data are stored with each beacon’s estimated position in the beacon
database. These per-beacon parameters allow our tracker to predict location more
accurately than our untrained models. The same technique works for both GSM and
802.11 beacons.
Ravenna (residentialDowntown (urban) ) Kirkland (suburban)
Percentage of Time
Number of 802.11 APs in Range
Downtown residential) Fig. 3. Density of 802.11 access points (and photos) for the
neighborhoods in which we ran
our experiments. For each area 7500 scans were performed at 250 ms intervals, while
along surface streets. For each scan we recorded the number of APs in range. Satellite
provided USGS through Microsoft’s Terraserver
The following table shows the results of our accuracy tests.
802.11 GSM 802.11 + GSM
accuracy coverage accuracy coverage accuracy coverage
Seattle (Urban) 20.5 m 100.0% 107.2 m 100.0% 21.8 m 100.0%
(Residential) 13.5 m 90.6% 161.4 m 100.0% 13.4 m 100.0%
(Suburban) 22.6 m 42.0% 216.2 m 99.7% 31.3 m 100.0%
Two conclusions can be drawn from the results in this table. First, for single types
of beacons, 802.11 outperforms GSM in accuracy although its coverage is worse in
areas with sparser population. That is to say, when 802.11 beacons are in range, Place
Lab’s predictions are more accurate than with GSM alone. Given their relatively long
range, GSM beacons play a high-coverage, low accuracy role in Place Lab. This
tradeoff stands to reason because 802.11 has smaller cell sizes (shorter radio range)
and, unlike GSM where cell placement is managed as a system to optimize coverage,
802.11 cells are deployed in small numbers by independent homeowners and
institutions. Second, fusing 802.11 and GSM provides a good blend of accuracy and
coverage. Consider the sparse suburban area of Kirkland where 802.11 coverage is
only 42%. In Kirkland, fusing with GSM yields 100% coverage (up from 42% with
802.11 alone) with only an 8.7 meter decrease in median accuracy, despite the 216.2
meter accuracy of GSM alone in Kirkland. To explain this result, recall from the
previous section that gaps in 802.11 coverage tend to be short. An effective location
estimation algorithm like a particle filter can model the user’s motion and allows
GSM beacons to effectively fill in the gaps without the error ballooning.
To investigate the relationship between beacon density and accuracy we combined
all data from the three areas and computed the median accuracy achievable by Place
Lab using 802.11 alone. Figure 4 shows a graph comparing the accuracy of Place Lab
as it relates to the number of unique beacons the client saw during the previous 10
second window. From this figure we can conclude that if 802.11 density is high
enough for clients to see at least 3 distinct beacons during a 10 second window, the
density is sufficient for Place Lab to achieve its ―peak‖ median accuracy of 15-20
meters or approximately twice the error of unassisted GPS.
5.4 Bluetooth
The beacon technology notably absent from our results is Bluetooth. We found that
non-mobile Bluetooth devices have not reached sufficient density where they are
eminently useful for beacon-based location estimation in the wild. (Place Lab only
looks for Bluetooth beacons likely to remain fixed such as printers, vending
machines, and access points; we ignore nomadic Bluetooth devices like personal cell
phones or laptops since their unpredictable mobility makes them harder to use to
predict location.) Although our results do not report Bluetooth beacon densities, we
did scan for them during our data collection and we saw virtually no fixed Bluetooth
in any of the test locales. The sparseness of Bluetooth beacons is further exacerbated
by the fact the each scan for nearby Bluetooth beacons takes approximately 10
seconds to complete. At this slow scan rate, a mobile device even moving only at
human walking speed can miss a Bluetooth beacon it passes.
A simple experiment in our lab showed that due to their short radio range, fixed
Bluetooth devices do improve Place Lab’s accuracy. We deployed ten Bluetooth
devices in our 1000 square meter lab and showed a Place Lab accuracy of slightly
better than 10 meters using Bluetooth alone. This suggests that Bluetooth beacons
could be deployed strategically in small environments to somewhat improve the
client’s location accuracy while preserving the Place Lab model of client-side location
estimation with commodity devices.
6 Future Work
For many emerging location-aware applications it is much easier to utilize place
names like ―Bank‖, ―Starbucks‖ or ―Movie Theater‖, than geo-coordinates such as
(48.43456, -122.45678). We are developing techniques that allow Place Lab to
automatically learn and estimate places in addition to geo-coordinates. One step in
this process is moving Place Lab to ―2.5‖ dimensions. Place Lab currently only
generates position estimates in two dimensions (latitude and longitude) and ignores
the altitude component of location. This can present a problem in multi-story
buildings where floor number is likely a key aspect of location. Our current belief is
Fig. 4. This graph shows the effect AP density on Place Lab’s accuracy. The graph
includes all
22,500 measurements from the three neighborhoods measured. The accuracy line is
through the medians, while the error bars represent the 1st and 3rd quartile readings.
(50% of the
readings fall between the error bars.) The second line shows how often we saw that
number of
distinct APs
Median error (meters)
Distinct 802.11 APs in range in 10 second period
Percentage of time
1 2 3 4 5 6 7 8 9 10 11 ≥ 12
Median accuracy
Percentage of time
that generating ―2.5‖ dimension estimates in which altitude is represented with a
symbolic name such as ―Parking Level A‖ or ―3rd floor‖ are more meaningful than a
coordinate-based altitude like 34.6 meters above sea level. We are planning to
augment Place Lab to allow beacons and traces to be annotated with floor information
and have our trackers predict this symbolic dimension along with latitude and
We intend to remove the reliance on GPS as ground-truth for war-driving and
mapping new beacons. Given a map of a portion of the beacons, Place Lab should be
able to use its own location estimates to map new beacons that are encountered in the
environment. We plan to study the number of beacons which constitute a ―critical
mass‖ such that beacon trace logs without GPS can be used to grow and refresh the
client’s database as beacons are added, moved and decommissioned.
7 Conclusions
We believe that many emerging location-aware computing application are going to
require 100% availability of location information in real people’s lives, similar to the
way cellular phones are held to a 100% availability standard. Place Lab provides the
necessary features to move in this direction. In this paper we have shown that a
beacon-based approach to location can A) maximize coverage as measured by the
percent of time a location fix is available in people’s daily lives and B) offer a low
barrier to entry for users and application developers thanks to the use of commodity
hardware, privacy awareness, and straightforward interfaces.
Our coverage experiment confirmed the intuition that GPS, often thought of as a
pervasive location technology, in fact lacks availability in people’s daily lives since
people are frequently indoors or under cover, whereas 802.11 and GSM beacons are
frequently available both indoors and out. This experiment was conducted by logging
beacon availability using small recorders carried by people as they went about their
daily routines.
To evaluate beacon-based location, we examined 802.11 and GSM beacon density
and quantified the relationship between density and accuracy. In studying three
distinct neighborhoods of the greater Seattle area (urban, residential, and suburban),
we found that beacon density is sufficient to support the Place Lab approach.
Specifically, for 802.11 beacons we can conclude that if density is high enough for
client devices to see at least 3 distinct beacons during a 10 second window, Place Lab
clients can achieve median accuracy of 15-20 meters. This accuracy is lower than
GPS, but, unlike GPS, beacon-based location covers nearly 100% of users’ daily
lives. In the sparsely-populated suburban area we measured fusing 802.11 with GSM
readings results in median accuracy just over 30 meters.
We believe Place Lab is a useful artifact for the research community. Binary and
source releases of Place Lab are available for many platforms along with sample radio
traces at Adoption of Place Lab has already been
encouraging; our system sees around 500 downloads per month and a number of
research projects and web services are using Place Lab as a component of their
system. Place Lab is an enabling technology because it is useful for developers and
facilitates new research into location-aware computing such as exploring the meaning
of place and the studying the utility of location-aware applications that can be
deployed to real users.

To top