UNCONNECTED CHATTY Wi-Fi DEVICES | enterprise.netscout.com


Probing Phone Example

HTC phone: 173 Probes per sec at 330 bytes/probe. 2640 bits/sec at 1 Mbps = 0,00264 seconds per frame. W/ 173 Probes/min = 0,45672 Probe secs/minute of airtime + 40 microsecs/frame (0,00956 secs) = 0,46628 seconds per min (0,777% of airtime per phone, per channel)

If you’re looking for a trigger word for networking folks, you could do worse than “BYOD”. BYOD, which stands for “bring your own device” is the concept of allowing employees, vendors, guests and all manner of others to use their device of choice when accessing enterprise Wi-Fi. It introduces all sorts of concepts that traditionally have been foreign to networking, including mobility, lack of device control, neighboring network interference and guest authentication, among others.

The good news is that networking professionals have gotten used to BYOD. For nearly a decade — ever since the rise of the smartphone, really — enterprises have been increasingly willing to provide network and Internet connectivity for users’ personal Wi-Fi devices. While BYOD policy differs across organizations, the concept of allowing foreign devices to touch the network has gained acceptance.

The bad news is that there’s been another wireless trend happening during the growth of BYOD: faster cellular data speeds. In many cases, users who become frustrated with enterprise Wi-Fi can simply connect to their cellular provider’s network and happily access online applications without the network being a bottleneck.

Why is users’ attraction to cellular data BAD news? It’s bad because cellular devices can damage network performance for Wi-Fi devices. Some devices have a Wi-Fi radio that remains very active when the device isn’t connected to a Wi-Fi network, even if the user is happily accessing cellular data. And if that isn’t frustrating enough, the behavior varies. Some devices may be polite, so to speak, when not actively using Wi-Fi. Other devices may be chatty little buggers when not connected via Wi-Fi.

This paper will explain how it is, exactly, that Wi-Fi enabled devices can degrade performance when NOT connected via Wi-Fi. It will also cover details about how NETSCOUT’s best in class Wi-Fi analysis application, AirMagnet WiFi Analyzer PRO, can be used to diagnose whether chatty Wi-Fi devices are causing performance issues.

First, an explanation of the problem.

The problem, as so often is the case, is bandwidth. Wi-Fi bandwidth, to be specific. Which means that the bandwidth issue is different than the normal way that network administrators think of bandwidth.

Wi-Fi devices and access points (APs) share a channel. Only one device can transmit over the channel at any given moment, otherwise a collision is likely.

Channel sharing works fine for Wi-Fi, most of the time. When one device or AP begins transmitting, other devices and APs go quiet. Then, once data has been transmitted, all devices and APs go through a process called “arbitration” to determine who sends next. The winner of arbitration sends data, thus starting the whole process over.

It kind of looks like this:
Wi-Fi arbitration keeps data flowing across the channel while keeping collisions to a minimum. And it usually works well. “Bandwidth” gets divided relatively equally. If there are four devices on a channel and the channel is capable of handling 100 Mbps worth of total throughput, then each device will end up with access to right around 25 Mbps of individual throughput.

The problem with Wi-Fi bandwidth is that it can fluctuate. Wi-Fi devices use a protocol called dynamic rate switching (DRS), which allows devices to switch between different data rates as needed.

DRS is a good thing for Wi-Fi because different devices may need different data rates. When channel conditions worsen, low rate Wi-Fi traffic can remain successful even as high rate traffic fails. Whether distance, walls, mobility, interference or something else is causing unstable channel conditions, low data rates can allow a Wi-Fi connection to remain usable.

The end result of DRS is that devices on the same channel may be using different rates, like so:
Once different rates are used, Wi-Fi bandwidth starts to change. The entire channel loses data capacity because the low rate traffic takes up more channel time when facilitating the same amount of data.

Here is a depiction of how the above Wi-Fi network might handle data of varying rates:
Fewer data frames are able to traverse the channel when each data frame takes up more time. The end result is that the whole network gets slower.

This all circles back to unconnected Wi-Fi devices in a very real way.

The problem is that many Wi-Fi devices keep active Wi-Fi radios so that users have a seamless experience when moving from a cellular-only area to an area where Wi-Fi is present.

Here’s the process:
First a device powers on (or wakes from sleep), then it looks for a Wi-Fi connection. If no Wi-Fi connection is available, the device then begins using its cellular radio (if present) for Internet access. While on cellular, the device keeps looking for Wi-Fi just in case the device moves to an area where an available Wi-Fi network is present.

The process of looking for Wi-Fi — even while connected via cellular — is what causes devices to remain active on the Wi-Fi channel when unconnected to the Wi-Fi network.

Devices looking for Wi-Fi can lead to big problems. Devices use messages called Probe Requests to look for available Wi-Fi networks. Probe Request frames are relatively large (well over 100 bytes, typically) and very, very slow. Probe request frames are designed to reach as many APs as possible, so they must be transmitted at the lowest data rate possible. Modern Wi-Fi devices send Probe Request frames at 1 or 6 Mbps. Compared to modern smartphones that can access Wi-Fi using data rates up to 867 Mbps, that is really, really slow.

It can lead to the channel looking like this:
A typical Probe Request will be at least 150 bytes long, possibly stretching as long as 360 bytes. That means somewhere between 240 and 2.920 microseconds of channel time will be used up by each Probe Request. (For those interested in the math, it’s approximately 40 microseconds of 802.11n/ac standard physical layer encapsulation, plus between 200 and 2.880 microseconds for the 150 to 360 bytes [1.200 to 2.880 bits] of the Probe Request frame using either 0,000001 [1 Mbps] or 0,0000001667 [6 Mbps] seconds per bit.)

In most cases, Probe Request frames use more channel time than data frames. Even a large data frame of 1546 bytes (1.500 byte payload, plus 8 bytes of upper layer encapsulation and 38 bytes of 802.11 header) using the relatively low data rate of 52 Mbps would take up just 280 microseconds of channel time, including headers and encapsulation. Essentially, a best case scenario Probe Request uses about the same amount of channel time as a worst case scenario data frame.

There is some good news in all of this: WI-Fi devices have become less rude. Three or four years ago, Wi-Fi devices were extremely “chatty” when unconnected. A smartphone using its cellular connection for data might transmit enough Probe Request frames to take up many multiples of the amount of Wi-Fi channel time used by a typical connected Wi-Fi device. In high density environments, Wi-Fi devices that could ruin Wi-Fi networks without ever connecting to them. Today, that doesn’t happen. Wi-Fi devices send far fewer Probe Request frames when not connected to a Wi-Fi network.

While it is good that Wi-Fi devices are typically less chatty than they once were, unconnected Wi-Fi devices can still be a problem. Certain Wi-Fi devices can get chatty enough to cause Wi-Fi performance and stability issues, especially in areas with dense concentrations of people.

In some ways, the problem is even more tricky because there is less certainty. Wi-Fi professionals used to be able to say, “we need to get all these Wi-Fi devices connected, or we need to get users to turn their Wi-Fi radios off.” Now, it’s more like, “we need to find out IF these unconnected devices are too chatty, because they might be a problem or they might not.”

Whenever there is an “if” in Wi-Fi, the situation calls for a Wi-Fi network analyzer. And NETSCOUT has an enterprise class Wi-Fi network analyzer that allows data rates and Probe Request activity to be tracked, quickly and simply.

NETSCOUT’s AirMagnet WiFi Analyzer PRO is the original Wi-Fi specific analyzer. In fact, it is still really the only Wi-Fi specific analyzer. What allows NETSCOUT to make that claim is the fact that AirMagnet WiFi Analyzer PRO has several Wi-Fi specific features. And not-so-coincidentally, some of those Wi-Fi specific features can be used to gauge whether unconnected devices are causing Wi-Fi problems by being too chatty.

Determining the performance impact of Wi-Fi devices begins in the place where AirMagnet WiFi Analyzer PRO houses several of its most useful Wi-Fi specific features: the Infrastructure screen. The Infrastructure screen — like all screens in AirMagnet WiFi Analyzer PRO — can be accessed by clicking on a button in the lower left corner of AirMagnet WiFi Analyzer PRO:

From the Infrastructure screen, one of AirMagnet WiFi Analyzer PRO’s signature Wi-Fi specific features can be accessed by simply clicking on an AP or device. Any time an AP or a device is selected, AirMagnet WiFi Analyzer PRO immediately begins capturing on the exact channel occupied by the selected AP or device.

AirMagnet Wi-Fi Analyzer's ability to automatically capture on the channel of a selected device is a huge time-saver compared to situations where capture channels have to be manually selected.

Here is an example of how AirMagnet Wi-Fi Analyzer’s Infrastructure screen can be used to gauge the chattiness of Wi-Fi devices:
First, the device must be identified. To allow AirMagnet WiFi Analyzer PRO to display a list of all devices, “STA List” must selected from a dropbox in the upper left corner of the Infrastructure screen of AirMagnet WiFi Analyzer PRO.

Station lists can number in the hundreds, so be prepared to spend a moment looking for a device by MAC address, IP address or hostname. AirMagnet WiFi Analyzer PRO’s ability to capture an analyze any and all Wi-Fi activity is great in a lot of ways, but when it comes time to find a single MAC address, manual labor gets involved.

Station lists can number in the hundreds, so be prepared to spend a moment looking for a device by MAC address, IP address or hostname. AirMagnet WiFi Analyzer PRO’s ability to capture an analyze any and all Wi-Fi activity is great in a lot of ways, but when it comes time to find a single MAC address, manual labor gets involved.

Stations are listed in alphabetical order, which can make a search easier. Be careful, though, because AirMagnet WiFi Analyzer PRO is smart enough to recognize vendor OUIs (the first six digits of MAC addresses), so a device’s MAC address might have to be identified using the name of the device maker or Wi-Fi radio chipset maker.

After an unconnected Wi-Fi device has been found in the list of stations, the next step is to use another one of AirMagnet WiFi Analyzer PRO’s Wi-Fi specific features to gauge the device’s chattiness: the Stats window. When a device or AP is selected in the Infrastructure screen of AirMagnet WiFi Analyzer PRO, all information in the Stats window (located in the lower right corner of the screen) reflect only that device’s or AP’s activity. It's an amazing feature, especially when networking professionals need to cycle through dozens of Wi-Fi devices in search of the chattiest ones.

With AirMagnet WiFi Analyzer PRO, there is no need to look at countless captured frames or wait for analysis software to execute complex display filters. Instead, once a device is clicked on, statistics about Probe Request activity are easily viewed in the lower right corner of the Infrastructure screen.

There is one additional thing to note about analyzing the Probe Request activity of unconnected Wi-Fi devices. Wi-Fi network analyzers — AirMagnet WiFi Analyzer PRO, included — capture on one channel at a time, but devices will send Probe Request frames on multiple channels.

The 146 Probe Request frames shown in the figure above were transmitted by a single smartphone over the course of several minutes on one channel. The smartphone was almost certainly sending Probe Request frames on other channels as well. And if other devices were selected in AirMagnet WiFi Analyzer PRO's Infrastructure screen, similar numbers of Probe Request frames might have been seen.

When analyzing a Wi-Fi environment for Probe Request congestion, it is usually best to look for increasing numbers. If a device’s Probe Request numbers perpetually increase, then that device is a potential contributor to a problem. If numerous devices show increasing numbers of Probe Requests, then a higher level solution might be required.

A connected Wi-Fi devices tends to be a less chatty device, at least when it comes to Probe Request frames. Encouraging users to connect to a guest Wi-Fi network (and making connections simple and fast, to aid adoption) has been known to mitigate the problem.

One big thing to note about analyzing chatty devices is that it is always going to be impossible to capture every single Probe Request. It is impossible to predict exactly which channel Probe Requests will be sent on. If Probe Request frames are sent on a different channel than AirMagnet is capturing on, then Probe Request frames will be missed.

Analyzing unconnected device chattiness is an inexact science. Different devices send Probe Request frames of different lengths, with differing regularity and in differing channel patterns. As tricky as those things can make it, AirMagnet WiFi Analyzer PRO allows Wi-Fi Professionals to get a reasonable scope of the problem of unconnected devices getting chatty with Probe Request frames.

Powered By OneLink