VIEWS: 42 PAGES: 56 POSTED ON: 7/16/2011
Student: Alex Geller Arie Abramovici Instructor: 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 http://comnet.technion.ac.il/~cn09s05/ 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 statistics. 1.4 Introduction to project concepts In this section we will quickly introduce the user to several concepts used in the book. 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 ICQ 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 them. 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 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. Triangulation (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 Client Control Controller Client Model RSSI Collection Location Distance Calcultaion Calculation Plugin Plugin SQL Database Database Controller The watch-me system consists of a server and a client. Client: The client collects signal strength (RSSI, which can be used to determine location) 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). Server: The Server Receives RSSI Data from the client via JAIN SIP Stack (over SIP protocol) 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 JAIN SIP Stack. 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 command. 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: DistanceCalculation 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 LocationCalculation 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 point. 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 Database. 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 are: 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: >Room< >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: >Access_x0020_Points< <MAC>00022D1ECAEC</MAC< The MAC of the access Point >Location>( 8.45, 3.85 , 0 )</Location< The X , Y, Z location meters </Access_x0020_Points> 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 controllers. 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 meters. The format for the XML: >MapLocation>./resource/floorplan3.JPG</MapLocation< - The location of the map file >MapSize< >MapWidth>24</MapWidth< --- The map width in meters >MapHeight>15</MapHeight< --- The map Height in meters </MapSize> 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: REGISTER sip:22.214.171.124:5060 SIP/2.0 Call-ID: nist-sip-im-register-callId1 CSeq: 1 REGISTER message type is register for CreateUser message From: <sip:firstname.lastname@example.org>;tag=5072 The message is sent from the new user To: <sip:__newUser@126.96.36.199> The message is sent to __newUser Via: SIP/2.0/TCP technion- irina:11111;branch=z9hG4bKb24b32c77b12ffdb311eb9e4f8602622 Max-Forwards: 10 Content-Type: text/plain;charset=UTF-8 Contact: <sip:technion-irina:11111;transport=tcp> Allow: INVITE,SUBSCRIBE,NOTIFY,MESSAGE,INFO,PUBLISH 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: REGISTER sip:10.0.0.11:5060 SIP/2.0 Call-ID: nist-sip-im-register-callId1 CSeq: 1 REGISTER From: <sip:email@example.com>;tag=3111 To: <sip:firstname.lastname@example.org> Via: SIP/2.0/TCP technion- irina:11000;branch=z9hG4bK15e9799ad00e45e7a631aea6edc743fb Max-Forwards: 10 Content-Type: text/plain;charset=UTF-8 Contact: <sip:technion-irina:11000;transport=tcp> Allow: INVITE,SUBSCRIBE,NOTIFY,MESSAGE,INFO,PUBLISH 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 CSeq: 1 SUBSCRIBE From: <sip:email@example.com>;tag=9950 To: <sip:arie@technion-irina> Via: SIP/2.0/TCP 10.0.0.11:5060;branch=z9hG4bK03b28c7e1de66bc50c7fa14ae5a4b12d Max-Forwards: 70 Contact: <sip:10.0.0.11:5060;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:188.8.131.52:5060;transport=tcp SIP/2.0 Call-ID: nist-sip-im-invite-callId1 CSeq: 1 INVITE From: <sip:firstname.lastname@example.org>;tag=402 sender To: <sip:email@example.com> receiver Via: SIP/2.0/TCP 10.0.0.11:11000;branch=z9hG4bK6c82d56ccd5b4066b5e20cd9d064221f Max-Forwards: 70 Contact: <sip:184.108.40.206:11000;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 user. Syntax is normal SIP Message syntax: MESSAGE sip:220.127.116.11:5060;transport=tcp SIP/2.0 Call-ID: nist-sip-im-message-callId1 CSeq: 1 MESSAGE From: <sip:firstname.lastname@example.org>;tag=2006 sender To: <sip:email@example.com> receiver Via: SIP/2.0/TCP 10.0.0.11:11000;branch=z9hG4bK3e642b70a67b7c4b170607483a784e82 Max-Forwards: 70 Content-Type: text/plain;charset=UTF-8 Contact: <sip:18.104.22.168:11000;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:22.214.171.124:5060;transport=tcp SIP/2.0 Call-ID: nist-sip-im-info-callId1 CSeq: 1 INFO INFO Message From: <sip:firstname.lastname@example.org>;tag=7346 querying user To: <sip:email@example.com> queried user or group Via: SIP/2.0/TCP 126.96.36.199:11000;branch=z9hG4bK1aeccd2f071220386bcf295d6819dfa8 Max-Forwards: 70 Contact: <sip:188.8.131.52:11000;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:firstname.lastname@example.org>;tag=7346 To: <sip:email@example.com>;tag=9738 Via: SIP/2.0/TCP 184.108.40.206:11000;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 users alex~OFFLINE~Unnamed~-1.0~-1.0~-1.0 guest~OFFLINE~Unnamed~-1.0~-1.0~-1.0 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:10.0.0.11:5060;transport=tcp SIP/2.0 Call-ID: nist-sip-im-notify-callId1 CSeq: 1 NOTIFY The LocationData message is implemented as notify message From: <sip:firstname.lastname@example.org>;tag=3285 To: <sip:getLocation@10.0.0.11> The location data message is sent to getLocation service, in order to calculate the client’s current location Via: SIP/2.0/TCP 10.0.0.11:11000;branch=z9hG4bK150fad1d8029db9ee5b38943510a2bfc Max-Forwards: 70 Content-Type: text/plain;charset=UTF-8 Contact: <sip:10.0.0.11:11000;transport=tcp> Event: presence Accept: application/pidf+xml Content-Length: 67 The syntax for this message is MAC’SignalStrength~MAC’SignalStrength’~... 00022D1ECAEC'-63~00022D214B71'-10~00022D28D0AA'-65~00022D28D0A8'-20 The response for LocationData message will be a message containing the user’s current location Call-ID: nist-sip-im-notify-callId15 CSeq: 1 NOTIFY From: <sip:email@example.com>;tag=5947 To: <sip:getLocation@10.0.0.11>;tag=390 Via: SIP/2.0/TCP 10.0.0.11:11000;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:220.127.116.11:5060;transport=tcp SIP/2.0 Call-ID: nist-sip-im-notify-callId296 CSeq: 1 NOTIFY From: <sip:firstname.lastname@example.org>;tag=1376 requesting user is arie To: <sip:nameLocation@18.104.22.168> user is requesting to name a location Via: SIP/2.0/TCP 22.214.171.124:11000;branch=z9hG4bKa9e036a522541ec8996455789cabd90c Max-Forwards: 70 Content-Type: text/plain;charset=UTF-8 Contact: <sip:126.96.36.199:11000;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 users. 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 messages. 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 area. 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- 312.jdbc2.jar‖ 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‖ button 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 Groups‖ 3. Messaging screen will appear 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 ―Map.xml‖ 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 map 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 iptel.org 6. Postgre SQL. 7. Almanac - Java JDBC examples Appendix 1 Jain SIP Stack JAIN SIP • 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 protocol. • 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 container. • JAIN SIP supports the SIP protocol functionality described in RFC 3261. • 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 properties. • Defines retransmission settings. • Defines router information. Retransmissions • 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 Responses. Stack Properties • IP_ADDRESS – Sets the IP Address of the SipStack. This property is mandatory. • STACK_NAME – Sets a user friendly name to identify the underlying stack implementation. This property is mandatory. • OUTBOUND_PROXY – Sets the outbound proxy of the SIP Stack. • ROUTER_PATH – Sets the fully qualified classpath to the application supplied Router object that determines how to route messages before a dialog is established. • EXTENSION_METHODS – This configuration value informs the underlying implementation of supported extension methods that create new dialog's. • RETRANSMISSION_FILTER – 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 messages. • Parse incoming messages and enable application access to fields via a standardized Java interface. • Invoke appropriate application handlers when protocol significant – 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 SipListener. • 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 events. – 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. Packages • 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 Factories 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 TelURL’s. • 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 Interfaces: – 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 Request. • 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 • 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 protocol: • INVITE – Invites a participant to a session • BYE – Ends a client’s participation in a session • CANCEL – terminates a transaction • OPTIONS – Queries a participant about their media capabilities • ACK – For reliability and call accepta nce (3-way handshake) • REGISTER – Informs a SIP server about the location of a user Request Message Types The following request messages are defined by various SIP extensions: • INFO – Session related control information generated during a session. • PRACK – For reliability of provisional responses. • UPDATE – Update a session without impacting the state of a dialog. • SUBSCRIBE – Request notification from remote nodes when certain events occur. • NOTIFY – Notification from remote nodes when certain events occur. • MESSAGE – For sending instant messages. • REFER – Refer to a resource provided in the request. Headers • SIP headers are similar to HTTP headers fields in both syntax and semantics. • 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 issued. – 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 define: – 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 request. – 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 network • Implementation manages the association between Transactions and Dialogs. . Dialog Support • A Dialog is a peer to peer association between communicating SIP endpoints. – 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 lives. 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 . 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, timeconsuming 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 environment. 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 http://www.placelab.org/. 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 . 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 developers. 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 . Ekahau (ekahau.com) 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 . 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 , ultra-wideband radio (ubisense.com). 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 (mappoint.com, streetatlasusa.com). Users that are comfortable disclosing their location to their social network have access to applications like dodgeball.com and mMode’s Friend Finder (attwireless.com/mmode) 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 (yp.yahoo.com) and Google’s Local Search (local.google.com) are available to anyone with a network connection. 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 points1. 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 Tracker Local apps Web browser Place Lab Client Radio beacons War drivers and other data contributors Beacon databases Internet beacon traces beacon locations GSM 802.11 Bluetooth 802.11 spotter GSM spotter Bluetooth 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, wigle.net 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 (worldwidewardrive.org). 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 wigle.net, 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 phone numbers in an attempt to discover and establish a modem connection with interesting computers. 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  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.  and Patterson et al. . 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. Operating Systems Architectures 802.11abg Beacons GSM Beacons Bluetooth Beacons 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 the master device. development, Place Lab supports five ways of communicating location information to applications: 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 . 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 . 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 estimates PlaceBar that uses a browser toolbar to manage a user’s interactions with Google’s location-based search: http://local.google.com/. 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 (http://a2b.cc/). 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 . 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 . 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 accuracy. 4 Unfortunately, our Nokia cell phones only allow us to know the ID of the current cell tower 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 technology. 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  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. 0% 10% 20% 30% 40% 50% 60% 012345≥6 0% 10% 20% 30% 40% 50% 60% 012345≥6 0% 10% 20% 30% 40% 50% 60% 012345≥6 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 driving along surface streets. For each scan we recorded the number of APs in range. Satellite photos 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 Downtown Seattle (Urban) 20.5 m 100.0% 107.2 m 100.0% 21.8 m 100.0% Ravenna (Residential) 13.5 m 90.6% 161.4 m 100.0% 13.4 m 100.0% Kirkland (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 drawn 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 0 5 10 15 20 25 30 35 40 45 50 1 2 3 4 5 6 7 8 9 10 11 ≥ 12 0% 5% 10% 15% 20% 25% 30% 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 longitude. 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 http://www.placelab.org/. 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.
Pages to are hidden for
"Installing"Please download to view full document