From ae946d820c2c8aec5b1d1878f5ae7081bfed97b7 Mon Sep 17 00:00:00 2001 From: Jinghao Shi Date: Mon, 1 Jun 2015 17:35:13 -0400 Subject: [PATCH] 5 page fit --- conclusion.tex | 10 +++++----- design.tex | 20 ++++++++++---------- introduction.tex | 2 +- investigation.tex | 16 ++++++++-------- related.tex | 10 +++++----- 5 files changed, 29 insertions(+), 29 deletions(-) diff --git a/conclusion.tex b/conclusion.tex index f5471dd..07b68ea 100644 --- a/conclusion.tex +++ b/conclusion.tex @@ -1,11 +1,11 @@ \section{Conclusions} \label{sec:conclusion} -In this paper, we show that reciprocal \wifi{} sharing opportunities do exist in real -life scenarios through extensive analysis of the \PhoneLab{} \wifi{} dataset. We -propose and present the design of \wisefi{}, a system that detects reciprocal -sharing opportunities, enable \wifi{} sharing and monitor the \wifi{} usage and -performance to ensure the sharing remains reciprocal. +In this paper, we show that reciprocal \wifi{} sharing opportunities do exist in +real life scenarios through extensive analysis of the \PhoneLab{} \wifi{} +dataset. We present the design of \wisefi{}, a system that detects +reciprocal sharing opportunities, enable \wifi{} sharing and monitor the \wifi{} +usage and performance to ensure the sharing remains reciprocal. We are currently implementing a \wisefi{} system prototype, which includes a \wisefi{} Android application, dynamic AP configuration API support on OpenWRT diff --git a/design.tex b/design.tex index 15799c9..6b0a16c 100644 --- a/design.tex +++ b/design.tex @@ -38,14 +38,14 @@ described in Section~\ref{subsec:reciprocal}. \label{subsec:sharing} Once the reciprocal sharing opportunities are discovered, the \wisefi{} server -can distribute such information to the \wisefi{} application on smartphone, -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 home network printers or storage. +distributes such information to the \wisefi{} application on smartphone, which +prompts user to establish \wifi{} sharing. The sharing mechanism must meet two +goals: \textit{control} and \textit{protection}. First, the system should be +able to control the sharing, including granting the access of home AP to other +\wisefi{} users, and more importantly, revoking the access when needed. 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 home +network printers or storage. Some mid-to-high end wireless routers support the \textit{virtual network} feature, where multiple virtual \wifi{} networks are emulated by a single router @@ -78,7 +78,7 @@ all devices is still tedious. To overcome this challenge, we propose a dynamic \wifi{} AP configuration API with two simple interfaces: \texttt{getAuthClients} and \texttt{setWhiteList}. -The semantics of the interfaces are as follows. \texttt{getAuthClients} simply +The semantics of the interfaces are as follows. \texttt{getAuthClients} returns all the MAC addresses of clients that are currently associated with the AP through normal authentication. In home \wifi{} network scenario, this 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 obvious and another is obscure. First, it is obviously important to ensure that the sharing remains reciprocal -in long term to provide incentives for both parties to participate the sharing. +to provide incentives for both parties to participate the sharing. For instance, suppose after the system has established reciprocal \wifi{} sharing between Alice and Bob, and Bob decides to deploy an extra AP at his home which makes him no longer benefit from sharing Alice's home AP. The system should diff --git a/introduction.tex b/introduction.tex index e566158..f8deda2 100644 --- a/introduction.tex +++ b/introduction.tex @@ -64,7 +64,7 @@ But how often is reciprocal \wifi{} sharing beneficial and possible in practice? To explore these questions, we begin in Section~\ref{sec:investigation} by analyzing a dataset collected on the \PhoneLab{}~smartphone testbed containing \num{21192417} \wifi{} scan results -from 254~smartphones over 5~months (\S~\ref{sec:investigation}). Despite the +from 254~smartphones over 5~months. Despite the fact that the geographic extent of the dataset is suburban Buffalo, which as a city has a population density an order of magnitude lower than densely-populated areas like Manhattan, we still find that many users would diff --git a/investigation.tex b/investigation.tex index 0987c22..037afaa 100644 --- a/investigation.tex +++ b/investigation.tex @@ -79,12 +79,12 @@ that provide better signal most of the time? \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}$ and (2) the - device never connects to $AP_{best}$ in the dataset. 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 + currently associated home AP, $AP_{home}$, and the AP with best RSSI, denoted + as $AP_{best}$. We are particularly interested in \textit{sub-optimal} cases, + where: (1) $AP_{home} \neq AP_{best}$ and (2) the device never connects to + $AP_{best}$ in the dataset. 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 @@ -100,7 +100,7 @@ that provide better signal most of the time? \label{fig:suboptimal} \end{figure} -We classify all scan results reported during \wifi{} sessions with home APs into +We classify all scan results reported during home \wifi{} sessions 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 this percentage for @@ -110,7 +110,7 @@ their home APs usually provides best signal (sub-optimal percentage less than usually carefully positioned to provide good coverage. Second, we notice that for certain number (15\%) of devices, their home APs failed to provide best signal for more than 50\% of the time, suggesting that these users may benefit -from sharing the \wifi{} access of their neighbor APs. +from sharing the \wifi{} access of neighbor APs. Next, we want to answer the question when the device is in a sub-optimal association with its home AP, are there \textit{dominant} neighbor APs that diff --git a/related.tex b/related.tex index deffb55..19bbb40 100644 --- a/related.tex +++ b/related.tex @@ -1,8 +1,8 @@ -\section{Related Work} +\section{Related Works} \label{sec:related} OpenWireless movement~\cite{openwireless} is a community effort for ubiquitous -Internet access. Volunteers participate the community by configuring their +Internet access. Volunteers configure their \wifi{} network with open access and a special SSID, \texttt{openwireless.org}, to advertise free access. Another goal of OpenWireless is arguably preserving user's privacy by blending the user's network activity among all other users who @@ -22,11 +22,11 @@ neighbor relationship). There are also rich literature on cooperative \wifi{} sharing. Dimopoulos \textit{et al.}~\cite{efstathiou2010controlled} propose a reciprocal Wifi -sharing mechanism and later on extend it to a large scale peer-to-peer Wifi +sharing mechanism and later extend it to a large scale peer-to-peer Wifi roaming framework~\cite{dimopoulos2010exploiting}. They mostly focus on the reciprocal manner of sharing: each user who share his/her WLAN will obtain digital proof service (\textit{receipts}), which represent a ``I-owe-you'' relationship. These receipts can later on be consumed to get reciprocal Wifi access from other users. Such reputation mechanisms can also be applied to -\wisefi{}, although they can be simplified since \wisefi{} focus on sharing -between two immediate peers with physical colocation relationship. +\wisefi{}, although they can be simplified since the sharing is between two +immediate peers with physical colocation relationship. -- libgit2 0.22.2