BlogRecent1Add my vote for this tag BlogTechnical1Add my vote for this tag BlogWireless1Add my vote for this tag create new tag
view all tags

2014-05-29 - Prepping Our Next Paper

We are in the process of wrapping up an invited paper and were originally going to focus on the impact of probe requests from unaffiliated user elements (UEs, aka smartphones). The premise is fairly simple, smartphones tend to be aggressively tuned to pursue WiFi. One way in particular to make WiFi aggressive is to undergo frequent probe requests, aka is anyone out there? The use of a probe request will cause any APs (hidden or visible) to pipe up on a particular channel, thus allowing one to find WiFi faster versus simply waiting for the next beacon.

In short, the UE wakes up its WiFi adapter and rapidly scans the available WiFi space, 2.4 and 5 GHz for most devices (aka 802.11n). Issue a probe request (generic request, any AP), wait a small bit, hop to the next channel, rinse and repeat across all channels. Repeat the same thing for hidden APs (i.e. APs that do not broadcast via beacons and only respond to probe requests). If the UEs find a viable AP, the process stops and the UE proceeds to join the "trusted" or pre-known AP. Various UE software might also prompt the user to join the WiFi network if new APs are found.

While this process can speed up how fast you can find an AP, the flip side is that if there are no nearby APs that you can join, you keep issuing probe requests. When this occurs for only a few smartphones at home, this is not a big deal. However, imagine a dense environment where you have tens, hundreds, or even thousands of WiF devices doing this. Imagine say a stadium environment where you have thousands of APs whose WiFi range overlaps a small WiFi deployment. During scans in the 2.4 range that have plenty of overlapping channels (only 3 orthogonal ones at 1, 6, 11), not only do direct probe requests impact performance but also, probe requests on overlapping channels can also impact performance. The impact is reduced in the 5 GHz band due to there being more channels with less overlap but the problem still remains.

We have done some preliminary explorations on the impact in the 2.4 band via a few older 802.11g routers that we had. Unfortunately, we did not have a chance yet to run the experiments across 802.11n or 802.11ac APs to verify our results. As the impact could vary considerably, we ended up spiking that topic temporarily (saving it for later in the summer).

Hence, we are pivoting on a paper which has come along nicely drawing in particular on the effect of WiFi quality, namely that of the WiFi chipset / configuration on the handset. An overlooked notion for WiFi is the quality of the reception, i.e. how good is the antenna / chipset at the UE? For high end smartphones, we have seen a consistent march towards better quality where now quality is starting to match that of laptops and tablets. For the lower end smartphones, this is a bit more of a problem as cheapening the WiFi is one way to save money on a handset. As our CellNet paper back in 2012 had shown, this can be problematic resulting in flipped curves whereby cellular exceeds WiFi. Our paper is focusing on that particular interplay, exploring how taking the same students from the cohort in the NetSense study and giving them phones with better WiFi (the campus WiFi remained largely unchanged) results in dramatically different WiFi consumption, approaching if not exceeding the two-thirds estimates from prior works. The most interesting part is that consumption tended to continue unabated when on LTE which was quite fascinating.

Hopefully we can toss up an arXiV link soon with the paper as well as a few d3js graphs to show off several of the results that Shu had cooked up before she graduated.

Edit | Attach | Watch | Print version | History: r1 | Backlinks | Raw View | More topic actions
Topic revision: r1 - 2014-05-29 - AaronStriegel
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback