Place Lab: Enabling Large-Scale, Location-Enhanced Computing Ian Smith

1. Place Lab: Enabling Large-Scale, Location-Enhanced ComputingIan Smith Anthony LaMarca Yatin Chawathe, Sunny Consolvo, Jeffrey Hightower, James Scott (IRC) November 11, 2004

2. Why am I here? • Not headed for a Camus answer… • Let you know what’s going on at Intel Research Seattle… • Encourage potential interns to apply Indeed, why am I here, when my copy of Halo2 is in Seattle?!?

3. I am here What do you want to enable? • Widely available location-enhanced computing • Build a positioning system that is • Wide-scale, indoor & outdoor • Can be used everywhere • Privacy observant, low barrier to participation • Can be used by everyone

4. What new ideas enable virtually free device positioning? • Exploit wide-scale WiFi deployment • Urban areas have dense WiFi coverage • WiFi base stations broadcast unique IDs • Position WiFi devices using map of base-station-IDs to location

5. Demo

6. How will you go about it?Place Lab Toolkit • Develop toolkit to foster external engagement • XP, MacOS and Linux notebooks, PocketPC PDAs • Recently: Nokia Series 60 phones • Sample client- and server-side apps • 24/7 deployment of Mapper service on PlanetLab • War-driving devices based on personal servers • A plugin architecture to encourage experimentation • Signed-up for the alpha release • UW, UCB, UCSD, GaTech • IRB, IRC • Edinburgh festival

7. Time stamped GPS readings and WiFi signal strengths What is the meat of the project?#1 Scanning RF beacons in the wild • Problem: Signal strength not sufficient to accurately map base station location • “Visibility” is another key feature.. • Solution: Add contextual information to improve accuracy • Apply techniques developed at IRS for correcting GPS data • Mine GIS maps for structural information, e.g., roads, buildings • Incorporate models of obstacles and antennas t4 56 db t3 40 db t1 95 db t2 46 db

8. ? ? ? ? ? . . . t2 tn t1 ? ? ? ? ? ? t2 t3 t1 . . . t2 tn t1 ? ? ? ? . . . t2 tn t1 What is the meat of the project?#1 Scanning RF beacons in the wild (cont) • War drivers will not map all base stations • Leverage users’ RF traces to complete the map • Users can opt to submit traces of base stations they see • {(t1,b1) , (t2,b2) , … (tn, bn)} • Refine base station locations using these traces

9. What is the meat of the project?#1 Scanning RF beacons in the wild (cont) • Recently we’ve incorporated wigle.net’s data • We don’t have redistribution rights • Gives us significant coverage in US and Western Europe (about 2M access points) • “War driving is not a crime…”

10. Wigle.net Coverage Map

11. What is the meat of the project?#2Mapper Service • Distribute for scalability and trust • 1 server hour = 1 hr of war-driving or 20 hrs of steady-state traces • Avoid single trusted entity • Four key problems • Routing AP trace data from clientsto servers • Retrieving location maps from distributed servers • Detecting misbehaving servers • Detecting bad data submitted by clients AP sightings Mapper Service Regional location maps

12. What is the meat of the project?#3 Building a critical mass of data • Incorporate data from existing sources • Wigle, WiFi clubs (NYC wireless) • Distribute personal server spotters to research community • Compact, long-lived war-driving tool • 50 devices, 20% with GPS

13. Summer ’04Study Xmas ’04 SmallDeployment Consolvo/Matthews Iachello What is the meat of the project?#4 Designing the user experience: Pilot StudyFall ‘04 Research Trajectory

14. What is the meat of the project?#4 Designing the user experience (ESM) • Objective: Assess attitudes towards location disclosure to social relations • 16 participants, Seattle area, no tech. careers • All got out of house daily, all were cell-phone users • Phases • Pre-study interview (assess social network) • 2 Weeks of ESM questions (max 10 day, 9am-9pm) • Post-study interview • ESM questions were customized per-subject

15. What is the meat of the project?#4 Designing the user experience (ESM) • Participants want to disclose what they felt was most useful to the requestor • Recipient design (place rather than address) • No evidence of blurring for privacy (but blur for utility) • 77% of the time, something specific was disclosed • Westin privacy classification is not a good predictor • Westin concerns disclosure to business, so not surprising • Highest comfort level with spouse/SO • All of this was hypothetical, so…

16. What is the meat of the project?#4 Designing the user experience (Reno) • People share their location with their social network frequently • Mobile phones • SMS/Email/IM • Postcards • Coming soon: Social location disclosure apps? • Can we build a location-sharing application that is compelling and privacy sensitive? ‘Hello?’ ‘Hey, it’s Ian….Where are you?’ drianesmith: Hey, I’m at home. Can you pick me up on your way?

17. What is the meat of the project?#4 Designing the user experience (Reno) • Do it on a device that is really ubiquitous • Battery life, form factor, etc. • Device should position itself • Many options: GPS/A-GPS, Place Lab, etc. • Use “place” instead of location • Follows directly from Summer study about location disclosure • Don’t do anything worse with privacy • If they are already using a GSM cell phone…

18. What is the meat of the project?#4 Designing the user experience (Reno)

20. What is the meat of the project?#4 Designing the user experience (Reno) • Location information is a low-bandwidth channel • It can be extremely powerful in the presence of shared context • Location, path, activity Late tonight, [f] pushed her location to me from SEA-TAC airport. That reminded me that … I wanted get together with them socially when they arrived. I had forgotten it was this weekend. Participant g, Day 2 (Thurs)

21. 1500 1st Street Commercial A&M Real Estate Barnes and Noble Bookstore “School hangout” “Quiet place” What is the meat of the project?#5 Moving from location to place (Hightower) • Solving this problem requires: • Discovering and mapping boundaries of place • Learning place labels • From the WWW • Mine place boundaries using GIS maps • Extract place labels from GIS, Yellow Pages, … • From the RF beacon data • Infer place boundaries from behavior and usage • From the user • Direct entry of place labels “Café”

22. Thank You.

23. Deliverables Place Lab Toolkit Release toolkit with ULF or location stack Deploy Place Lab in university classes Release toolkit with location-to-place service Publish evaluation of academic use of Place Lab Release Place Lab Architecture Mapper Service Demo client/server and server/server reputation algorithms Deploy distributed Rev 2 Mapper service Deploy centralized Rev 1 service Deploy PS GPS spotter Capstone Application Publish evaluation of capstone application Deploy application to real users for evaluation Release application design and architecture Define user requirements Mapping / Learning Demo beacon placement inference Demo location-to-place service Demo data-cleaning filters Demo Arrangements layer operation primitives Privacy Report on tradeoffs of explicit vs. implicit privacy management Generate user requirements for trace gathering Demo explicit mechanisms for privacy management of location data 2004 2003 2005 Dec ‘03

24. The Three Major Aspects of Place Lab • Build a software artifact for doing location • Get others using and developing Place Lab applications and extensions • Within Intel • Within the research community • Within the broader “hacking” community • Perform research in location-enhanced computing • Privacy • Distributed systems • Machine learning • Applications

25. Develop Place Lab toolkitLaMarca, Chawathe, I Smith, J Scott • Java (J2ME) • Many supported platforms • 802.11, Bluetooth, GPS, GSM spotting • Approximately 500 downloads/month • Done • Rev 1.0 released 1/04 • Rev 1.1 released 3/04 • To Do • Rev 2.0 late summer ’04 with Nokia support

26. Download Statistics

27. Populate beacon mapping databaseChawathe, Powledge, Rea • 28475 mapped WiFi beacons as of July ’04 • Largely in US cities (Seattle, Berkeley, Boston, etc) • Done • Deployed non-distributed “Rev 1” mapper service • Developed Stargate Spotter, Place Lab stumbler software • To Do • Deploy Stargate Spotters to collaborators • Convince war drivers to submit logs • Investigate ways to drastically increase database size • Contest • Instrument public-service vehicles • Key Collaborators • T. Pering (IR)

28. Distribute beacon mapping databaseChawathe, LaMarca, Smith • Distribute via DHT using Prefix hash Trees (PHT) for indexing • Done • Developed 2D extensions to original PHT • Measured performance using realistic data set • Submitted paper to OSDI ’04 (rejected) • To Do • Submit joint IRB/IRS PHT paper to NSDI ’05 • Develop and test concurrency control measures for PHTs • Replace public database with distributed version • Key Collaborators • S. Ratnasamy (IRB), S. Shenker (ISCI), J. Hellerstein (IRB/UCB)

29. Foster use of Place LabLaMarca, I Smith, Chawathe • Place Lab usage in both research and teaching venues • Seeing uptake beyond collaborators and friends • Done • Demoed Prototype system at UbiComp ’03 • Taught 10 half-day Place Lab “boot camp” workshops • Dartmouth, UW, Trinity, UCSD, ICL, Glasgow, Strathclyde, Cambridge • Supported UW and Dartmouth use of Place Lab in the classroom • Open source development of Place Lab on Source Forge • Prepared demo for Google “Place Bar” • To Do • Continued support of class, academic use of Place Lab • Increase engagement with relevant Intel groups • Continue and increase support of Kelvin institute in Edinburgh deployment

30. Mapping and positioning algorithmsChawathe, LaMarca • Base toolkit implements centroid and simple particle filter based location calculation • Done • Preliminary data suggests Place Lab 1.1 accuracy of ~30M • To Do • Comprehensive study of existing WiFi location algorithms “aka Bake Off” [Submit to Pervasive ’05] • GPS-less beacon inference • Compare Voronoi-based approach to current unconstrained 2D approaches • Decide how best to cope with z dimension • Investigate multiple-radio algorithms (802.11 + Bluetooth, etc) • Key Collaborators: D. Fox (UW CSE), J. Krumm (MSR)

31. Designing privacy-observant proactive applicationsConsolvo, I Smith • Classes of application: personal, social, institutional • Done • Develop plan for Seattle-based ESM study of social applications • Develop plan for Edinburgh festival-based study of institutional applications • UbiComp workshop paper on location disclosure by app. class • To Do • Execute study of social app, submit study results to CHI ‘05 • Execute study of institutional app, submit study results to CHI ’05 • Fold study results into design of upcoming Place Lab applications • Key Collaborators: S. Mainwaring (PAPR)

32. Create a privacy license agreementI Smith, Consolvo • Combine end-user privacy guarantees and open source into a new license agreement • Release Place Lab under this agreement • Done • Partially complete certificate of origin • Rough draft of agreement with Intel Legal • To Do • Submit value-sensitive design paper to ECSCW ‘05 • Key Collaborators: B. Friedman UW I School), P. Kahn (UW Psych)

33. Develop Place Lab applications • No real applications developed by the team to date • Done • Copious brainstorming about possible “capstone” application • Small sample applications in each of the 3 identified categories • Pedometer – personal • “Ambush” – social • Google Place Bar – institutional • To Do • Revisit capstone ideas and evaluate in light of user study data • Build and deploy and evaluate a capstone application

34. Publication Plans

35. Break

36. Deliverables Place Lab Toolkit Release toolkit with ULF or location stack Deploy Place Lab in university classes Release toolkit with location-to-place service Publish evaluation of academic use of Place Lab  Release Place Lab Architecture   Mapper Service Demo client/server and server/server reputation algorithms Deploy distributed Rev 2 Mapper service  Deploy centralized Rev 1 service Deploy PS GPS spotter   Capstone Application Publish evaluation of capstone application Deploy application to real users for evaluation Release application design and architecture   Define user requirements  Mapping / Learning Demo beacon placement inference Demo location-to-place service Demo Arrangements layer operation primitives Demo data-cleaning filters Privacy Generate user requirements for trace gathering Demo explicit mechanisms for privacy management of location data Report on tradeoffs of explicit vs. implicit privacy management   2004 2003 2005

37. What has gone well • Toolkit development • Achieved sought-after portability • Complimented from users about usability • Development of research agenda • Engagement of top-shelf collaborators • PHT surprising, interesting result • Recruitment of J Scott to project • Strong UW collaboration/contribution

38. What has not gone well • Building out the database has been slow • Less WD engagement than expected • Less background mapping than expected • Support for CLDC 1.0 (Nokias) has required more engineering that expected • APIs not as simple as before • Bake-off, privacy agenda and application development have lagged expectations • Key resource (Sunny) redirected for Q1 this year • Technical and methodological problems with our data collection • No individual or entity on trajectory to inherit Place Lab

39. Changes to our plans • Nokia support give us a compelling platform • Develop and deploy Ambush on phones (J Scott, I Smith) • Investigate accuracy/coverage of heterogeneous beacon-based location systems (J Scott, LaMarca) • Drop study of academic use of toolkit (Consolvo) • Investigate PHTs and their cousins beyond the requirements of Place Lab (Chawathe, LaMarca)

40. Thanks!

41. Place Lab Users • UCSD’s Active Campus Project • Trinity College, Dublin • University of Washington CSE • GUIR’s Topiary • Kelvin Institute