Presentation is loading. Please wait.

Presentation is loading. Please wait.

WiFi-Reports: Improving Wireless Network Selection Jeffrey Pang (CMU) with Ben Greenstein (IRS) Michael Kaminsky (IRP) Damon McCoy (U. Colorado) Srinivasan.

Similar presentations


Presentation on theme: "WiFi-Reports: Improving Wireless Network Selection Jeffrey Pang (CMU) with Ben Greenstein (IRS) Michael Kaminsky (IRP) Damon McCoy (U. Colorado) Srinivasan."— Presentation transcript:

1 WiFi-Reports: Improving Wireless Network Selection Jeffrey Pang (CMU) with Ben Greenstein (IRS) Michael Kaminsky (IRP) Damon McCoy (U. Colorado) Srinivasan Seshan (CMU)

2 Problem: Commercial AP Selection tmobile attwifi (ap 1) attwifi (ap 2) seattlewifi linksys Free Public Wifi $3.99 $9.99 Free! Which networks will run my applications? Which ones have good performance? Quality = ??? We often have many choices of wireless access points (APs), but little information about each Jiwire.com Hotspot database Jiwire.com Hotspot database

3 Wifi-Reports Database Bandwidth: 30 kbps Blocked ports: Email Bandwidth: 5 Mbps Blocked ports: None community uploads measurement reports members download summary statistics

4 Wifi-Reports tmobile attwifi (ap 1) attwifi (ap 2) seattlewifi linksys Free Public Wifi I need to use VoIP so this is the best network for me Bandwidth: 300 kbps Blocked ports: None Doesn’t work! Wifi-Reports provides information about AP performance and application support Doesn’t work! Bandwidth: 100 kbps Blocked ports: None Bandwidth: 300 kbps Blocked ports: None Wifi-Reports Hotspot database Wifi-Reports Hotspot database Bandwidth: 30 kbps Blocked ports: Email Bandwidth: 5 Mbps Blocked ports: None Doesn’t work!

5 Research Challenges Doesn’t work! Bandwidth: 300 kbps Blocked ports: None Location privacy – Reports shouldn’t be linked, otherwise they can be used to track users – But also need to limit fraud; e.g., 1 report per AP per user – Solution: new ecash-like reporting protocol & robust summary functions

6 Research Challenges Doesn’t work! Bandwidth: 300 kbps Blocked ports: None Bandwidth: 10 Mbps Works great! (Really!) Location privacy – Reports shouldn’t be linked, otherwise they can be used to track users – But also need to limit fraud; e.g., 1 report per AP per user – Solution: new ecash-like reporting protocol & robust summary functions

7 Research Challenges Location privacy – Reports shouldn’t be linked, otherwise they can be used to track users – But also need to limit fraud; e.g., 1 report per AP per user – Solution: new ecash-like reporting protocol & robust summary functions Location context – Performance dependent on location with respect to AP – Wireless channel effects loss rate – Solution: estimate different loss regimes w/ distributed measurements Doesn’t work! Bandwidth: 300 kbps Blocked ports: None Bandwidth: 10 Mbps Works great! (Really!)

8 WiFi-Reports Overview WiFi-Reports Account Service WiFi-Reports Account Service Independent Report Databases Report on tmobile: Bandwidth: 1200 kbps Blocked ports: None Report on tmobile: Bandwidth: 1200 kbps Blocked ports: None Report on UBookstore Cafe: Bandwidth: 4000 kbps Blocked ports: Email, Skype,… Report on UBookstore Cafe: Bandwidth: 4000 kbps Blocked ports: Email, Skype,… Users collect measurement reports when they use networks Reports are sent to databases for others to download

9 Questions and Challenges How useful would this system be in practice? – Do users have many choices of usable wireless networks? – Is there diversity in network performance/functionality? – Is performance stable enough to be predictive? – Are networks better for some applications but worse for others? – Do enough users use real networks to gather measurements? How do we limit “report fraud” and provide anonymity? – Not even the account service should be able to link a user’s reports to each other (otherwise location privacy is violated) – But each user should only be able to report once per network

10 Part I: Measurement Study We built a measurement tool to simulate reports that users would collect – Bandwidth, latency, jitter, blocked ports, number of other users, etc. We measured all networks visible from: – 13 hotspots near The Ave – ~7 days at different times of day Measurement procedure: – Sit near center of hotspot – Perform active spot measurements (2-3 minutes per network) shinka tea tullys 1 starbucks 1 tullys 2 trabant oasis lounjin yunnie bubble tea sureshot bookstore cafeontheave starbucks 2 cafesolstice Our study is the first to examine pay networks and encrypted networks, in addition to open networks Our study is the first to examine pay networks and encrypted networks, in addition to open networks

11 Results: Are there many APs? Better

12 Results: Are there many APs? Better

13 Results: Is there diversity? Better

14 Results: Is there diversity? Better

15 Results: Are measurements predictive? Better

16 Results: Are there application trade-offs? Better Better latency Better bandwidth

17 Part II: Private and Accountable Reporting How do we limit “vote fraud” and provide anonymity? Requirements: – No one, even the account service, should be able to link a user’s reports to each other (otherwise previous work says location privacy is violated) – Each user should only be able to report once per network

18 Anonymizing Mix Network Design Sketch WiFi-Reports Account Service WiFi-Reports Account Service Report on tmobile: Bandwidth: 1200 kbps Blocked ports: None Report on tmobile: Bandwidth: 1200 kbps Blocked ports: None Independent Report Databases tmobile seattlewifi CAFEONTHEAVE … 1.Client creates one token per AP 2.Client blinds each token 3.Account Service signs blinded tokens 4.Client unblinds tokens … 1.Client uses and measures an AP 2.Client uses token to sign report 3.Report is published via mix network Report on tmobile: Bandwidth: 1200 kbps Blocked ports: None Report on tmobile: Bandwidth: 1200 kbps Blocked ports: None Report on tmobile: Bandwidth: 1200 kbps Blocked ports: None Report on tmobile: Bandwidth: 1200 kbps Blocked ports: None Report on tmobile: Bandwidth: 1200 kbps Blocked ports: None Report on tmobile: Bandwidth: 1200 kbps Blocked ports: None

19 Design Sketch Details = random public key pair {K tmobile, K tmobile -1 } – Account Service signs the public key K tmobile – Private key K tmobile -1 is used to sign reports  can update reports Assumptions: – The account service only gives one identity to each user – Most users are honest Open issues: – Client must get all tokens signed before using them  expensive If only get signed token after AP is used, use of the AP is revealed Can obtain a subset of all tokens instead (e.g., all tokens for a city)  trade off between token signing overhead for more location privacy

20 Token Generation Time Time to generate tokens for all APs in one city (single threaded Xenon 3.4 Ghz server)

21 Resistance to Fraud CDF of Prediction accuracy (1 = most accurate)

22 Ongoing work Implemented Wifi-Reports service – Linux client exists – Currently implementing Android client. Anyone want to help? MobiSys ‘09

23 Questions? (Other summer projects)

24 Results: Is there diversity? Better Blocked port = no measurement

25 Results: Is there diversity? Better Blocked port = no measurement

26 Results: Are measurements predictive? Better Blocked port = no measurement


Download ppt "WiFi-Reports: Improving Wireless Network Selection Jeffrey Pang (CMU) with Ben Greenstein (IRS) Michael Kaminsky (IRP) Damon McCoy (U. Colorado) Srinivasan."

Similar presentations


Ads by Google