Commit ae946d820c2c8aec5b1d1878f5ae7081bfed97b7
1 parent
25aeff1f
5 page fit
Showing
5 changed files
with
29 additions
and
29 deletions
conclusion.tex
| 1 | \section{Conclusions} | 1 | \section{Conclusions} |
| 2 | \label{sec:conclusion} | 2 | \label{sec:conclusion} |
| 3 | 3 | ||
| 4 | -In this paper, we show that reciprocal \wifi{} sharing opportunities do exist in real | ||
| 5 | -life scenarios through extensive analysis of the \PhoneLab{} \wifi{} dataset. We | ||
| 6 | -propose and present the design of \wisefi{}, a system that detects reciprocal | ||
| 7 | -sharing opportunities, enable \wifi{} sharing and monitor the \wifi{} usage and | ||
| 8 | -performance to ensure the sharing remains reciprocal. | 4 | +In this paper, we show that reciprocal \wifi{} sharing opportunities do exist in |
| 5 | +real life scenarios through extensive analysis of the \PhoneLab{} \wifi{} | ||
| 6 | +dataset. We present the design of \wisefi{}, a system that detects | ||
| 7 | +reciprocal sharing opportunities, enable \wifi{} sharing and monitor the \wifi{} | ||
| 8 | +usage and performance to ensure the sharing remains reciprocal. | ||
| 9 | 9 | ||
| 10 | We are currently implementing a \wisefi{} system prototype, which includes a | 10 | We are currently implementing a \wisefi{} system prototype, which includes a |
| 11 | \wisefi{} Android application, dynamic AP configuration API support on OpenWRT | 11 | \wisefi{} Android application, dynamic AP configuration API support on OpenWRT |
design.tex
| @@ -38,14 +38,14 @@ described in Section~\ref{subsec:reciprocal}. | @@ -38,14 +38,14 @@ described in Section~\ref{subsec:reciprocal}. | ||
| 38 | \label{subsec:sharing} | 38 | \label{subsec:sharing} |
| 39 | 39 | ||
| 40 | Once the reciprocal sharing opportunities are discovered, the \wisefi{} server | 40 | Once the reciprocal sharing opportunities are discovered, the \wisefi{} server |
| 41 | -can distribute such information to the \wisefi{} application on smartphone, | ||
| 42 | -which will prompt users to establish \wifi{} sharing. The sharing mechanism must | ||
| 43 | -meet two goals: control and protection. First, the system should be able to | ||
| 44 | -control the sharing, including granting the access of home AP to other \wisefi{} | ||
| 45 | -users, and revoking the access when the reciprocal sharing opportunity no longer | ||
| 46 | -exists. Second, the system should protect the home network from other \wisefi{} | ||
| 47 | -users by sharing access only to the Internet, and protecting private resources | ||
| 48 | -such as home network printers or storage. | 41 | +distributes such information to the \wisefi{} application on smartphone, which |
| 42 | +prompts user to establish \wifi{} sharing. The sharing mechanism must meet two | ||
| 43 | +goals: \textit{control} and \textit{protection}. First, the system should be | ||
| 44 | +able to control the sharing, including granting the access of home AP to other | ||
| 45 | +\wisefi{} users, and more importantly, revoking the access when needed. Second, | ||
| 46 | +the system should protect the home network from other \wisefi{} users by sharing | ||
| 47 | +access only to the Internet, and protecting private resources such as home | ||
| 48 | +network printers or storage. | ||
| 49 | 49 | ||
| 50 | Some mid-to-high end wireless routers support the \textit{virtual network} | 50 | Some mid-to-high end wireless routers support the \textit{virtual network} |
| 51 | feature, where multiple virtual \wifi{} networks are emulated by a single router | 51 | feature, where multiple virtual \wifi{} networks are emulated by a single router |
| @@ -78,7 +78,7 @@ all devices is still tedious. | @@ -78,7 +78,7 @@ all devices is still tedious. | ||
| 78 | 78 | ||
| 79 | To overcome this challenge, we propose a dynamic \wifi{} AP configuration API | 79 | To overcome this challenge, we propose a dynamic \wifi{} AP configuration API |
| 80 | with two simple interfaces: \texttt{getAuthClients} and \texttt{setWhiteList}. | 80 | with two simple interfaces: \texttt{getAuthClients} and \texttt{setWhiteList}. |
| 81 | -The semantics of the interfaces are as follows. \texttt{getAuthClients} simply | 81 | +The semantics of the interfaces are as follows. \texttt{getAuthClients} |
| 82 | returns all the MAC addresses of clients that are currently associated with the | 82 | returns all the MAC addresses of clients that are currently associated with the |
| 83 | AP through normal authentication. In home \wifi{} network scenario, this | 83 | AP through normal authentication. In home \wifi{} network scenario, this |
| 84 | interface shall return only the MAC addresses of user's own \wifi{} devices. On | 84 | interface shall return only the MAC addresses of user's own \wifi{} devices. On |
| @@ -133,7 +133,7 @@ sharing remains reciprocal. There are two reasons why this is necessary: one is | @@ -133,7 +133,7 @@ sharing remains reciprocal. There are two reasons why this is necessary: one is | ||
| 133 | obvious and another is obscure. | 133 | obvious and another is obscure. |
| 134 | 134 | ||
| 135 | First, it is obviously important to ensure that the sharing remains reciprocal | 135 | First, it is obviously important to ensure that the sharing remains reciprocal |
| 136 | -in long term to provide incentives for both parties to participate the sharing. | 136 | +to provide incentives for both parties to participate the sharing. |
| 137 | For instance, suppose after the system has established reciprocal \wifi{} sharing | 137 | For instance, suppose after the system has established reciprocal \wifi{} sharing |
| 138 | between Alice and Bob, and Bob decides to deploy an extra AP at his home which | 138 | between Alice and Bob, and Bob decides to deploy an extra AP at his home which |
| 139 | makes him no longer benefit from sharing Alice's home AP. The system should | 139 | makes him no longer benefit from sharing Alice's home AP. The system should |
introduction.tex
| @@ -64,7 +64,7 @@ But how often is reciprocal \wifi{} sharing beneficial and possible in | @@ -64,7 +64,7 @@ But how often is reciprocal \wifi{} sharing beneficial and possible in | ||
| 64 | practice? To explore these questions, we begin in | 64 | practice? To explore these questions, we begin in |
| 65 | Section~\ref{sec:investigation} by analyzing a dataset collected on the | 65 | Section~\ref{sec:investigation} by analyzing a dataset collected on the |
| 66 | \PhoneLab{}~smartphone testbed containing \num{21192417} \wifi{} scan results | 66 | \PhoneLab{}~smartphone testbed containing \num{21192417} \wifi{} scan results |
| 67 | -from 254~smartphones over 5~months (\S~\ref{sec:investigation}). Despite the | 67 | +from 254~smartphones over 5~months. Despite the |
| 68 | fact that the geographic extent of the dataset is suburban Buffalo, which as | 68 | fact that the geographic extent of the dataset is suburban Buffalo, which as |
| 69 | a city has a population density an order of magnitude lower than | 69 | a city has a population density an order of magnitude lower than |
| 70 | densely-populated areas like Manhattan, we still find that many users would | 70 | densely-populated areas like Manhattan, we still find that many users would |
investigation.tex
| @@ -79,12 +79,12 @@ that provide better signal most of the time? | @@ -79,12 +79,12 @@ that provide better signal most of the time? | ||
| 79 | \sloppy{% | 79 | \sloppy{% |
| 80 | To answer the first question, we inspect scan results that are reported during | 80 | To answer the first question, we inspect scan results that are reported during |
| 81 | \wifi{} sessions with home APs. For each such scan result, we identify the | 81 | \wifi{} sessions with home APs. For each such scan result, we identify the |
| 82 | - currently associated home AP, $AP_{home}$, and the AP with best RSSI among all | ||
| 83 | - reported APs, denoted as $AP_{best}$. We are particularly interested in | ||
| 84 | - \textit{sub-optimal} cases, where: (1) $AP_{home} \neq AP_{best}$ and (2) the | ||
| 85 | - device never connects to $AP_{best}$ in the dataset. Such cases indicate that the device | ||
| 86 | - could potentially improve its \wifi{} performance by connecting to a neighbor | ||
| 87 | - AP which has a strong signal yet it does not have access to that AP. Note that | 82 | + currently associated home AP, $AP_{home}$, and the AP with best RSSI, denoted |
| 83 | + as $AP_{best}$. We are particularly interested in \textit{sub-optimal} cases, | ||
| 84 | + where: (1) $AP_{home} \neq AP_{best}$ and (2) the device never connects to | ||
| 85 | + $AP_{best}$ in the dataset. Such cases indicate that the device could | ||
| 86 | + potentially improve its \wifi{} performance by connecting to a neighbor AP | ||
| 87 | + which has a strong signal yet it does not have access to that AP. Note that | ||
| 88 | here we consider RSSI as a hint in determining the \textit{optimal} AP and it | 88 | here we consider RSSI as a hint in determining the \textit{optimal} AP and it |
| 89 | is well understood that RSSI does not directly translate to \wifi{} | 89 | is well understood that RSSI does not directly translate to \wifi{} |
| 90 | performance, which we will discuss in Section~\ref{sec:challenges}. Also note | 90 | performance, which we will discuss in Section~\ref{sec:challenges}. Also note |
| @@ -100,7 +100,7 @@ that provide better signal most of the time? | @@ -100,7 +100,7 @@ that provide better signal most of the time? | ||
| 100 | \label{fig:suboptimal} | 100 | \label{fig:suboptimal} |
| 101 | \end{figure} | 101 | \end{figure} |
| 102 | 102 | ||
| 103 | -We classify all scan results reported during \wifi{} sessions with home APs into | 103 | +We classify all scan results reported during home \wifi{} sessions into |
| 104 | two categories: sub-optimal and the rest. For each device, we calculate the | 104 | two categories: sub-optimal and the rest. For each device, we calculate the |
| 105 | percentage of time when the scan results indicate sub-optimal association. | 105 | percentage of time when the scan results indicate sub-optimal association. |
| 106 | Figure~\ref{fig:suboptimal} shows the CDF of this percentage for | 106 | Figure~\ref{fig:suboptimal} shows the CDF of this percentage for |
| @@ -110,7 +110,7 @@ their home APs usually provides best signal (sub-optimal percentage less than | @@ -110,7 +110,7 @@ their home APs usually provides best signal (sub-optimal percentage less than | ||
| 110 | usually carefully positioned to provide good coverage. Second, we notice | 110 | usually carefully positioned to provide good coverage. Second, we notice |
| 111 | that for certain number (15\%) of devices, their home APs failed to provide best | 111 | that for certain number (15\%) of devices, their home APs failed to provide best |
| 112 | signal for more than 50\% of the time, suggesting that these users may benefit | 112 | signal for more than 50\% of the time, suggesting that these users may benefit |
| 113 | -from sharing the \wifi{} access of their neighbor APs. | 113 | +from sharing the \wifi{} access of neighbor APs. |
| 114 | 114 | ||
| 115 | Next, we want to answer the question when the device is in a sub-optimal association | 115 | Next, we want to answer the question when the device is in a sub-optimal association |
| 116 | with its home AP, are there \textit{dominant} neighbor APs that | 116 | with its home AP, are there \textit{dominant} neighbor APs that |
related.tex
| 1 | -\section{Related Work} | 1 | +\section{Related Works} |
| 2 | \label{sec:related} | 2 | \label{sec:related} |
| 3 | 3 | ||
| 4 | OpenWireless movement~\cite{openwireless} is a community effort for ubiquitous | 4 | OpenWireless movement~\cite{openwireless} is a community effort for ubiquitous |
| 5 | -Internet access. Volunteers participate the community by configuring their | 5 | +Internet access. Volunteers configure their |
| 6 | \wifi{} network with open access and a special SSID, \texttt{openwireless.org}, | 6 | \wifi{} network with open access and a special SSID, \texttt{openwireless.org}, |
| 7 | to advertise free access. Another goal of OpenWireless is arguably preserving | 7 | to advertise free access. Another goal of OpenWireless is arguably preserving |
| 8 | user's privacy by blending the user's network activity among all other users who | 8 | user's privacy by blending the user's network activity among all other users who |
| @@ -22,11 +22,11 @@ neighbor relationship). | @@ -22,11 +22,11 @@ neighbor relationship). | ||
| 22 | 22 | ||
| 23 | There are also rich literature on cooperative \wifi{} sharing. Dimopoulos | 23 | There are also rich literature on cooperative \wifi{} sharing. Dimopoulos |
| 24 | \textit{et al.}~\cite{efstathiou2010controlled} propose a reciprocal Wifi | 24 | \textit{et al.}~\cite{efstathiou2010controlled} propose a reciprocal Wifi |
| 25 | -sharing mechanism and later on extend it to a large scale peer-to-peer Wifi | 25 | +sharing mechanism and later extend it to a large scale peer-to-peer Wifi |
| 26 | roaming framework~\cite{dimopoulos2010exploiting}. They mostly focus on the | 26 | roaming framework~\cite{dimopoulos2010exploiting}. They mostly focus on the |
| 27 | reciprocal manner of sharing: each user who share his/her WLAN will obtain | 27 | reciprocal manner of sharing: each user who share his/her WLAN will obtain |
| 28 | digital proof service (\textit{receipts}), which represent a ``I-owe-you'' | 28 | digital proof service (\textit{receipts}), which represent a ``I-owe-you'' |
| 29 | relationship. These receipts can later on be consumed to get reciprocal Wifi | 29 | relationship. These receipts can later on be consumed to get reciprocal Wifi |
| 30 | access from other users. Such reputation mechanisms can also be applied to | 30 | access from other users. Such reputation mechanisms can also be applied to |
| 31 | -\wisefi{}, although they can be simplified since \wisefi{} focus on sharing | ||
| 32 | -between two immediate peers with physical colocation relationship. | 31 | +\wisefi{}, although they can be simplified since the sharing is between two |
| 32 | +immediate peers with physical colocation relationship. |