Phones On A WLAN

Enough is enough! I have had it with these motherf*cking smartphones on this motherf*cking WLAN! 

-Neville Flynn, played by Samuel L. Jackson in Snakes on a Plane (paraphrased) 

Oh, if only our wireless networks could be saved from smartphones by a foul-mouthed constable. Instead, we have to deal with them. I've done a bit of sniffing recently in an attempt to figure out how much damage a roving smartphone actually does and it led me to a radical conclusion.

At halftime of a Los Angeles Clippers game a few months ago, I had the occasion to speak with someone who works with the Staples Center WiFi network. He was unable to share too many details for security reasons, but one thing he did share were the problems Staples Center has with smartphones. 

When people attend a sporting event, thousands of WiFi-enabled smartphones are brought into a large open space. The Staples Center WiFi guy told me that the WLAN infrastructure shows that thousands of Ad-Hoc networks are created by these smartphones, mostly in the 2.4 GHz frequency band. The end result is that the 2.4 GHz band is nearly unusable to media members, vendors and employees of AEG (the company that owns and operates Staples Center). The Staples Center WiFi guy's interpretation is a little bit off, I believe, because Cisco's controllers and management software are known to incorrectly classify unassociated, probing client stations as Ad-Hoc networks. (And feel free to correct me in the comments area if Cisco has a way to fix the classification of unassociated probing stations.) The way that these smartphones are classified by the Cisco infrastructure is irrelevant, though. What is relevant is that these devices are causing serious damage to the Staples Center WLAN, and any other WLAN that has lots of people crowding into a big, open space.

In order to assess the damage that smartphones cause, I used WildPackets OmniPeek to capture the activity of my iPhone 4. The iPhone 4 has a 2.4 GHz 802.11b/g/n WiFi adapter. The iPhone 4's WiFi adapter has a single radio chain ("radio chain" essentially meaning a transceiver/antenna pair) and is incapable of using 40 MHz channels or the short guard interval. In plain(er) English, the iPhone 4 is, at best, a 65 Mbps device in the crowded 2.4 GHz frequency band.

Now, a debate can be had on whether the phrase "65 Mbps device in the crowded 2.4 GHz frequency band" means inherent trouble or not. I say "no", some people say, "yes". (I am correct, of course.) For this blog post, let's set that aside and just look at the impact that a typical smartphone has on the WLAN.

Here is a screenshot of an OmniPeek capture that I did for all traffic that an unassociated iPhone4 is a party to when the phone is turned on and unassociated for one minute:

There are a few important things I am seeing in that capture. The unassociated phone only caused 128 frames to be transmitted on the channel that I captured on. Compared to a typical, active client station, that is pretty good. The problem is that the traffic is large (well over 300 bytes when in the form of a Probe Response), the traffic uses a low rate (1 Mpbs, or whatever the lowest Basic Rate is) and the client station is also causing similar amounts of traffic on other channels (definitely channels 1/6/11, and probably other channels as well).

Contrast the above screenshot with an OmniPeek screenshot taken after an associated iPhone 4 was operating on the channel for one minute:

The associated smartphone caused 229 frames to be added to the channel. More frames is bad, usually. In this case, however, more frames is not so bad. The frames here are smaller (a bunch of 28 byte Null Data frames accompanied by 14 byte Acknowledgment frames) and the frames here use higher rates (the highest Basic Rate will typically be used for the Null/Ack power save sequence).

Let's even do some rough math on this. If we assume that the physical layer overhead (PLCP header and preamble) is identical for all frames since we are looking at traffic going to or from a single device, then the MAC layer overhead is what will make the difference. When the phone is unassociated, lots of 117 byte and 369 byte frames were transmitted at 1 Mbps. That means 117 microseconds or 369 microseconds used per frame for MAC layer activity. When the phone is associated, lots of 28 byte and 14 byte frames were transmitted, usually at 24 Mbps. That means about 1 microsecond or a half of a microsecond used per frame. If we extend the math a bit, that means that each Probe Request/Response pair has the equivalent overhead of about 278 Null/Ack pairs at the MAC Layer. And even if we add 40 microseconds of overhead for the PLCP (a typical amount when 802.11n mixed mode is used), that still means that the unassociated station causes about seven times as much dead (read: unavailable for data) channel time per Probe Request/Response pair as an associated station causes for a Null/Ack pair. And that is not even accounting for the fact that the unassociated station is likely causing this overhead on at least three channels.

If the preceding paragraph reads as a bunch of uber-techie mumbo jumbo, let me simplify it: a powered on, inactive smartphone that is not connected causes at least ten times as much damage to your public WiFi network as the same phone when it is connected.

The obvious solution to the problem, then, is to treat smartphones the exact opposite way that Samuel L. Jackson's character treats snakes on 2006's internet darling, Snakes on a Plane. Neville Flynn (profanely) wants the snakes off his plane. You probably want smartphones on your WLAN. It may sound counter-intuitive, but it may also prevent users from telling their friends that your WiFi network is the Snakes on a Plane of wireless networks.