diff --git a/challenges.tex b/challenges.tex
index 691b6cc..6d882ce 100644
--- a/challenges.tex
+++ b/challenges.tex
@@ -7,13 +7,13 @@ cooperative \wifi{} access and brings new challenges.
 As discussed in Section~\ref{subsec:sharing}, user's privacy and security can be
 preserved through isolating either at network level (virtual networks) or client
 level (white list vs. authenticated clients). However, it is still an open
-question that whether or to what extent the user is liable to the illegal
+question whether or to what extent the user is liable to the illegal
 actions, most notably copyright infringement, of the peers who share the
 network.
 
 Another challenge in establishing reciprocal \wifi{} sharing is the bootstrap
 process. It is expected that during early stages of deployment, the sharing
-opportunity will be sparse. Therefore, It is important to provide additional
+opportunity will be sparse. Therefore, it is important to provide additional
 incentives other than the benefit of \wifi{} sharing to increase the penetration
 of system. One possible feature that can be added to the \wisefi{} app is to
 help the user find better \wifi{} channels for their own APs. Uses who are
diff --git a/design.tex b/design.tex
index b722c24..97cd70c 100644
--- a/design.tex
+++ b/design.tex
@@ -25,12 +25,12 @@ shows the overall work flow of the \wisefi{} system.
 To detect reciprocal sharing opportunities, two pieces of information are
 required: the home AP of the device, and neighbor APs' signal strength during
 \wifi{} sessions with the home AP. A smartphone application can be deployed
-through app market to collect these information. In particular, the home AP
+through app market to collect this 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 inputted directly by user. Once the home
 AP information is identified, \wifi{} scan results during sessions with home APs
 can then be logged to identify the neighbor APs that can potentially provide
-better network performance. Finally, these information are uploaded and fused in
+better network performance. Finally, this information is uploaded and fused in
 \wisefi{} server to identify reciprocal sharing opportunities using the methods
 described in Section~\ref{subsec:reciprocal}.
 
@@ -38,8 +38,8 @@ described in Section~\ref{subsec:reciprocal}.
 \label{subsec:sharing}
 
 Once the reciprocal sharing opportunities are discovered, the \wisefi{} server
-distributes such information to the \wisefi{} application on smartphone, which
-prompts user to establish \wifi{} sharing. The sharing mechanism must meet two
+distributes such information to the \wisefi{} application on the smartphone, which
+prompts the 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,
@@ -56,7 +56,7 @@ temporal visitors yet isolate them from home clients. For home APs with such
 feature, \wifi{} sharing can be achieved by only distributing the credential of
 guest network to other \wisefi{} users. Access and bandwidth policies can then
 be enforced on the guest network to achieve control and protection.
-Additionally, such isolation and enforcements are mostly likely already enabled
+Additionally, such isolation and enforcements are most likely already enabled
 by default for guest networks, so that even inexperienced user can configure the
 \wifi{} sharing through guest network.
 
@@ -65,14 +65,14 @@ be required by user, such as MAC black or white list, routing table
 modification, etc. Such configurations are most likely too complicated for
 average users to perform. However, simply sharing the \wifi{} credential of user's
 home AP to other \wisefi{} users is not only dangerous, but also making it
-difficult to revoke the access in the future. In worst case scenario, a user may
+difficult to revoke the access in the future. In the worst case scenario, a user may
 be forced to change the home AP password and reconfigure the \wifi{} credential
 on all his/her devices just to revoke the access of the other \wisefi{} user.
 Although most commodity APs support client MAC black or white list feature,
 configuring them properly is difficult for average users. Furthermore, the
 sharing relationship should be built between users instead of devices: once the
 sharing is established, one user should be able to connect any of his/her
-devices, not only the smartphone, to the other user's home AP. Even the system
+devices, not only the smartphone, to the other user's home AP. Even if the system
 can directly share each other's \wifi{} credential, manually configuring it on
 all devices is still tedious.
 
@@ -80,8 +80,8 @@ 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} 
 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
+AP through normal authentication. In the home \wifi{} network scenario, this
+interface shall return only the MAC addresses of the user's own \wifi{} devices.  On
 other hand, \texttt{setWhiteList} sets a list of white list MAC addresses that
 the AP should accept their association requests regardless of possible
 authentication errors (e.g., due to incorrect \wifi{} password). Finally, these
@@ -92,7 +92,8 @@ API through the HTTP server that is already integrated in most commodity APs.
 
 With the help of these configuration APIs, the \wifi{} sharing process can work
 as follows. Suppose the \wisefi{} system has discovered the reciprocal sharing
-opportunity between Alice and Bob, here are the steps to grant Bob's device to
+opportunity between Alice and Bob, here are the steps to grant Bob's device
+access to
 Alice's home AP. First, the \wisefi{} app on Bob's smartphone (which is
 associated with Bob's home AP through proper authentication) sends a
 \texttt{getAuthClients} request to Bob's home AP, retrieving the MAC addresses
@@ -115,12 +116,13 @@ Second, revoking access of other \wisefi{} users simply requires a
 \texttt{setWhiteList} request, without needing to change the user's home AP
 password. Furthermore, the \wisefi{} app can list other \wisefi{}
 users who are in a reciprocal sharing relationship and provide interfaces to let
+the
 user manually revoke access of other users if needed. Finally, this mechanism
 does not require modifications of \wifi{} clients (except for installation of
-\wisefi{} app) and only requires software updates at AP side, making it easy to
+the \wisefi{} app) and only requires software updates at AP side, making it easy to
 deploy.  Once the sharing is established, protection and isolation can be
 enforced at the AP side by differentiating two type of clients: authenticated
-clients (user's own devices) and while list clients (\wisefi{} devices).
+clients (user's own devices) and white list clients (\wisefi{} devices).
 Therefore, such sharing mechanism meets both the control and protection goals.
 
 
@@ -138,17 +140,17 @@ For instance, suppose after the system has established reciprocal \wifi{} sharin
 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
 monitor Bob's \wifi{} usage to detect the termination of the reciprocal
-relationship and revoke Alice's access of Bob's home AP accordingly.
+relationship and revoke Alice's access to Bob's home AP accordingly.
 
 Second, the not so obvious reason is that, as mentioned in
 Section~\ref{subsec:better}, \wifi{} signal strength is used 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, also affect the link quality
+PHY data rate, interference, or \wifi{} generation (e.g., 802.11/g/n/ac), also affect the link quality
 yet can not be easily detected by the smartphone. Furthermore, last hop \wifi{}
-link quality does not necessarily determines clients' overall end-to-end network
+link quality does not necessarily determine the clients' overall end-to-end network
 performance. In fact, there is no way to predict whether the neighbor AP can
-indeed provide better network performance than user's home AP until the sharing is
+indeed provide better network performance than the user's home AP until the sharing is
 actually established.
 
 To measure the reciprocity in terms of network performance, standard performance
@@ -156,7 +158,7 @@ benchmarks, such as download/upload throughput, \texttt{ping} latency, or DNS
 lookup, can be performed periodically by the \wisefi{} client. However, it is
 not trivial to monitor the network usage aspect of reciprocity from the vantage
 point of a single client: the smartphone's association time may not be
-representative of user's other wireless devices. For this purpose, we argument
+representative of user's other wireless devices. For this purpose, we augment
 the AP configuration API proposed in Section~\ref{subsec:sharing} with one new
 interface, \texttt{getWhiteListClents}, which returns the MAC addresses of
 clients that associated with the AP through white list mechanism. These are the
diff --git a/introduction.tex b/introduction.tex
index f8deda2..fa7a3f0 100644
--- a/introduction.tex
+++ b/introduction.tex
@@ -70,7 +70,7 @@ a city has a population density an order of magnitude lower than
 densely-populated areas like Manhattan, we still find that many users would
 benefit from being able to connect to neighboring private networks. Even more
 surprisingly, despite monitoring only several hundred users we were still
-able to identify several reciprocal \wifi{} sharing opportunities in our tiny
+able to observe reciprocal \wifi{} sharing opportunities in our tiny
 sample. Motivated by these results Section~\ref{sec:design} presents the
 design of \wisefi{}, a system addressing the practical challenges of
 establishing and monitoring reciprocal \wifi{} sharing agreements. We
diff --git a/investigation.tex b/investigation.tex
index 5442657..71f6884 100644
--- a/investigation.tex
+++ b/investigation.tex
@@ -60,7 +60,7 @@ 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) to further
 filter out false positives.
 
-After applying the above heuristics, the home AP information of 107 devices are
+After applying the above heuristics, the home AP information of 107 devices is
 identified, including 101 unique BSSIDs. There are 6 BSSIDs that are identified
 as home APs for two devices. After further investigation and clarification with
 \PhoneLab{} administrators, we found this is because some participants are family
@@ -123,7 +123,7 @@ 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 the top $n (1 \le n \le 3)$ dominant neighbor APs.
 Figure~\ref{fig:dominantap} shows the CDF of dominant AP fraction. By sharing 1,
-2 or 3 neighbor APs, half the device's sub-optimal connection time can be
+2 or 3 neighbor APs, the suboptimal connection time for 50\% of the devices can be
 reduced by 55\%, 82\% and 90\% respectively.
 
 \begin{figure}[t]
@@ -143,7 +143,7 @@ purpose, we build a reciprocal sharing graph $G_r=(V, E)$, where $V$ is the set
 of APs, and $\langle AP_i \rightarrow AP_j \rangle \in E$ if $AP_i$'s clients
 receive better signal from $AP_j$, that is, $AP_j$ appears as $AP_{best}$ in the
 scan results of $AP_i$'s clients. Note that according to the definition, $AP_i$
-is one of the identified home APs, while $AP_j$ could be other arbitrary APs.
+is one of the identified home APs, while $AP_j$ could be any other arbitrary AP.
 Loops in $G_r$ represent reciprocal sharing opportunities.
 
 To capture the reciprocal sharing relationships among \PhoneLab{} participants,
@@ -174,7 +174,7 @@ APs, node 0 and 7, which exhibit reciprocal sharing relationships.
 
 We must point out that \PhoneLab{} participants reside sparsely among the vast
 Buffalo area, and the above analysis is further restricted to those participants
-that we can detect their home APs using heuristics described
+whose home AP can be detected using heuristics described
 Section~\ref{subsec:homeap}. The consequence of such sparsity is that most of
 the neighbor APs which can provide better signal are not one of the identified
 home APs, thus are not shown in Figure~\ref{fig:reciprocal}. To quantify the
diff --git a/related.tex b/related.tex
index 19bbb40..936e52b 100644
--- a/related.tex
+++ b/related.tex
@@ -10,22 +10,22 @@ share access to the open \wifi{} network. On other hand, FON~\cite{fon} is a
 commercial 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 because they are way from home and
+from home (roaming). FON aims at providing a global Wifi sharing community where
+users want to connect to others' Wifi network because they are away from home and
 have no WLAN access. 
 
 Both OpenWireless and FON aim at sharing \wifi{} access between strangers either
-through volunteering or financial incentives. Whereas in our proposal, users share
+through volunteering or financial incentives. In contrast, in our proposal, users share
 Wifi network locally (within neighbors) for better network performance, and the
 sharing relationship is immediate (between two parties) and stable (physical
 neighbor relationship).
 
-There are also rich literature on cooperative \wifi{} sharing. Dimopoulos
+There are also several works on cooperative \wifi{} sharing. Dimopoulos
 \textit{et al.}~\cite{efstathiou2010controlled} propose a reciprocal 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''
+reciprocal manner of sharing: each user who shares his/her WLAN will obtain
+digital proof of service (\textit{receipts}), which represents 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 the sharing is between two