design

Jinghao Shi
1 parent f3dadab6
Showing 10 changed files with 151 additions and 59 deletions
challenges.tex
common.tex
conclusion.tex
design.tex
figures/design.odg
figures/design.pdf
investigation.tex
paper.tex
references.bib
related.tex
 \section{Challenges}
 \label{sec:challenges}
+
+\subsection{Sharing Mechanisms}
+
+\subsection{Bootstrap and Incentives}
+
+\subsection{
@@ -4,3 +4,4 @@
 \newcommand{\PhoneLab}{\textsc{PhoneLab}}
 \hyphenation{Phone-Lab}
 \newcommand{\wifi}{Wifi}
+\newcommand{\wisefi}{\textsc{WiseFi}}
-\section{Conclusions and Discussion}
+\section{Conclusions}
 \label{sec:conclusion}
 \section{System Design}
 \label{sec:design}
+
+\begin{figure*}[t]
+ \centering
+ \includegraphics[width=\textwidth]{./figures/design.pdf}
+ \caption{\textbf{\wisefi{} System Work Flow.}}
+ \label{fig:design}
+\end{figure*}
+
+Inspired by the results of the investigation in Section~\ref{sec:investigation},
+we design a system called \wisefi{} to detect reciprocal sharing
+opportunities (\S\ref{subsec:detection}), enable \wifi{} sharing
+(\S\ref{subsec:sharing}) and monitor the \wifi{} performance to ensure the
+sharing remains reciprocal (\S\ref{subsec:monitoring}). Figure~\ref{fig:design}
+shows the overall work flow of the \wisefi{} system.
+
+\subsection{Detection}
+\label{subsec:detection}
+
+To detect reciprocal sharing opportunities, two information are required: the
+home AP of the device, and neighbor APs' signal strength during \wifi{} sessions
+with the home AP. A smartphone application will be deployed through app market
+to collect these information. In particular, the home AP information can be
+learned over a period of time using the heuristics developed in
+Section~\ref{subsec:homeap}, or be resolved through user input. \wifi{} scan
+results during sessions with home APs can then be logged to identify the
+neighbor APs that can potentially provide better signal. Finally, these
+information are uploaded and fused in \wisefi{} server to identify reciprocal
+sharing opportunities as described in Section~\ref{subsec:reciprocal}.
+
+\subsection{Sharing}
+\label{subsec:sharing}
+
+Once the reciprocal sharing opportunities are discovered, the \wisefi{} server
+can then distribute such information to the smartphone clients, which will
+prompt users to establish \wifi{} sharing. The sharing mechanism must meet two
+goals: control and protection. First, the system should be able to control the
+sharing, including granting the access of home AP to other \wisefi{} users, and
+revoking the access when the reciprocal sharing opportunity no longer exists.
+Second, the system should protect the home network from other \wisefi{} users by
+sharing access only to the Internet, and protecting private resources such as
+network printer or home network storage.
+
+For home APs which support virtual guest network feature, the \wifi{} sharing
+can be achieved by only distributing the credential of guest network to other
+\wisefi{} users. Access and traffic policies can then be enforced on the guest
+network to achieve control and protection. For APs without guest network
+feature, however, cumbersome AP configurations may be required, such as MAC
+black or white list, routing table entry. Such configurations are probably too
+complicated for average users to perform. We discuss possible solutions in
+Section~\ref{sec:challenges}.
+
+
+\subsection{Monitoring}
+\label{subsec:monitoring}
+
+After the sharing is established, the system needs to monitor the \wifi{}
+performance to ensure that the sharing remains reciprocal. There are two
+reasons. First, as mentioned in Section~\ref{subsec:better}, the system uses
+signal strength as a hint to identify potentially better APs. And it is well
+known that signal strength does not directly translate to \wifi{} performance.
+Other factors, such as AP load, modulation, interference, or \wifi{} generation,
+which can not be easily detected by the smartphone, also affect the link
+quality. Furthermore, last hop \wifi{} link quality does not necessarily
+determines the overall end-to-end network performance. Therefore, whether
+connecting to neighbor AP can indeed improve the user's network performance is
+unknown until the sharing is actually established. Second, it is important to ensure that
+the sharing remains reciprocal in long terms for fairness concerns. For
+instance, a \wisif{} user may have a new AP deployed at home such that the home APs
+always provide better or comparable \wifi{} coverage than the neighbor APs, and
+there are no longer needs to share neighbor APs. The system should be able to
+detect the termination of the reciprocal sharing relationship and revoke the
+peer's access to the user's home AP.
+
@@ -4,10 +4,10 @@
 \section{Investigation}
 \label{sec:investigation}
  
-To investigate such reciprocal sharing opportunities, we obtain a \wifi{} scan
-result dataset from \PhoneLab{} (\S\ref{subsec:phonelab}). We first develop
-heuristics to identify home AP information for each device
-(\S\ref{subsec:homeap}). Then we show the RSSI comparison between user's home
+To investigate such reciprocal sharing opportunities, we obtained a \wifi{} scan
+result dataset from \PhoneLab{} (\S\ref{subsec:phonelab}). We first discuss some
+heuristics to identify the home AP for each device
+(\S\ref{subsec:homeap}). Then we show the RSSI comparison between a user's home
 and neighbor APs (\S\ref{subsec:better}). Finally, we explore the reciprocal
 sharing relationships in the dataset (\S\ref{subsec:reciprocal}).
  
@@ -26,7 +26,6 @@ sharing relationships in the dataset (\S\ref{subsec:reciprocal}).
 Observed APs & \num{1197522} \\
 Used APs & \num{15668} \\ \midrule
 \wifi{} Sessions & \num{466032} \\
- Total Connection Time (Days) & \num{34721} \\
 \bottomrule
 \end{tabularx}
 \caption{\textbf{\PhoneLab{} \wifi{} Dataset Summary.} Used APs refers to the
@@ -37,13 +36,13 @@ sharing relationships in the dataset (\S\ref{subsec:reciprocal}).
 \PhoneLab{}\cite{phonelab-sensemine13} is a public smartphone platform testbed
 operated at the University at Buffalo. Several hundreds of participants carry
 instrumented Nexus 5 smartphones as their primary device. In particular, the
-smartphone platform was modified to log each \wifi{} scan results as well as
+smartphone platform was modified to log each \wifi{} scan result as well as
 connection events naturally generated by the Android system. Note that the same
-information can also be collected by applications with appropriate permissions.
+information can also also be collected by applications with appropriate permissions.
 Table~\ref{tab:summary} summarizes the \PhoneLab{} \wifi{} dataset.
  
-\wifi{} scan result represents the device's network visibility, and consists of
-multiple entries---each corresponds to one \wifi{} Access Point (AP) the device
+A \wifi{} scan result represents the device's network visibility, and consists of
+multiple entries---each corresponds to one \wifi{} AP the device
 observed. The content of one entry includes: (1) beacon timestamp, (2) AP SSID
 and BSSID, (3) AP channel and (4) RSSI. Additionally, the timestamp when the
 scan was performed is also logged.
@@ -51,20 +50,20 @@ scan was performed is also logged.
 \subsection{Home AP Detection}
 \label{subsec:homeap}
  
-In following analysis, we focus on home \wifi{} networks which are more likely
-to reveal stable and immediate reciprocal sharing opportunities. For this
-purpose, we first develop several heuristics to identify the home AP for each
-device in the dataset. The intuition is that the devices are most likely
-connected to home AP at night. More specifically, to identify the home AP for a
-device, we look at \wifi{} sessions happened during 12~AM and 4~AM and count the
-number of days that the device connects to each AP during this time period. We
-then identify the AP which has the largest day count as the device's home AP,
+We focus on home \wifi{} networks which are more likely to reveal stable and
+immediate reciprocal sharing opportunities. For this purpose, we first developed
+several heuristics to identify the home AP for each device in the dataset. The
+intuition is that the devices are most likely connected to their home AP at
+night. More specifically, to identify the home AP for a device, we look at
+\wifi{} sessions that happened during 12~AM and 4~AM and count the number of
+days that the device connects to each AP during this time period. We then
+identify the AP which has the largest day count as the device's home AP,
 provided that the day count is larger than a threshold (30 days).
  
 After applying the above heuristics, the home AP information of 107 devices are
 identified, including 101 unique BSSIDs. There are 6 BSSIDs that are identified
-as home AP for two devices. After further investigation and clarification with
-\PhoneLab{} administrator, we found this is because some participants are family
+as home APs for two devices. After further investigation and clarification with
+\PhoneLab{} administrators, we found this is because some participants are family
 members, and certain participants had device replacements during the data
 collection period. In both cases, multiple devices may be associated with the
 same home AP.
@@ -72,27 +71,30 @@ same home AP.
 \subsection{\wifi{} Session Signal Strength}
 \label{subsec:better}
  
-After identified home AP information, we then ask these two questions: (1) When
-the device is connected to home AP, how often does it receive a better signal
+After identifying the home AP for each device, we ask two questions: (1) When
+the device is connected to its home AP, how often does it receive a better signal
 from neighbors' APs which it does not have access to? and (2) When the home AP
-fails to provide best signal, is there one dominant neighbor AP among others
+fails to provide the best signal, is there one dominant neighbor AP 
 that provides better signal most of the time?
  
-To answer the first question, we inspect scan results that are reported during
-\wifi{} sessions with home APs. For each such scan result, we identify the
-currently associated home AP, $AP_{home}$, and the AP with best RSSI among all
-reported APs, denoted as $AP_{best}$. We are particularly interested in which we
-refer as \textit{sub-optimal} cases, where: (1) $AP_{home} \neq AP_{best}$; (2)
-the device never connects to $AP_{best}$ in the dataset; and (3) the RSSI of
-$AP_{best}$ is better than $AP_{home}$ by at least certain threshold (5dBm in
-our analysis). Such cases indicate that the device could potentially improve its
-\wifi{} performance by connecting to neighbor APs which have better signals yet it
-does not have access to. Note that here we consider RSSI as a hint in determining the
-\textit{optimal} AP and it is well understood that RSSI does not directly translate
-to \wifi{} performance, which we will discuss in Section~\ref{sec:challenges}.
-Also note that the cases when the device are not connected to APs with best
-signal due to bad roaming strategies are not interesting in the context of this
-paper, and are excluded by the second condition.
+\sloppy{%
+ To answer the first question, we inspect scan results that are reported during
+ \wifi{} sessions with home APs. For each such scan result, we identify the
+ currently associated home AP, $AP_{home}$, and the AP with best RSSI among all
+ reported APs, denoted as $AP_{best}$. We are particularly interested in
+ \textit{sub-optimal} cases, where: (1) $AP_{home} \neq AP_{best}$; (2) the
+ device never connects to $AP_{best}$ in the dataset; and (3) the RSSI of
+ $AP_{best}$ is better than $AP_{home}$ by at least a certain threshold (5~dBm
+ in our analysis). Such cases indicate that the device could potentially
+ improve its \wifi{} performance by connecting to a neighbor AP which has a
+ strong signal yet it does not have access to that AP. Note that here we
+ consider RSSI as a hint in determining the \textit{optimal} AP and it is well
+ understood that RSSI does not directly translate to \wifi{} performance, which
+ we will discuss in Section~\ref{sec:challenges}. Also note that the cases
+ when the device is not connected to APs with the strongest signal due to bad
+ roaming strategies are not interesting in the context of this paper, and are
+ excluded by the second condition.
+}
  
 \begin{figure}[t]
 \centering
@@ -104,23 +106,23 @@ paper, and are excluded by the second condition.
 We classify all scan results reported during \wifi{} sessions with home APs into
 two categories: sub-optimal and the rest. For each device, we calculate the
 percentage of time when the scan results indicate sub-optimal association.
-Figure~\ref{fig:suboptimal} shows the CDF of such percentage for 
+Figure~\ref{fig:suboptimal} shows the CDF of this percentage for 
 the 107 devices. We make several observations. First, for 80\% of the devices,
 their home APs usually provides best signal (sub-optimal percentage less than
 25\%). This result is not particularly surprising considering that home APs are
-usually carefully positioned to try to provide good coverage. Second, we notice
+usually carefully positioned to provide good coverage. Second, we notice
 that for certain number (8\%) of devices, their home APs failed to provide best
 signal for more than 40\% of the time, suggesting that these users may benefit
 from sharing the \wifi{} access of their neighbor APs.
  
-Next, we are interested to see when the device is in a sub-optimal association
-with its home AP, whether there exists a \textit{dominant} neighbor AP that
-usually provides the best signal among other neighbor APs. If such dominant
+Next, we want to answer the question when the device is in a sub-optimal association
+with its home AP, is there a \textit{dominant} neighbor AP that
+usually provides the best signal among other neighbor APs? If such dominant
 neighbor AP exists, then by just sharing access of this one particular neighbor
 AP, the device's sub-optimal association time can be largely reduced. To this
-end, we look at all the scan results in sub-optimal category, and count the
+end, we look at all the scan results in the sub-optimal category, and count the
 number of times that each neighbor AP appears as $AP_{best}$. For each device,
-we calculate the fraction of dominant neighbor AP. Figure~\ref{fig:dominantap}
+we calculate the fraction of the dominant neighbor AP. Figure~\ref{fig:dominantap}
 shows the CDF of dominant AP fraction. For 50\% of the devices, one particular
 neighbor AP contributes to more than 57\% of sub-optimal connection time,
 implying that even by sharing \wifi{} access of one neighbor AP, these device's
@@ -138,7 +140,7 @@ sub-optimal connection time can be reduced by more than 57\%.
 \label{subsec:reciprocal}
  
 Finally, we investigate the cases where two devices can obtain better signals
-from each other's home AP, i.e., reciprocal sharing opportunity. We first use
+from each other's home AP, i.e., reciprocal sharing opportunities. We first use
 scan results to establish physical neighbor information between the home APs.
 Then we investigate whether reciprocal sharing opportunities exist between
 neighbor APs.
@@ -149,16 +151,17 @@ AP_j \rangle \in E$ if $AP_i$ and $AP_j$ appear in the same result and both AP&#39;s
 signal strengths are larger than a threshold (80~dBm), meaning $AP_i$ and $AP_j$
 are physically colocated with each other. Figure 3 shows the constructed $G_{neighbor}$
 from the dataset, where nodes with no edges are omitted. There are three clear
-cluster of home APs. We also verified that APs in the same cluster have
+clusters of home APs. We also verified that APs in the same cluster have
 different SSID and manufacturer, confirming that they are not centrally deployed
 or managed.
  
 Next, we look into potential AP sharing opportunities among colocated APs. For
 each edge $\langle AP_i, AP_j \rangle \in E$, if $AP_i$'s clients receive better
-(by at least 5~dBm) signals from $AP_j$, then we draw a directed edge $\langle
+(by at least 5~dBm) signal from $AP_j$, then we draw a directed edge $\langle
 AP_i\rightarrow AP_j \rangle}$, indicating that $AP_i$'s clients could
 potentially benefit from sharing access of $AP_j$. We also assign a weight to
-each directed edge to indicate how often such relationship happens.
+each directed edge to indicate how often such relationship happens in the
+dataset.
  
 The updated home AP neighbor graph is shown in Figure~\ref{fig:reciprocal}.
 Sharing opportunities are sparse but exist. In particular, we observe one pair
@@ -183,9 +186,3 @@ relationships.
 Thickness of directed edges corresponds to edge weights.}
 \label{fig:reciprocal}
 \end{figure}
-
-
-
-\newpage
-\clearpage
-
@@ -32,9 +32,9 @@
 \numberofauthors{1}
  
 \author{%
- \alignauthor Jinghao Shi, Liwen Gui, Chunming Qiao\\Dimitrios Koutsonikolas and Geoffrey Challen\\%
- \affaddr{University at Buffalo}\\[0.05in]%
- \email{\texttt{\{jinghaos,liwengui,qiao,dimitrio,challen\}@buffalo.edu}}\\
+% \alignauthor Jinghao Shi, Liwen Gui, Chunming Qiao\\Dimitrios Koutsonikolas and Geoffrey Challen\\%
+% \affaddr{University at Buffalo}\\[0.05in]%
+% \email{\texttt{\{jinghaos,liwengui,qiao,dimitrio,challen\}@buffalo.edu}}\\
 Paper \#\thepapernumber{}%
 \vspace*{-0.1in}
 }
@@ -54,10 +54,10 @@ Paper \#\thepapernumber{}%
 \input{investigation.tex}
 \input{design.tex}
 \input{challenges.tex}
+\input{related.tex}
 \input{conclusion.tex}
  
 {\footnotesize
- \balance
 \bibliographystyle{abbrv}
 \bibliography{references}
 }
@@ -9464,3 +9464,7 @@ Networks and Devices in the Home},
 booktitle={Proceedings of {ACM SIGMETRICS}},
 year={2013}
 }
+
+@misc{fon,
+ howpublished={\url{https://corp.fon.com/en}}
+}
+\section{Related Works}
+\label{sec:related}
+
+FON~\cite{fon} is a global Wifi sharing network, where registered users can roam
+over FON-supported Wifi networks. WLAN owners share their Wifi network either
+for small money compensation, or to get Wifi access to other users when they are
+way from home (roaming). FON aims at providing global Wifi sharing community
+where users want to connect to others' Wifi network only because they are way
+from home and have no WLAN access. Whereas in our proposal, users share Wifi
+network locally (within neighbors) for better network performance. The sharing
+relationship is a stable and tight loop.